From buraglio@forwardingplane.net Wed Nov 15 07:04:40 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 1F087C151065 for ; Wed, 15 Nov 2023 07:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.106 X-Spam-Level: X-Spam-Status: No, score=-7.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forwardingplane.net 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 B53Ne5x7-3bI for ; Wed, 15 Nov 2023 07:04:36 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 49055C14CE29 for ; Wed, 15 Nov 2023 07:04:31 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id d75a77b69052e-41cda69486eso43102761cf.3 for ; Wed, 15 Nov 2023 07:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forwardingplane.net; s=google; t=1700060670; x=1700665470; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8k/NGwMqTu3Ka1zaHHHQrnI5Ej8esMo+vyjCbEhHMEI=; b=xEloqclFixLTK4sYt2iMz34rg3PpUnZK6ydU9/0oYMpwJApwq/kN/sv6E/K1OkBZ8U c8SM9rhrV7f1hqHpZMUZPmwLmt8gzIdtofYpdeopkQBclZ/7TASvkr6dsx5jtlDwBFg3 p84+dbN42ON1t+GvgM5xienhCosisj1eVeQ50= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700060670; x=1700665470; 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=8k/NGwMqTu3Ka1zaHHHQrnI5Ej8esMo+vyjCbEhHMEI=; b=pX+okRxkg6Wvarluy+8qIzjymLzCyuxkFy99yKdlu8XiP1wbihUVkhOKy8+7ZE5r64 xXAaexEqEYC+kbb9yK/RN/7eTS/89VflbXustvQDzEoCqQdSWs6y+tuZ/xB2bgiPp0ZB XcBb7LR+Dt/pjWvjoUbv6kyT0gjqVDHrWFhk9xlv0LggrU15Gk7O9UtnDi6irw0b954W x7qBOcD6ZqmJwd+tFlWZLdBiB9CDUnQS7D3PnnhmMLJyFdRIsgsLdvhxDaq/wUZHIOl7 y5LhPsG6Q+NhfHdRkOKEHyRoNTxzilah4YARt8CHg91g2YhacyUAB0X8la9ULH0joprG P4Aw== X-Gm-Message-State: AOJu0YzHwSdGZN0SYv8YEXTJUPmOV1XzrzSRAfejgEumzEN/YUaq5PHX sApQj0iGJCKZ+KYLTW59Y8u5CjsquB7En2EmYnAOng== X-Google-Smtp-Source: AGHT+IECmS/0hR3I7TRdDQAzS2lrLKPmrVea/ECwMT5t253HMYL6UCdpG2E3Wj85z+5YOrlX1BVv3TLiqNvwSnCH16w= X-Received: by 2002:a05:622a:215:b0:41c:c23e:74fb with SMTP id b21-20020a05622a021500b0041cc23e74fbmr6800621qtx.20.1700060669513; Wed, 15 Nov 2023 07:04:29 -0800 (PST) MIME-Version: 1.0 References: <169919966581.36738.5162400304409089286@ietfa.amsl.com> <4350734.1mFrItZxnq@asclepius.adm.tul.cz> <34387704-A89A-41BD-8F6D-27CF1E2C4122@tiesel.net> In-Reply-To: <34387704-A89A-41BD-8F6D-27CF1E2C4122@tiesel.net> From: Nick Buraglio Date: Wed, 15 Nov 2023 09:04:18 -0600 Message-ID: To: "Philipp S. Tiesel" Cc: =?UTF-8?Q?Martin_Hun=C4=9Bk?= , Lorenzo Colitti , Jen Linkova , V6 Ops List Content-Type: multipart/alternative; boundary="0000000000004dc07e060a32382d" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-ietf-v6ops-dhcp-pd-per-device-05.txt 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, 15 Nov 2023 15:04:40 -0000 --0000000000004dc07e060a32382d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 15, 2023 at 3:28=E2=80=AFAM Philipp S. Tiesel wrote: > Hi, > > I mostly agree with Martin, my personal conclusion is: > > - I don=E2=80=99t think progressing this draft to publication is harmful. > > - The nail-down to "Brian-/64" makes it much less useful than it could be > and > will harm IPv6 deployment outside large / highly capable organisations > for many years. > > - Changing it to /80 (or 2^16 /96 if delegating hierarchal within the > host) > would solve the the VMs / containers addressing problem in a few month, > but break the general Tethered Device story that is particularly > appealing for Android. > > - The proposed way to provide SLAAC on /80 and thus turn "Brian-/64 into > /80 > will take 3+ years to become available and > > > What does this boil down to in examples? > > Can my sponsor/employer live with /64 per device? > Most probably yes > > Could my community ISP deploy /64 per device in WiFi-HotSpots? > Yes, but only because we are LIR and pretty small. > > Could a medium-sized enterprise deploy /64 per device? > Most probably no. > These two assessments are enlightening, thank you for sending them, I enjoyed reading them. They sparked a few thoughts, somewhat related but more anecdotal than anything else. Part of the ambiguity here, I think, is how the sizes are defined. There has been a fair bit of discussion on "waste" of IPv6 space, and I believe that is related to how different perspectives define the sizing buckets. For example, The international supercomputing conference is happening right now - they have ~8k wireless clients associated as of yesterday. 8k clients sounds fairly small to me, but even with <1k clients, there were notable, almost show stopping issues that were uncovered on the ipv6-mostly network that were pretty much exclusively related to neighbor discovery and RA. This draft would have solved that issue as this problem becomes *glaringly* apparent without IPv4 around to paint over the cracks in a network where IPv6 may be problematic due to NDP issues. I guarantee we will start seeing more and more of this as running without legacy IP becomes more and more common. Given that the conference has a /48 (65,536 /64s), that would have used - liberally - a /50. To me that does not seem a waste since the majority of the client use is wireless but perhaps I look at it differently. Given that each "booth drop", of which there are ~200 representing a client or customer, that leaves aggregated three more /50s. Take now the example of a very large university where I used to work. They peak at 66k wireless clients and have only a /44. The same issues exist there with neighbor tables. They have the luxury of dedicating multiple entire /48 to wifi if they want to and still have more than enough to give reasonable blocks to their ~380 buildings and still aggregate, but I don't consider them "small", even if they have a smaller PI allocation. Sizing and waste is all subjective and very relative to the perspective of a given person. One could probably argue that a /64 per organization is *technically* a "waste" because it contains 18,446,744,073,709,551,616 addresses, but we all know the operational realities of that don't really make sense. As a further example, I had an ISP recently propose that they wanted to hand out /127s to customers like they do /31 for IPv4 and they could not understand the reasoning for giving each business customer a /48 and each residential customer a /56 because it was a "waste", even though they have *two* /32 PI blocks. Again, perspective. The intention isn't one-size fits all. While I do think it is an interesting thought exercise to look at SLAAC on a /80, to me it seems like a better use of resources to adjust allocation policy to reflect updated operational realities. > > > So the question has become whether with WG wants to pass documents that > are useful, > but only feasible for big or highly capable players only. > Do we want to exclude many useful cases in order to protect one other > use-case (Tethered Devices)? > > Community and the Internet is about compromise and keeping the ecosystem > pluralistic=E2=80=A6 > Don=E2=80=99t count me agains progressing the draft but I would love to s= ee the > authors > truly supporting SLAAC on /80 to make pd-per-device available to others a= s > well. > I want to be convinced SLAAC on /80 is not just an excuse. > > AVE! > Philipp > > > > On 12. Nov 2023, at 16:32, Martin Hun=C4=9Bk wrot= e: > > > > Hi folks, > > > > After meeting the authors, the WG chair, and the document Shepard, I > would like to express my current stance concerning this draft. > > > > First of all, I would like to say thank you all for a long, in-depth, > but friendly discussion. > > > > Personally, I see those Pros: > > - It solves problems caused by devices having too many addresses (like > virtualization with separate L3 segment with ND proxy or specifically > Google ChromeOS devices having 20+ addresses) > > - When addresses are grouped into a single prefix, they are easier to > track by the network operator > > - The client/host is able to use as many addresses in the single prefix > as it wants without the side effects on the rest of the network > > - When the used addresses are registered, I could allow to maintain AAA= A > records for services behind the device (additional draft/RFC in the proce= ss) > > > > Risks for the network operators: > > 1) The loss of the ability to differentiate between Routers extending > the network outside of the device itself (currently using DHCPv6-PD) and > hosts > > 2) The ability of network extension outside a single device might be > unwanted in enterprise-style networks and may introduce security risks fo= r > them or the risk of not complying with the local laws/regulations > > 3) With PIO flags set to A=3D1, L=3D1, and P=3D1: As it is currently wr= itten, > it increases the load on routers in case of peer-to-peer communication. T= he > L flag is de facto ignored by PD clients as they are not locally reachabl= e > when not using SLAAC. To maintain local reachability, the operator needs = to > set 2 prefixes (one for SLAAC: A=3D1, L=3D1, P=3D0; the second virtual wi= th A=3Dx, > L=3Dx, P=3D1 where x is preferably 0 but would work with 1 too). > > 4) As the proposed method is not usable for every network, it MUST NOT > be viewed as a replacement of the SLAAC (I've been told that it is not th= e > case by authors and WG chair - so no problem) > > > > Cons: > > 1) The requirement of SLAAC ability (/64 per device) is unnecessary and > makes this method unusable for the address-space constraint networks > > 2) Address plans of the early adopters had to be changed > > 3) It causes pressure on network operators to provide additional addres= s > space while simple network space extension doesn't have to be possible. > This produces additional pressure on LIRs and could also lead to RIRs > policy changes > > 4) The P flag draft should be the Normative reference > > > > There is no need for the requirement in section 7, 2nd point. Some > implementations may not depend on internal SLAAC use. They can use > proprietary algorithms to generate addresses with shorter IID or the DHCP= v6 > IA_NA. For such devices, it is OK to ask for less than /64 currently need= ed > for SLAAC autoconfiguration. If the client asks for less than /64, there = is > no point for the server to MUST give at least SLAAC usable prefix. It > should be able to provide what the client asked for, while it can provide > more. That is why I can see the Con 1). > > > > There is no harm in the client indicating that it needs less than/64 an= d > for the server to honor such a request. Such signaling is possible by the > "prefix-length hint" field. > > > > However, I see the reasoning why the network SHOULD expect that the > prefix requested by the client will be /64 as there probably will be the > majority of the devices asking for the /64. > > > > Con 2) is a minor problem, but it could cause additional work for early > adopters and could be seen as a sign of the immaturity of IPv6 addressing > philosophy. > > > > The con 3) is the situation I'm currently facing as the network > administrator of the university network, having just /48. It is specific = to > some networks, so I'm just stating that it could be a problem for some > networks. > > > > The Con 4): One thing I've just realized is that the draft in 6man > (pio-pflag) is not a normative reference. However, this seems an integral > part of the method as it describes both client behaviour and network > signalling. As the 6man draft has a direct effect on how this draft > behaves, it should probably be published together with the draft in 6man > with a proper normative cross-reference. > > > > The major risks I can see with the draft are the numbers 1 and 2. While > I, as the "enterprise-style" network administrator, would be OK with the > client asking for a prefix to run containers or VMs, I would not want to > give a prefix to a Wi-Fi router extending my network (possibly without > required security). Not to mention other adverse effects that unmanaged > Wi-Fi routers have on the spectrum and so on. I think that this concern > must be solved, but not necessary here in this document. I know that I > cannot guarantee this in IPv4, but this document doesn't talk about IPv4. > IPv6 could solve the issues that IPv4 does not. > > > > As I've been told that this is not here to replace SLAAC in the future > for those networks that could not use this, I'm less worried about this > draft. Apart from the unnecessary MUST in section 7 and missing signallin= g > of the client's intent to extend the network to an external interface, I'= m > reasonably fine with it. However, without that missing signalling (and > getting more address space from my upstream), I don't see the possibility > of using it in my network now. > > > > Once again, thank you all for your time and informative discussion. > > > > Regards, > > Martin > > > > Dne ned=C4=9Ble 5. listopadu 2023 17:17:13 CET, Jen Linkova napsal(a): > >> Hello, > >> > >> Following the conclusion of the WGLC (thanks to everyone who > >> commented!), we've submitted a -05 version with the following changes: > >> 1. Making it more clear that the draft requires the network to > >> delegate a SLAAC-suitable prefix, and /64 is currently required for > >> SLAAC to work - but it doesn't have to be like that in the future. > >> Examples also use /64. Brian, does it address your comment? > >> 2. To address most of Ole's comments: > >> 2.1 Making it explicit that the draft only covers the network > >> behavior, while host requirements are out of scope. > >> 2.2 Clarifying that the network can support both flat and > >> hierarchical models - it's up to the host to specify the hint. > >> 3. Rewriting examples in the prefix length consideration section to > >> make it clearer that the proposal does not require an excessive amount > >> of IPv6 space. > >> > >> > >> > >> On Sun, Nov 5, 2023 at 4:54=E2=80=AFPM wrot= e: > >>> > >>> A new version of Internet-Draft > draft-ietf-v6ops-dhcp-pd-per-device-05.txt has > >>> been successfully submitted by Jen Linkova and posted to the > >>> IETF repository. > >>> > >>> Name: draft-ietf-v6ops-dhcp-pd-per-device > >>> Revision: 05 > >>> Title: Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client i= n > Large Broadcast Networks > >>> Date: 2023-11-05 > >>> Group: v6ops > >>> Pages: 20 > >>> URL: > https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-device-05.tx= t > >>> Status: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-device/ > >>> HTML: > https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-device-05.ht= ml > >>> HTMLized: > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcp-pd-per-device > >>> Diff: > https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-v6ops-dhcp-pd-per-= device-05 > >>> > >>> Abstract: > >>> > >>> This document discusses an IPv6 deployment scenario when individual > >>> clients connected to large broadcast networks (such as enterprise > >>> networks or public Wi-Fi networks) are allocated unique prefixes vi= a > >>> DHCPv6 Prefix Delegation (DHCPv6-PD). > >>> > >>> > >>> > >>> The IETF Secretariat > >>> > >>> > >> > >> > >> > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > AVE! > Philipp S. Tiesel > > -- > Philipp S. Tiesel > https://philipp.tiesel.net/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000004dc07e060a32382d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 15, 2023 at 3:28=E2=80=AF= AM Philipp S. Tiesel <philipp@ties= el.net> wrote:
Hi,

