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>
>