Re: [v6ops] New Version Notification for draft-ietf-v6ops-dhcp-pd-per-device-05.txt

Nick Buraglio <buraglio@forwardingplane.net> Wed, 15 November 2023 15:04 UTC

Return-Path: <buraglio@forwardingplane.net>
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 <v6ops@ietfa.amsl.com>; 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 <v6ops@ietfa.amsl.com>; 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 <v6ops@ietf.org>; Wed, 15 Nov 2023 07:04:31 -0800 (PST)
Received: by mail-qt1-x832.google.com with SMTP id d75a77b69052e-41cda69486eso43102761cf.3 for <v6ops@ietf.org>; 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> <CAFU7BATnx3n2hPf5i2=9rH-gpV=oXkT6rxoQw2eQ9dY81mRNVw@mail.gmail.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 <buraglio@forwardingplane.net>
Date: Wed, 15 Nov 2023 09:04:18 -0600
Message-ID: <CACMsEX8k-VoU6mJuVhjPR5jGD3q5FaEBkqhAEbsyopZs-xvrrw@mail.gmail.com>
To: "Philipp S. Tiesel" <philipp@tiesel.net>
Cc: Martin Huněk <martin.hunek@tul.cz>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, Jen Linkova <furry13@gmail.com>, V6 Ops List <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004dc07e060a32382d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tQKsGJVPcDenRNjkftzOeJ1n3uM>
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 <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: Wed, 15 Nov 2023 15:04:40 -0000

On Wed, Nov 15, 2023 at 3:28 AM Philipp S. Tiesel <philipp@tiesel.net>
wrote:

> Hi,
>
> I mostly agree with Martin, my personal conclusion is:
>
> - I don’t 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…
> Don’t 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!
>   Philipp
>
>
> > On 12. Nov 2023, at 16:32, Martin Huněk <martin.hunek@tul.cz> wrote:
> >
> > 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 AAAA
> records for services behind the device (additional draft/RFC in the process)
> >
> > 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 for
> them or the risk of not complying with the local laws/regulations
> > 3) With PIO flags set to A=1, L=1, and P=1: As it is currently written,
> it increases the load on routers in case of peer-to-peer communication. The
> L flag is de facto ignored by PD clients as they are not locally reachable
> when not using SLAAC. To maintain local reachability, the operator needs to
> set 2 prefixes (one for SLAAC: A=1, L=1, P=0; the second virtual with A=x,
> L=x, P=1 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 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 address
> 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 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 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 and
> 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 signalling
> 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ěle 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 PM <internet-drafts@ietf.org> wrote:
> >>>
> >>> 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 in
> 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.txt
> >>> 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.html
> >>> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-dhcp-pd-per-device
> >>> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-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 via
> >>>   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
>