I mostly agree with Martin, my personal conclusion is:

- I don=E2=80=99t think progressing this draft to publication is harmful.
- The nail-down to "Brian-/64" makes it much less useful than it = could be and
=C2=A0 will harm IPv6 deployment outside large / highly capable organisatio= ns for many years.

- Changing it to /80 (or 2^16 /96 if delegating hierarchal within the host)=
=C2=A0 would solve the the VMs / containers addressing problem in a few mon= th,
=C2=A0 but break the general Tethered Device story that is particularly app= ealing for Android.

- The proposed way to provide SLAAC on /80 and thus turn "Brian-/64 in= to /80
=C2=A0 will take 3+ years to become available and


What does this boil down to in examples?

Can my sponsor/employer live with /64 per device?
=C2=A0 =C2=A0Most probably yes

Could my community ISP deploy /64 per device in WiFi-HotSpots?
=C2=A0 =C2=A0Yes, but only because we are LIR and pretty small.

Could a medium-sized enterprise deploy /64 per device?
=C2=A0 =C2=A0Most probably no.

These tw= o assessments are enlightening, thank=C2=A0you for sending them,=C2=A0I enj= oyed reading them. They sparked a few thoughts, somewhat related but more a= necdotal than anything else.=C2=A0

Part of the amb= iguity here, I think, is how the sizes are defined. There has been a fair b= it of discussion on "waste" of IPv6 space, and I believe that is = related to how different perspectives define the sizing buckets. For exampl= e, The international supercomputing conference is happening right now - the= y have ~8k wireless clients associated as of yesterday. 8k clients sounds f= airly small to me, but even with <1k clients, there were notable, almost= show stopping issues that were uncovered on the ipv6-mostly network that w= ere pretty much exclusively related to neighbor discovery and RA.=C2=A0
This draft would have solved that issue as this problem becomes <= i>glaringly apparent without IPv4 around to paint over the cracks i= n a network where IPv6 may be problematic due to NDP issues. I guarantee we= will start seeing more and more of this as running without legacy IP becom= es more and more common.=C2=A0
=C2=A0
Given that th= e conference has a /48 (65,536 /64s), that would have used - liberally - a = /50. To me that does not seem a waste since the majority of the client use = is wireless but perhaps I look at it differently. Given that each "boo= th drop", of which there are=C2=A0~200 representing a client or custom= er, that leaves aggregated three more /50s.=C2=A0 =C2=A0

