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

[Martin Huněk <[e-mail]>]

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
> >
> >
> 
> 
>