Re: [v6ops] Updating RFC 7084

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 23 November 2022 15:24 UTC

Return-Path: <alexandre.petrescu@gmail.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 3944BC14CEE8 for <v6ops@ietfa.amsl.com>; Wed, 23 Nov 2022 07:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.329
X-Spam-Level:
X-Spam-Status: No, score=-4.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 7uv79Jvz14Ru for <v6ops@ietfa.amsl.com>; Wed, 23 Nov 2022 07:24:15 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 41986C14CE5E for <v6ops@ietf.org>; Wed, 23 Nov 2022 07:24:15 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 2ANFOE7A010735 for <v6ops@ietf.org>; Wed, 23 Nov 2022 16:24:14 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 33991207210 for <v6ops@ietf.org>; Wed, 23 Nov 2022 16:24:13 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2A2AE205D20 for <v6ops@ietf.org>; Wed, 23 Nov 2022 16:24:13 +0100 (CET)
Received: from [10.11.243.10] ([10.11.243.10]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 2ANFOCDa017011 for <v6ops@ietf.org>; Wed, 23 Nov 2022 16:24:12 +0100
Message-ID: <99916727-a678-e79d-b66e-3fbcec12911b@gmail.com>
Date: Wed, 23 Nov 2022 16:24:12 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0
Content-Language: fr
To: v6ops@ietf.org
References: <0595eeaa9312460782253b7b465edf7e@huawei.com> <B1B0F1F6-DEEA-4043-9771-4BE3407E0D71@employees.org> <255cbeefc23e4ab9bd714a68266a73b4@huawei.com> <CAPt1N1=J5YG1onG-KX5cjZ6y5zrdQLmmY4g1Zog8RybLKzNn-Q@mail.gmail.com> <c0217ef65d06404696434e26e56c8557@huawei.com> <CAPt1N1mehaFD9utDe=V2i_T4qEmtp4LVMmCeEYPAk4jUBX1m_A@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <CAPt1N1mehaFD9utDe=V2i_T4qEmtp4LVMmCeEYPAk4jUBX1m_A@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/t_4GcAOZFDPL-N9tmTLAgmqzM3E>
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: Wed, 23 Nov 2022 15:24:19 -0000


Le 21/11/2022 à 18:04, Ted Lemon a écrit :
> Try to give us an example of an actual user experience that would be 
> affected by the behavior you are concerned about. Describe the network 
> configuration.
> 
> The reason I am skeptical of your concern is that I have no idea what 
> real world scenario is motivating it.

This: last night my ISP went down and I re-connected the TV via my 
spouse's smartphone.  It was all on IPv4.

But if my TV maintained the IPv6 address from my faulty ISP then I would 
have had bad time forcing it with the IPv6 address obtained from the 
smartphone.

This scenario is fictitious in its IPv6 aspect, but it is very true in 
the ISP connections going down and up these recent times.

In order for this IPv6-related problem to appear there are many things 
that are necessary first, before arriving at the problem with DHCPv6-PD 
on the LAN interface.

These problems relate a lot to the usage of IPv6 in general, to its 
level of penetration, to the large skepticism in the industry about it.

That is another problem that should be addressed.

Alex


> 
> Op ma 21 nov. 2022 om 12:02 schreef Vasilenko Eduard 
> <vasilenko.eduard@huawei.com <mailto:vasilenko.eduard@huawei.com>>
> 
>     Hi Ted,____
> 
>     I do not want to ignore you.____
> 
>     But I am not capable to explain it differently.____
> 
>     It looks so obvious…____
> 
>     Eduard____
> 
>     *From:*Ted Lemon [mailto:mellon@fugue.com <mailto:mellon@fugue.com>]
>     *Sent:* Monday, November 21, 2022 7:36 PM
>     *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com
>     <mailto:vasilenko.eduard@huawei.com>>
>     *Cc:* IETF v6ops WG <v6ops@ietf.org <mailto:v6ops@ietf.org>>; Ole
>     Troan <otroan=40employees.org@dmarc.ietf.org
>     <mailto:40employees.org@dmarc.ietf.org>>
>     *Subject:* Re: [v6ops] Updating RFC 7084____
> 
>     __ __
> 
>     What’s the problem you’re trying to solve here?____
> 
>     __ __
> 
>     Op ma 21 nov. 2022 om 10:59 schreef Vasilenko Eduard
>     <vasilenko.eduard@huawei.com <mailto:vasilenko.eduard@huawei.com>>____
> 
>         It was not about routing.____
> 
>         DHCP-PD propagates prefixes that would be used for PIOs.____
> 
>         If Carrier is not available anymore, hosts should stop using
>         these PIOs for source addresses.____
> 
>         But the stub router should be informed that particular prefixes
>         should not be used anymore.____
> 
>         How?____
> 
>         Then stub router could deprecate PIO (zero preferred lifetime).____
> 
>         Ed/____
> 
>         *From:*Ole Troan [mailto:otroan
>         <mailto:otroan>=40employees.org@dmarc.ietf.org
>         <mailto:40employees.org@dmarc.ietf.org>]
>         *Sent:* Monday, November 21, 2022 6:53 PM
>         *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com
>         <mailto:vasilenko.eduard@huawei.com>>
>         *Cc:* Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>>;
>         IETF v6ops WG <v6ops@ietf.org <mailto:v6ops@ietf.org>>
>         *Subject:* Re: [v6ops] Updating RFC 7084____
> 
>         ____
> 
>         Eduard,____
> 
>         ____
> 
>         I think you confuse addressing with routing. ____
> 
>         ____
> 
>         O. ____
> 
>         __ __
> 
>             On 21 Nov 2022, at 16:39, Vasilenko Eduard
>             <vasilenko.eduard=40huawei.com@dmarc.ietf.org
>             <mailto: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
>             <mailto:mellon@fugue.com>]
>             *Sent:* Monday, November 21, 2022 6:30 PM
>             *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com
>             <mailto:vasilenko.eduard@huawei.com>>
>             *Cc:* IETF v6ops WG <v6ops@ietf.org <mailto: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
>             <mailto: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
>                 <mailto:v6ops-bounces@ietf.org>> On Behalf Of Brian E
>                 Carpenter
>                 Sent: Friday, November 18, 2022 9:02 PM
>                 To: Timothy Winters <tim@qacafe.com
>                 <mailto:tim@qacafe.com>>; IPv6 Operations
>                 <v6ops@ietf.org <mailto: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/ <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/>
>                  >
>                 <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/ <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 <mailto:v6ops@ietf.org>
>                  > https://www.ietf.org/mailman/listinfo/v6ops
>                 <https://www.ietf.org/mailman/listinfo/v6ops>
>                 _______________________________________________
>                 v6ops mailing list
>                 v6ops@ietf.org <mailto:v6ops@ietf.org>
>                 https://www.ietf.org/mailman/listinfo/v6ops
>                 <https://www.ietf.org/mailman/listinfo/v6ops>
>                 _______________________________________________
>                 v6ops mailing list
>                 v6ops@ietf.org <mailto:v6ops@ietf.org>
>                 https://www.ietf.org/mailman/listinfo/v6ops
>                 <https://www.ietf.org/mailman/listinfo/v6ops>____
> 
>             _______________________________________________
>             v6ops mailing list
>             v6ops@ietf.org <mailto:v6ops@ietf.org>
>             https://www.ietf.org/mailman/listinfo/v6ops
>             <https://www.ietf.org/mailman/listinfo/v6ops>____
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops