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

[Nick Buraglio <[e-mail]>]

On Wed, Nov 15, 2023 at 3:28 AM Philipp S. Tiesel <[e-mail]>
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 <[e-mail]> 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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> AVE!
>    Philipp S. Tiesel
>
> --
> Philipp S. Tiesel
> https://philipp.tiesel.net/
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>