Re: [v6ops] Updating RFC 7084
Ole Troan <otroan@employees.org> Mon, 21 November 2022 15:53 UTC
Return-Path: <otroan@employees.org>
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 B2300C1524AF for <v6ops@ietfa.amsl.com>; Mon, 21 Nov 2022 07:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.204
X-Spam-Level:
X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=employees.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOsKUC4oEu0Q for <v6ops@ietfa.amsl.com>; Mon, 21 Nov 2022 07:53:06 -0800 (PST)
Received: from vesa03.kjsl.com (vesa03.kjsl.com [IPv6:2001:4830:c170::91]) (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 8D9C3C1524B0 for <v6ops@ietf.org>; Mon, 21 Nov 2022 07:53:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=employees.org; i=@employees.org; q=dns/txt; s=vesa202009; t=1669045986; x=1700581986; h=content-transfer-encoding:from:mime-version:subject:date: message-id:references:cc:in-reply-to:to; bh=T0YuhXDpvlOXbHvMJmjNI9oTAKkV4q+sRDlqmKJkadM=; b=gvZ+TVuZDn3Mn07x7qNDm2TJUMNh/Q3/8qXZJZ1cEjBZawV0qLYGmkSR no+P79KNpCIWy3E4NwxW62Wv9ZnOgQrvWuiMhmuSQ5y0OLubg0NI9VNDg eBTNaV2eeZJ7jTi7TGmVe5cggAQiPvC+V0TyOX99ArLEVdYIabo7Bheoo CMZZ0Z8Xbq2e+7ulKN+Qmkd3/YNtJd9wc9kT5r99BaLuTICgXB9AMyqqi wPPu8Yd/0yBgK32ax7pFKRFbS4f5EnHGaIcewB/DBLxRU3JxYeoxCflV3 XcWVWztQCPVI7sebLfTFZIrQsMp3Pk/kGpU8zXJPVf0GbM1aokC7F+znh A==;
Received: from clarinet.employees.org ([IPv6:2607:7c80:54:3::74]) by vesa03.kjsl.com with ESMTP; 21 Nov 2022 15:53:03 +0000
Received: from smtpclient.apple (ti0389q160-5811.bb.online.no [95.34.2.246]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 22E714E11B0F; Mon, 21 Nov 2022 15:53:03 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-3CFBDD50-B8AC-4E30-96D4-EC72E4DFCC7B"
Content-Transfer-Encoding: 7bit
From: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Date: Mon, 21 Nov 2022 16:52:51 +0100
Message-Id: <B1B0F1F6-DEEA-4043-9771-4BE3407E0D71@employees.org>
References: <0595eeaa9312460782253b7b465edf7e@huawei.com>
Cc: Ted Lemon <mellon@fugue.com>, IETF v6ops WG <v6ops@ietf.org>
In-Reply-To: <0595eeaa9312460782253b7b465edf7e@huawei.com>
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (20B101)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/acxk9m43fi_cTnj64QAfD8RwSuI>
Subject: Re: [v6ops] Updating RFC 7084
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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 Nov 2022 15:53:10 -0000
On 21 Nov 2022, at 16:39, Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org> wrote:
_______________________________________________Imagine that the uplink to the Carrier (DSL for example) is down.
All hosts on the site should stop using the /48 prefix received from this carrier. It should happen preferably sub-second.
How this negative information would propagate over the site? (multi-hop)
Default PIO preferred time is 1 week. Fernando has the intention to change it to 2hours – still pretty bad.
The resolution by the current ND is very bad.
Eduard
From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Monday, November 21, 2022 6:30 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: IETF v6ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Updating RFC 7084
The DHCPv6 server could send a notification to the DHCPv6 client if we are concerned about this. But it’s not clear to me that we should be. If you think we should be, you need to actually make a case for that, not just assert that it’s so.
Op ma 21 nov. 2022 om 08:52 schreef Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
Hi all,
I do not understand how DHCP-PD may be used for prefix distribution inside the site.
Because uplink could go down.
Should be some signaling to all routers on site that the prefix is not available anymore (and should be deprecated on all links).
But DHCP is stateless in principle.
This "flush renumbering problem" would be pretty difficult to fix.
It would kill MHMP completely.
Eduard
-----Original Message-----
From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian E Carpenter
Sent: Friday, November 18, 2022 9:02 PM
To: Timothy Winters <tim@qacafe.com>; IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] Updating RFC 7084
On 19-Nov-22 03:47, Timothy Winters wrote:
> Hello,
>
> I've started a draft to update RFC 7084 to support prefix delegation on the LAN interfaces. The current state of IPv6 in home networks is ISP are assigning prefixes of appropriate sizes but they currently are under utilized due to the lack of prefix delegation on LAN interfaces.
>
> This draft is an attempt to add that support to the draft.
>
> https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/" target="_blank" rel="nofollow"> https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/
> <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/>
>
> This is only an update to 7084 at the moment, there has been some discussion on the snac working group about leveraging this work as well.
>
> One item being discussed is this currently doesn't solve multi-homed networks.
As a historical note, we've spent a lot of time in the past on multi-homing and more or less failed (and the HOMENET approach was designed for home nets, not for enterprises where the problem is probably more important).
To summarise what I've said over on SNAC:
1. If we're going to mention PvDs in the 7084 update, I think we should also mention RFC 8028. It isn't that a CE router should necessarily support 8028, but that in a network that does implement 8028 on its subnet routers, the following part of 8028 applies:
2.2. Expectations of Multihomed Networks
Networking equipment needs to support source/destination routing for
at least some of the routes in the Forwarding Information Base (FIB),
such as default egress routes differentiated by source prefix.
Installation of source/destination routes in the FIB might be
accomplished using static routes, Software-Defined Networking (SDN)
technologies, or dynamic routing protocols.
Those egress routes of course lead to CE routers.
(There is some other thinking about this topic in draft-vv-6man-nd-support-mhmp).
Brian
>
> I welcome any feedback about the proposal.
>
> ~Tim
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/v6ops
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
- [v6ops] Updating RFC 7084 Timothy Winters
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Lorenzo Colitti
- Re: [v6ops] Updating RFC 7084 Lorenzo Colitti
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ole Troan
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Timothy Winters
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Chongfeng Xie
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 David Farmer
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 - alternate logic Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 Gert Doering
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic otroan
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu