Re: [v6ops] Updating RFC 7084
Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 18 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 F3856C14CE22 for <v6ops@ietfa.amsl.com>; Fri, 18 Nov 2022 07:24:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.671
X-Spam-Level:
X-Spam-Status: No, score=0.671 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_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=no 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 OrVKMPlB0n9y for <v6ops@ietfa.amsl.com>; Fri, 18 Nov 2022 07:24:00 -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 78554C14CF06 for <v6ops@ietf.org>; Fri, 18 Nov 2022 07:24:00 -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 2AIFNvI8030620; Fri, 18 Nov 2022 16:23:57 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5415320692E; Fri, 18 Nov 2022 16:23:57 +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 447C22068FA; Fri, 18 Nov 2022 16:23:57 +0100 (CET)
Received: from [10.8.32.70] (is156570.intra.cea.fr [10.8.32.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 2AIFNvIf051062; Fri, 18 Nov 2022 16:23:57 +0100
Message-ID: <e5531fd0-b7a6-603e-5df7-5cea777260bb@gmail.com>
Date: Fri, 18 Nov 2022 16:23:57 +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: Ted Lemon <mellon@fugue.com>
Cc: Timothy Winters <tim@qacafe.com>, IPv6 Operations <v6ops@ietf.org>
References: <CAJgLMKs5oYT1Eoq1Z-_3FYDVLvq6q8ecf+-g8cc1zZR5pJtJNw@mail.gmail.com> <a34370f1-46ea-3fe3-661f-5c2bd539dbe8@gmail.com> <CAPt1N1ms+y5tv=bDh+je4ow2zF4jAH4VKGuQOXwaW9LYwyfqfA@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <CAPt1N1ms+y5tv=bDh+je4ow2zF4jAH4VKGuQOXwaW9LYwyfqfA@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/wh89KAW9JUyy0waEVvM0IYgo8MM>
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: Fri, 18 Nov 2022 15:24:02 -0000
Ted, Le 18/11/2022 à 16:13, Ted Lemon a écrit : > Pretty much any CE router should ask for a /48, My question is not about a CE (customer edge) router, presumably connected on the DSL or optical line. I am asking aboout a trivial off-the-shelf access point router, or some other such router like a tv router, or a printer router, or any box router? This router would not be the CE, would not be managed by the ISP. I am trying to understand whether any such off-the-shelf box made for home networks runs DHCPv6-PD clients at all. > although I think a lot of them don't. I don't think that the behavior > currently specified in RFC7084 is quite right. I think what we want > is for the CE router to always ask for a /48. I think it makes sense for the CE router managed by the ISP to ask for a /48 from the ISP network, either with its own DHCPv6-PD client or with some other protocol means. > If it gets anything narrower than a /64, it sets up a DHCPv6 PD > server to sub-delegate. If it gets a /64, it sets up a relay agent > and relays any downstream PD requests to the DHCP server from which > it got its /64. If a prefix is delegated through the relay, it puts > a route to that prefix in its routing table, using the IP address of > the DHCP client or relay from which it received the PD request as > its next-hop. > > The DHCP server on the CE router only ever allocates /64s. I think the DHCP server on the CE router should allocate any prefix length on the LAN interface, not necessarily /64. The CE router could get a /48 on its DSL line, then form a /56 and allocate it to an in-home router on the LAN, which would further form a /57 and so on. All with DHCPv6-PD. In this > way, if the end user plugs a bunch of networks together, the edge > router winds up being responsible for all sub-delegations. Fair enough. > > Of course, there's probably a way for this to all go very very wrong > if the end user creates a loop. I'm not sure how they'd do that, but > it's probably possible. True. There are countless opportunities for this loop. But these opportunities are there anyways, regardless of the DHCPv6-PD presence. With a NAT everywhere concept too it is possible to create difficult loops, briges-vs-router impossible behaviours and so on, especially when there are too numerous brands of devices in that home network. Alex > > On Fri, Nov 18, 2022 at 10:01 AM Alexandre Petrescu > <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> > wrote: > > > > Le 18/11/2022 à 15:47, Timothy Winters a écrit : >> 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. >> >> I welcome any feedback about the proposal. > > A general comment: my freebox would indeed take advantage of this > proposal. Currently the freebox relies on a grandma personnage to > manually configure, and 'delegate' /64s to routers on LAN, out of a > /56 obtained on its DSL line. She needs to add lines like this: > > IPaddress-of-in-home-router prefix interface > > Were the freebox to implement a DHCPv6-PD server software, that work > would be much easier, it would be automated. > > But, is there a wifi in-home access point, or some other such kind > of in-home router, that would run a DHCPv6-PD Client to request the > prefixes from a freebox? > > Alex > >> >> ~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] 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