Re: [v6ops] Updating RFC 7084
Ted Lemon <mellon@fugue.com> Fri, 18 November 2022 17:27 UTC
Return-Path: <mellon@fugue.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 70B7BC1524BC for <v6ops@ietfa.amsl.com>; Fri, 18 Nov 2022 09:27:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.com
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 zEKAkQs5VILL for <v6ops@ietfa.amsl.com>; Fri, 18 Nov 2022 09:27:43 -0800 (PST)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 0D033C1524B5 for <v6ops@ietf.org>; Fri, 18 Nov 2022 09:27:42 -0800 (PST)
Received: by mail-qt1-x82b.google.com with SMTP id l2so3535959qtq.11 for <v6ops@ietf.org>; Fri, 18 Nov 2022 09:27:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ryhXvu6SAlLqm2n//YwqOtiQfFrWJM/iPiKdg+V8J3E=; b=dYHD5l4ffl9/STTeXAAMfJqvHmji3llOwdk//Qw5OiaTr7kyj+76IwKXKGn8WY/YQm T/rWwGTvSBStGL3C5Mht/EqNx6q2f8+32Sq6keEaPhWphQS9y3HaDyVLydZo8lSQQqq0 /qO6RoGVWm1Q98D160heuMGXomGdW3LSeVUepL3Lk+4onZrEr7b38lbExkJIh4LF2mvs WYmJi6riIS7Fixz6Kb/u4mLTM8yU8BSbjsp6s6LZ9VWu92DIBp4bLRfSDtqGM1A/nBQT yobiLY4Hj7psqY2pFwd145u2LhAT5cWFhnx7VpE4+eHWBoxppklBXVGlVSwjS7F3VJS2 pp1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ryhXvu6SAlLqm2n//YwqOtiQfFrWJM/iPiKdg+V8J3E=; b=rBwbGZY8owtXKPpDWRBHo3XwqzTPlxYQU8PZIZTe6pcsQ0DqggMfRabhraJk5SFxgR ws99m96cGhYKZ2kU4hsH/hNg8JAMv3xbdjCbdUE4G3Wyg5J0b8lCLiH+7+9uBIajIl1L m+wZOMjX/4qI8iN87uv/m7PFBs5/ZiDGU6NBoHujMBUlaEbYbJP9YqF5ZiOL51KfQFut H32JdmvCWk6wq/xcNA34spHlv00AWtvfWUlhIhuYH514rUcfUnQusSvYZdD2WHxgUldL KoVZalbM+2M455EMlLSHKBn0ZwDm+TLmzpqncwf15Ng7CcxGinCn+zlW3d0RgOhN4eOX pWwQ==
X-Gm-Message-State: ANoB5pm77wvtlPq2Y9S9lAG43igRxQX3ctE1ZwayNYpJqOBwluDOPlB/ BcLfQvZ2swTxe/AT7hLSMVED7HrA52MQCMutE7yvTBHxZYoNnQ==
X-Google-Smtp-Source: AA0mqf5x4BwQVc0eCe3WSnwoAJ9n8kU/mAqN68DzReO2QakT63mEsIF9N4cKzjwjRimIMW4JB1hMDHZCQKe6Gi+ueHc=
X-Received: by 2002:a05:622a:1e9b:b0:3a5:4442:80fb with SMTP id bz27-20020a05622a1e9b00b003a5444280fbmr7372195qtb.250.1668792461896; Fri, 18 Nov 2022 09:27:41 -0800 (PST)
MIME-Version: 1.0
References: <CAJgLMKs5oYT1Eoq1Z-_3FYDVLvq6q8ecf+-g8cc1zZR5pJtJNw@mail.gmail.com> <a34370f1-46ea-3fe3-661f-5c2bd539dbe8@gmail.com> <CAPt1N1ms+y5tv=bDh+je4ow2zF4jAH4VKGuQOXwaW9LYwyfqfA@mail.gmail.com> <e5531fd0-b7a6-603e-5df7-5cea777260bb@gmail.com>
In-Reply-To: <e5531fd0-b7a6-603e-5df7-5cea777260bb@gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 18 Nov 2022 12:27:31 -0500
Message-ID: <CAPt1N1kXS00Nz8N0havcUwNyw-CWAR3EgUPJuzx7wLuBM89F9A@mail.gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: IPv6 Operations <v6ops@ietf.org>, Timothy Winters <tim@qacafe.com>
Content-Type: multipart/alternative; boundary="000000000000e5449f05edc205ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7fRmhAgVlgl4_4DJtOblQdPf1Nc>
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 17:27:44 -0000
A CE router is a router that is at the customer edge of the network. It might be managed by the ISP, but often isn’t. If you buy a WiFi router from Amazon, you are buying a CE router. If it supports IPv6, as most do, then it definitely will request at least a /64 from whatever it’s connected to. Op vr 18 nov. 2022 om 10:23 schreef Alexandre Petrescu < alexandre.petrescu@gmail.com> > 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