Re: [v6ops] Updating RFC 7084
Lorenzo Colitti <lorenzo@google.com> Mon, 21 November 2022 00:55 UTC
Return-Path: <lorenzo@google.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 1D3E9C14CEE6 for <v6ops@ietfa.amsl.com>; Sun, 20 Nov 2022 16:55:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.595
X-Spam-Level:
X-Spam-Status: No, score=-17.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ourRWZ6_kDzN for <v6ops@ietfa.amsl.com>; Sun, 20 Nov 2022 16:55:53 -0800 (PST)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 67394C14F719 for <v6ops@ietf.org>; Sun, 20 Nov 2022 16:55:53 -0800 (PST)
Received: by mail-ua1-x92c.google.com with SMTP id s16so972659uaq.12 for <v6ops@ietf.org>; Sun, 20 Nov 2022 16:55:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.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=hKQ89PPoNPmyWi/zdqJJJH9KjX5OAscpvygqeXXSiw8=; b=XqLxcXESpRcR5nfSkAMVHabcba1yKhOENCxOl31+R8ng7S1Di/uvB95V8mJSByjv1A Ai2BMzPOJrboiBtdne2tOz6GrQ0SvssM3eROESguxFO2JOYXm90G+GnrcWLDneoIpn6r wMQZ6wl+9B8M4FoF5xpKpjCDhv/gzs3I/1bXLjriM7GtndK81e0dULkRynJTDyTCaYup q2iUHFDBAhejYh6egf5Agzwc7nHldogvIvfqm9LUuwbpfUdn3VNg2H5/siSIqZ27Gfd+ lxkJa1ciHDCqYeJ8anl8iD7d9eCtGnPh9pKLob6TqUyoZUBj1GtFEBg90kiBcBBIkrUY NuDA==
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=hKQ89PPoNPmyWi/zdqJJJH9KjX5OAscpvygqeXXSiw8=; b=U0EnR7hrRnh1IHSCvCSuKFX92M4TWELM8MWAczV37WNq7z3hs6WErp8C42yvV8I+4R PKEVuoFzV7fmKjTG6jgCBRbmN0mciHEhP0eguW5a5dZwMvu/L3MS69LsBf6p4CTvCYxs 7tv+BbnyklcUHFXotxKWmG6h91ZU+5WY+meACI/F/JR/SL552M4WDxbOpUKg55n3/qrk 1YNKXZoG4I8V3VzGP9R58BAaEqNhAu6NBWsdLWvzoH752w6TPQQHO4mR26jQaQBkj8Mu 7r1NCDu1AFuabyjjODLrI6rtPAEwPbpa3WMIFwdfKUTdSQRVr40Zy+p+FpgY1i4zcLO5 NE/Q==
X-Gm-Message-State: ANoB5pnQUmkLy4SPm/0T5vuZmDf6RADQNgXA+H9IroSWz7wb9aJ8casG tWA2G/qJZflSE6Ww08qGsUjskuGQQYa4nq8PDgwENzaGLmh8kkrC
X-Google-Smtp-Source: AA0mqf4bZIhtQ5Ext/AVLVI8re9fGG0scYh+m6QhB8NGXamiH6svFzvpbldY15eahdUj/cs2njh8XMpiJJHWaJYVHVI=
X-Received: by 2002:ab0:74c2:0:b0:40c:caeb:5130 with SMTP id f2-20020ab074c2000000b0040ccaeb5130mr8805719uaq.24.1668992152016; Sun, 20 Nov 2022 16:55:52 -0800 (PST)
MIME-Version: 1.0
References: <CAJgLMKs5oYT1Eoq1Z-_3FYDVLvq6q8ecf+-g8cc1zZR5pJtJNw@mail.gmail.com>
In-Reply-To: <CAJgLMKs5oYT1Eoq1Z-_3FYDVLvq6q8ecf+-g8cc1zZR5pJtJNw@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 21 Nov 2022 09:55:40 +0900
Message-ID: <CAKD1Yr2jLyOxK1PVmXYaQ5G=sb3p5rp3N69cAGdtRQOiboZ9KQ@mail.gmail.com>
To: Timothy Winters <tim@qacafe.com>
Cc: IPv6 Operations <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005af5fd05edf08464"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/4sLusT7LrosJOVykjrfcm-4NBtU>
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: Mon, 21 Nov 2022 00:55:54 -0000
I agree it's useful to recommend that CE routers hand out prefixes via DHCPv6 PD. Even my own network has this problem - the only fiber ISP that serves my apartment has a CE router that I can't replace, and it doesn't enable PD, which is limiting. That said - IIRC we discussed this in homenet and we decided that it was a bit tricky. Supporting one level of delegation is trivial, but hierarchical delegation is more difficult. What size should be supported? Do you rely on the downstream router hinting correctly? But how will the downstream router know how many routers are downstream of itself? That's why we ended up with the homenet protocol. This proposal solves that by making all routers turn on relay agents such that the topmost router hands out individual /64s. From an address management perspective this will work, I guess, but I see a couple of problems: 1. When a CE router gets a relayed PD request from a downstream interface, will it know what to do? In particular, will it know that it needs to route that prefix to the relay address and not to the client? There are CE routers that support DHCPv6 PD today, and I don't know how they will react. OTOH I don't know much about PD, so maybe this will just work? 2. If the topmost CE router gets handed a /64 by the ISP, and implements LPD-6, then the ISP will get relayed DHCPv6 requests. Do we think ISP relays and servers will deal with this correctly? I'd guess the correct response would be to respond with NoPrefixesAvail, but will they? On Fri, Nov 18, 2022 at 11:47 PM Timothy Winters <tim@qacafe.com> 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/ > > 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. > > ~Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > 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