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