From furry13@gmail.com Tue Oct 10 23:27:23 2023 Return-Path: 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 0DCB8C14CE40 for ; Tue, 10 Oct 2023 23:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=gmail.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 Xd9L4aH7eyXh for ; Tue, 10 Oct 2023 23:27:19 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 3B83AC14CEFE for ; Tue, 10 Oct 2023 23:27:19 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2c15463ddd4so74371591fa.3 for ; Tue, 10 Oct 2023 23:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697005637; x=1697610437; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=a/qbhcNmh6CDj1F9HuiLWyqQmqvxq2iLwap7bcIQfgA=; b=AI9FCKxqIL15wntP14Hixu4fOLUzJKyVgBmK/JXxXncB/46r4NVvI0kdjYitbzPnxf DgsxHyqVDgZ1QHmB/Z1Dgg5jaGcDilp/D058GxR8fDZmGfJ3VC+66Vv0kqxxXJ5d8hdq bdupoj2Fj/WRlrOHjxROelxhniWlnrohbCEUkNXW6WyxsEP1kTLqvi4fF60fkrfNUAv2 WoJ1EMkDVdhoM8ChQX50/Hd3gDjqiBl7fiXiByKFQK858Gug1FuTof9cw2m8uKtYcplV 3z11vbMxWQMw3u9D7Dz44q2IeUq1U0jfQ7VQ587GejOI9e6yT1jZlcsHQbwITVhjAUvq 2WjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697005637; x=1697610437; h=content-transfer-encoding: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=a/qbhcNmh6CDj1F9HuiLWyqQmqvxq2iLwap7bcIQfgA=; b=VYk1yNAJoKbSPLRnp8O0w23JSgsw8LuzT9bFk64jpdcBKOLInD32dJh2GeFLyvzmHU bLlyq7RYbi7g5rmTgvtPRlkvUzk8e0Cgz/18NssntYPWv2us9fmlojRyP5OePel9Gemw NRyBgJWlfsvUtuRi/5rHDUffeqtvESrlVcsuq8wdYhatZsUzALyoWeF26+X58KgOwGdZ rNK6YHA5y1oAyRmlOtJuOyZgsNuTH4TyXRk21Tlx2XRVhbsZtV4i/G1CJSa7XntuDbhm 9k47nKH5ixx8EboWgB4yvAI91D3DYTGlHCBFPrHDhezp/qNYexB6XxCYSXYXlVEzSvD0 YVtw== X-Gm-Message-State: AOJu0YwqVQTb/27BS+h7+VJiw80dRqKz8E3vR9soLOqjS9hKK0pXRsb3 Aj0XOAWwboKsswFx6vvu1bB9BHRChpnu7lMDGaM= X-Google-Smtp-Source: AGHT+IFR4noXad4xCqMk92f8hIXr/S1W9fGJzy/AF/N+rXF5TM1iS5ARkNfvt7f7Y+Q7x6HevrZLnYrIMHGqlNj28Tk= X-Received: by 2002:a2e:b614:0:b0:2bc:f739:2eda with SMTP id r20-20020a2eb614000000b002bcf7392edamr17410342ljn.5.1697005636397; Tue, 10 Oct 2023 23:27:16 -0700 (PDT) MIME-Version: 1.0 References: <169660647031.23597.13067349132781805398@ietfa.amsl.com> <64e6fcde-ffd6-1051-415b-4326802842ff@joelhalpern.com> <016d23ac-02d5-d21a-256f-0ed605e377d2@gmail.com> <803b75b3-680e-ee9b-a3fa-7cbdf5abc407@gmail.com> In-Reply-To: <803b75b3-680e-ee9b-a3fa-7cbdf5abc407@gmail.com> From: Jen Linkova Date: Tue, 10 Oct 2023 23:27:05 -0700 Message-ID: To: Brian E Carpenter Cc: Joel Halpern , V6 Ops List , Lorenzo Colitti , Pascal Thubert , Vasilenko Eduard , Ole Troan , oselists@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Continuing WGLC: ietf-v6ops-dhcp-pd-per-device-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2023 06:27:23 -0000 Hi Brian, On Sun, Oct 8, 2023 at 1:06=E2=80=AFPM Brian E Carpenter wrote: > Reading it with the new Introduction, I have one remaining question: > To what extent is I-D.collink-6man-pio-pflag a requirement? The two > issues raised in section 11 ("Migration Strategies and Co-existence > with SLAAC Using Prefixes From PIO") suggest to me that if this draft > was a BCP, the new PIO flag would be at least a SHOULD. Since the draft > is labelled "Informational" there's no formal need to resolve this, > but should the language be strengthened somehow? As the draft is focusing on the network side and not on the client behavior, I-D.collink-6man-pio-pflag is not a requirement for the network. I'm deploying this in some parts of my enterprise network w/o P-flag, for RFC7084-like clients. P-flag is smth mobile endpoints implementing DHCPv6-PD client SHOULD support indeed. > >> A minor remark (not really suggesting a change): > >> > >>> 6.1. Prefix Pool Allocation > >> ... > >>> Other deployment models, such as prefix pools shared over multiple li= nks or routers, are possible, but not described in this document. > >> > >> This would in fact be a very obvious application for RFC 8992, a bit s= imilar to the scenario in appendix A.2 thereof. > > > > Oh interesting, thanks for the reference. I've not been following > > ANI-related work, to be honest - will read RFC 8992. > > > >> On 07-Oct-23 05:04, Joel Halpern wrote: > >>> Thank you. The introduction now seems to me quite clear, and lays ou= t > >>> the case for the procedures the draft introduces. I also appreciate = the > >>> caveats and clarifications in the Applicability and Limitations secti= on (5). > >>> > >>> Yours, > >>> > >>> Joel > >>> > >>> On 10/6/2023 11:48 AM, Jen Linkova wrote: > >>>> Dear v6ops WG, > >>>> > >>>> We have just submitted the -03 version for > >>>> ietf-v6ops-dhcp-pd-per-device - thank you very much to everyone who > >>>> provided feedback! > >>>> Please review and let us know if the draft is ready to progress. > >>>> > >>>> The main changes: > >>>> - Introduction is rewritten (much shorter and, hopefully, more clear= ) > >>>> - some text about multiple addresses use cases moved to Appendix. > >>>> - The Applicability and Limitation section is moved up, so it's in t= he > >>>> beginning - hopefully it would help the readers to understand what > >>>> scenarios are in scope and what are not. > >>>> - Client Mobility section added to discuss what happens when a clien= t > >>>> moves between network attachment points. > >>>> - the draft is now explicit that it focuses on "a pool per link" > >>>> scenario, which also drastically simplifies the routing and relay > >>>> requirements (the routing section is updated as well). > >>>> - the draft now suggests Active Leasequery as one of the mechanisms = to > >>>> keep the relay state in sync with the server. > >>>> - The Prefix Consideration section has been updated and states that > >>>> the endpoints are not required to use SLAAC - it's just the network > >>>> allows them to do that, if they need to. > >>>> - various changes to address other comments received during the WGLC= so far. > >>>> > >>>> I'd like to ask everyone who has expressed concerns during this WGLC > >>>> (you are in Cc: - hopefully I didn't miss anyone) to review the new > >>>> version and let the author know if you still have concerns. > >>>> > >>>> Thank you! > >>>> > >>>> On Fri, Oct 6, 2023 at 8:35=E2=80=AFAM wr= ote: > >>>>> Internet-Draft draft-ietf-v6ops-dhcp-pd-per-device-03.txt is now av= ailable. It > >>>>> is a work item of the IPv6 Operations (V6OPS) WG of the IETF. > >>>>> > >>>>> Title: Using DHCPv6-PD to Allocate Unique IPv6 Prefix per C= lient in Large Broadcast Networks > >>>>> Authors: Lorenzo Colitti > >>>>> Jen Linkova > >>>>> Xiao Ma > >>>>> Name: draft-ietf-v6ops-dhcp-pd-per-device-03.txt > >>>>> Pages: 18 > >>>>> Dates: 2023-10-06 > >>>>> > >>>>> Abstract: > >>>>> > >>>>> This document discusses an IPv6 deployment scenario when indi= vidual > >>>>> clients connected to large broadcast networks (such as enterp= rise > >>>>> networks or public Wi-Fi networks) are allocated unique prefi= xes via > >>>>> DHCPv6 Prefix Delegation (DHCPv6-PD). > >>>>> > >>>>> The IETF datatracker status page for this Internet-Draft is: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-devic= e/ > >>>>> > >>>>> There is also an HTML version available at: > >>>>> https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-device= -03.html > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-v6ops-dhcp-p= d-per-device-03 > >>>>> > >>>>> Internet-Drafts are also available by rsync at: > >>>>> rsync.ietf.org::internet-drafts > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> v6ops mailing list > >>>>> v6ops@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/v6ops > >>>> > >>>> > > > > > > --=20 SY, Jen Linkova aka Furry