Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

[Vasilenko Eduard <[e-mail]>]

Hi Martin,
Would you have the same concern if DHCP-PD would delegate /96 to every host in the future?
It is an excellent alternative to shut down SLAAC in the far future. The majority of IPv6 problems are revolving around SLAAC.
Eduard
-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Martin Hunek
Sent: Friday, December 16, 2022 1:26 PM
To: V6 Ops List <[e-mail]>; Jen Linkova <[e-mail]>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

Hello,

Even though this proposal has some merit, and it might be useful for some applications (tethering, virtualization, docker, ...), it is certainly not suitable for most devices. For this reason, I think it should not aim for "Best Current Practise" but, at the most, for "Informational" status.

In the introduction, you state that the client needs at least eight addresses even now. However, there is still a difference between 8 addresses and 2^64. Furthermore, even in IPv6, there are simply not enough addresses to cover it - not with current rules, anyway.

In chapter 4, you state that /32 should be enough. However, most organizations would not have /32. Organization != LIR. I do understand that large content providers, ISP, and some other big actors are LIRs, but not every big enterprise need to do business in the Internet domain. Such organizations would gain no benefit in becoming LIR. Because of the IPv4 shortage, we have all moved into a mindset where everyone needs to be an LIR to get address space. This is not true, or at least it should not be true. An LIR is a subject that gets an address space from RIR and assigns it to its customer. Back in the day, even ISPs were not LIRs.

In the RIPE region, a customer should be given at most /48 - if you want to assign more than that, it has to be authorized. The maximum /48 is less than your requirement of /32 or even /29 stated in chapter 4.

If you need examples of such enterprises, I do have two:

The first organization is a university. It does have former class B /16 IPv4 assignment and /48 IPv6 assignment. It actively uses about 100 VLANs and uses SLAAC mostly because it has been an early IPv6 adopter and now because of one mobile phone OS vendor (no DHCPv6 support). The university is slowly running out of IPv4 space as it is not using NAT. Also, it is not using DHCPv6-PD as network policy forbids connecting routers to its network. If all the devices started requiring /64 via PD, the university would be in the same situation as it is in IPv4 (64 - 48 = 16, which is the same as in IPv4 32 - 16 = 16).

The second organization is a small ISP. It has got /29 from RIPE. It has three geographical areas each /32. In every area, every POP has got /40. In every POP, every VLAN has got /48 (/64 for SLAAC, rest for PD). On every VLAN, there are /56s for customers via PD. This gives every customer, in theory, the possibility to assign 256 networks. That is enough for all residential customers right now. However, if the customer is using network segmentation (wired, wireless, guests, mgmt, reserve) and every device would require /64, it would easily limit the customer to 32 devices per VLAN. This is not sufficient. You may argue that ISP can allocate more. That would be true, but do you expect that ISPs would be willing to renumber the whole network?

In chapter 6, you state that the minimum prefix-length hint should be 64. I don't think that there is such a universal minimum value. The device (router) should request prefix length so it can saturate its need for addresses. If it is using the SLAAC, it is the /64 for VLAN, but it may have more than one VLAN. If it is using DHCPv6, it may request less than /64. It depends on the number of interfaces and autoconfiguration method in use.

In chapter 8, you wrote: "When the network supports both /64 per host and SLAAC as address assignment methods, it's highly desirable for the host NOT to use SLAAC and only use the prefix delegated via DHCPv6-PD. " Why?

If the device is, for example, a phone doing tethering, it would have two interfaces: up-facing rmnet0 and down-facing wlan0. What is wrong about the rmnet0 having SLAAC configured or DHCPv6 configured address on it, while routed network segment or wlan0 having DHCPv6-PD obtained prefix? How does it differ from what are routers doing nowadays? The same goes for virtualization or containers. If the device is routing, it is a router, so it should act like one. If it is not routing and it is bridging, then it is a bridge and should act like one. Furthermore, if it is a bridge, it should just act as transparent and forward ND packets and DHCPv6 packets like any other bridge. There is no need for anything in between.

In chapter 9, it is stated:

"The network needs to scale to the number of devices" with /64 per device; it scales worse than with /128 per device. This is the fact as it is limited by prefix length.

"The cost of having multiple addresses is offloaded to the endpoint. Devices are free to create and use as many addresses as they need" for the cost that every device becomes a router.

"Fate sharing: all global addresses used by a given device are routed as a single /64. Either all of them work or not, which makes the failures easier to diagnoze and mitigate" Is it really better to lose connection also for the virtualization host?

Chapter 10: The DHCPv6-PD is not an alternative to SLAAC the DHCPv6 is. This is just moving the router functionality into the client device, and auto-config has to be used inside it.

Let me be clear that I have nothing against a client asking about PD when it has a need for it - when it is routing traffic. So if it has an independent L3 network segment connected to it and it needs to provide Internet access to it, then it is fine by me. However, if every device would ask PD automatically regardless being router or not, that would create quite a mess. This draft actually scares me as a network administrator of the large non-LIR network and also as a netadmin of the small ISP. In both cases, either organization or customers would run out of IPv6 addresses. It is effectively dividing address length by 2.

Sincerely,
Martin Hunek

Dne čtvrtek 15. prosince 2022 4:59:33 CET, Jen Linkova napsal(a):
> Hello,
> 
> We've just submitted -01 version of draft-collink-v6ops-ent64pd, which 
> proposes using DHCPv6-PD to delete /64 per host (the draft was very 
> briefly presented at the last IETF).
> 
> Comments and suggestions are welcome!
> 
> 
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Thu, Dec 15, 2022 at 2:39 PM
> Subject: New Version Notification for 
> draft-collink-v6ops-ent64pd-01.txt
> To: Jen Linkova <[e-mail]>, Lorenzo Colitti 
> <[e-mail]>, Xiao Ma <[e-mail]>
> 
> 
> 
> A new version of I-D, draft-collink-v6ops-ent64pd-01.txt
> has been successfully submitted by Jen Linkova and posted to the IETF 
> repository.
> 
> Name:           draft-collink-v6ops-ent64pd
> Revision:       01
> Title:          Using DHCP-PD to Allocate /64 per Host in Broadcast Networks
> Document date:  2022-12-14
> Group:          Individual Submission
> Pages:          11
> URL:
> https://www.ietf.org/archive/id/draft-collink-v6ops-ent64pd-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-collink-v6ops-ent64pd/
> Html:
> https://www.ietf.org/archive/id/draft-collink-v6ops-ent64pd-01.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-collink-v6ops-ent64pd
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-collink-v6ops-ent64pd-
> 01
> 
> Abstract:
>    This document discusses the IPv6 deployment scenario when individual
>    hosts connected to broadcast networks (like WiFi hotspots or
>    enterprise networks) are allocated /64 subnets via DHCP-PD.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
>