Take now the example of a very large university where I used to work= . They peak at 66k wireless clients and have only a /44. The same issues ex= ist there with neighbor tables. They have the luxury of dedicating multiple= entire /48 to wifi if they want to and=C2=A0still have more than enough to= give reasonable blocks to their ~380 buildings and still aggregate,=C2=A0b= ut I don't consider them "small", even if they have a smaller= PI allocation.=C2=A0

Sizing and waste is all subj= ective and very relative to the perspective of a given person. One could pr= obably argue that a /64 per organization is technically a "wast= e" because it contains=C2=A018,446,744,073,709,551= ,616 addresses, but we all know the=C2=A0operational realities of that don&= #39;t really make=C2=A0sense.=C2=A0
As= a further example, I had an ISP recently propose that they wanted to hand = out /127s to customers like they do /31 for IPv4 and they could not underst= and the reasoning for giving each business customer a /48 and each resident= ial customer a /56 because it was a "waste", even though they hav= e two /32 PI blocks.
Again, per= spective. The intention isn't one-size fits all.=C2=A0 While I do think= it is an interesting thought exercise to look at SLAAC on a /80, to me it = seems like a better use of resources to adjust allocation policy to reflect= updated operational realities.=C2=A0


<= /div>
=C2=A0

=C2=A0


So the question has become whether with WG wants to pass documents that are= useful,
but only feasible for big or highly capable players only.
Do we want to exclude many useful cases in order to protect one other use-c= ase (Tethered Devices)?

Community and the Internet is about compromise and keeping the ecosystem pl= uralistic=E2=80=A6
Don=E2=80=99t count me agains progressing the draft but I would love to see= the authors
truly supporting SLAAC on /80 to make pd-per-device available to others as = well.
I want to be convinced SLAAC on /80 is not just an excuse.

AVE!
=C2=A0 Philipp=C2=A0


> On 12. Nov 2023, at 16:32, Martin Hun=C4=9Bk <martin.hunek@tul.cz> wrote:
>
> Hi folks,
>
> After meeting the authors, the WG chair, and the document Shepard, I w= ould like to express my current stance concerning this draft.
>
> First of all, I would like to say thank you all for a long, in-depth, = but friendly discussion.
>
> Personally, I see those Pros:
> - It solves problems caused by devices having too many addresses (like= virtualization with separate L3 segment with ND proxy or specifically Goog= le ChromeOS devices having 20+ addresses)
> - When addresses are grouped into a single prefix, they are easier to = track by the network operator
> - The client/host is able to use as many addresses in the single prefi= x as it wants without the side effects on the rest of the network
> - When the used addresses are registered, I could allow to maintain AA= AA records for services behind the device (additional draft/RFC in the proc= ess)
>
> Risks for the network operators:
> 1) The loss of the ability to differentiate between Routers extending = the network outside of the device itself (currently using DHCPv6-PD) and ho= sts
> 2) The ability of network extension outside a single device might be u= nwanted in enterprise-style networks and may introduce security risks for t= hem or the risk of not complying with the local laws/regulations
> 3) With PIO flags set to A=3D1, L=3D1, and P=3D1: As it is currently w= ritten, it increases the load on routers in case of peer-to-peer communicat= ion. The L flag is de facto ignored by PD clients as they are not locally r= eachable when not using SLAAC. To maintain local reachability, the operator= needs to set 2 prefixes (one for SLAAC: A=3D1, L=3D1, P=3D0; the second vi= rtual with A=3Dx, L=3Dx, P=3D1 where x is preferably 0 but would work with = 1 too).
> 4) As the proposed method is not usable for every network, it MUST NOT= be viewed as a replacement of the SLAAC (I've been told that it is not= the case by authors and WG chair - so no problem)
>
> Cons:
> 1) The requirement of SLAAC ability (/64 per device) is unnecessary an= d makes this method unusable for the address-space constraint networks
> 2) Address plans of the early adopters had to be changed
> 3) It causes pressure on network operators to provide additional addre= ss space while simple network space extension doesn't have to be possib= le. This produces additional pressure on LIRs and could also lead to RIRs p= olicy changes
> 4) The P flag draft should be the Normative reference
>
> There is no need for the requirement in section 7, 2nd point. Some imp= lementations may not depend on internal SLAAC use. They can use proprietary= algorithms to generate addresses with shorter IID or the DHCPv6 IA_NA. For= such devices, it is OK to ask for less than /64 currently needed for SLAAC= autoconfiguration. If the client asks for less than /64, there is no point= for the server to MUST give at least SLAAC usable prefix. It should be abl= e to provide what the client asked for, while it can provide more. That is = why I can see the Con 1).
>
> There is no harm in the client indicating that it needs less than/64 a= nd for the server to honor such a request. Such signaling is possible by th= e "prefix-length hint" field.
>
> However, I see the reasoning why the network SHOULD expect that the pr= efix requested by the client will be /64 as there probably will be the majo= rity of the devices asking for the /64.
>
> Con 2) is a minor problem, but it could cause additional work for earl= y adopters and could be seen as a sign of the immaturity of IPv6 addressing= philosophy.
>
> The con 3) is the situation I'm currently facing as the network ad= ministrator of the university network, having just /48. It is specific to s= ome networks, so I'm just stating that it could be a problem for some n= etworks.
>
> The Con 4): One thing I've just realized is that the draft in 6man= (pio-pflag) is not a normative reference. However, this seems an integral = part of the method as it describes both client behaviour and network signal= ling. As the 6man draft has a direct effect on how this draft behaves, it s= hould probably be published together with the draft in 6man with a proper n= ormative cross-reference.
>
> The major risks I can see with the draft are the numbers 1 and 2. Whil= e I, as the "enterprise-style" network administrator, would be OK= with the client asking for a prefix to run containers or VMs, I would not = want to give a prefix to a Wi-Fi router extending my network (possibly with= out required security). Not to mention other adverse effects that unmanaged= Wi-Fi routers have on the spectrum and so on. I think that this concern mu= st be solved, but not necessary here in this document. I know that I cannot= guarantee this in IPv4, but this document doesn't talk about IPv4. IPv= 6 could solve the issues that IPv4 does not.
>
> As I've been told that this is not here to replace SLAAC in the fu= ture for those networks that could not use this, I'm less worried about= this draft. Apart from the unnecessary MUST in section 7 and missing signa= lling of the client's intent to extend the network to an external inter= face, I'm reasonably fine with it. However, without that missing signal= ling (and getting more address space from my upstream), I don't see the= possibility of using it in my network now.
>
> Once again, thank you all for your time and informative discussion. >
> Regards,
> Martin
>
> Dne ned=C4=9Ble 5. listopadu 2023 17:17:13 CET, Jen Linkova napsal(a):=
>> Hello,
>>
>> Following the conclusion of the WGLC (thanks to everyone who
>> commented!), we've submitted a -05 version with the following = changes:
>> 1. Making it more clear that the draft requires the network to
>> delegate a SLAAC-suitable prefix, and /64 is currently required fo= r
>> SLAAC to work - but it=C2=A0 doesn't have to be like that in t= he future.
>> Examples also use /64. Brian, does it address your comment?
>> 2. To address most of Ole's comments:
>>=C2=A0 2.1 Making it explicit that the draft only covers the networ= k
>> behavior, while host requirements are out of scope.
>>=C2=A0 2.2 Clarifying that the network can support both flat and >> hierarchical models - it's up to the host to specify the hint.=
>> 3. Rewriting examples in the prefix length consideration section t= o
>> make it clearer that the proposal does not require an excessive am= ount
>> of IPv6 space.
>>
>>
>>
>> On Sun, Nov 5, 2023 at 4:54=E2=80=AFPM <internet-drafts@ietf.org> wro= te:
>>>
>>> A new version of Internet-Draft draft-ietf-v6ops-dhcp-pd-per-d= evice-05.txt has
>>> been successfully submitted by Jen Linkova and posted to the >>> IETF repository.
>>>
>>> Name:=C2=A0 =C2=A0 =C2=A0draft-ietf-v6ops-dhcp-pd-per-device >>> Revision: 05
>>> Title:=C2=A0 =C2=A0 Using DHCPv6-PD to Allocate Unique IPv6 Pr= efix per Client in Large Broadcast Networks
>>> Date:=C2=A0 =C2=A0 =C2=A02023-11-05
>>> Group:=C2=A0 =C2=A0 v6ops
>>> Pages:=C2=A0 =C2=A0 20
>>> URL:=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-de= vice-05.txt
>>> Status:=C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-device/=
>>> HTML:=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/archive/id/draft-ietf-v6ops-dhcp-pd-per-d= evice-05.html
>>> HTMLized: http= s://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcp-pd-per-device >>> Diff:=C2=A0 =C2=A0 =C2=A0https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-= v6ops-dhcp-pd-per-device-05
>>>
>>> Abstract:
>>>
>>>=C2=A0 =C2=A0This document discusses an IPv6 deployment scenari= o when individual
>>>=C2=A0 =C2=A0clients connected to large broadcast networks (suc= h as enterprise
>>>=C2=A0 =C2=A0networks or public Wi-Fi networks) are allocated u= nique prefixes via
>>>=C2=A0 =C2=A0DHCPv6 Prefix Delegation (DHCPv6-PD).
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>>
>>
>>
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops



AVE!
=C2=A0 =C2=A0Philipp S. Tiesel

--=C2=A0
Philipp S. Tiesel
https://philipp.tiesel.net/

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000004dc07e060a32382d--