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

[Jen Linkova <[e-mail]>]

Hi Martin,

On Fri, Dec 16, 2022 at 9:26 PM Martin Huněk <[e-mail]> wrote:

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

Oh sorry, it's a leftover from the template I used. Will be fixed in
the next version. Good catch, thanks.

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

/32 or /29 was for ~8k sites with 64 segments per site (so ~500K
segments). I doubt a customer of that size would get a single /48.

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

Maybe that organization can ask their LIR for another /48? Maybe they
can use PD not on all segments but only on wireless ones, where the
problem of multiple addresses is more visible? Or maybe they decide
not to do it, waiting for LIRs to read this draft and adjust their
policy?

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

OK, I think we need to add more text on this topic to the next version
of the draft, as it's not the first time readers miss it.
The proposed design is suitable for the large networks, where ND
scalability is an issue. The home networks with /56 delegated to CPEs
is out of scope, and indeed the device shouldn't request a prefix in
this case.
That's why a new flag is proposed, so the network can signal to hosts
if they should be using SLAAC or PD.  Section 8 explicitly states but
I assume we should make it more clear.

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

I really doubt that we can converge on a specific number. The benefit
of /64 is that after the prefix is received, everything else can
function as if it were a SLAAC prefix (address assignments etc).

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

Because the whole idea of this proposal is to ensure that the host
uses the delegated /64 to form addresses. That way it can form many
addresses w/o any scalability implications for the network.
If the host instead keeps using the PIO to form new addresses, we just
wasted the delegated /64.
Do you think more clarifying text is needed?

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

Then we are back to having the problem we are trying to solve (also
described in https://www.ietf.org/archive/id/draft-linkova-v6ops-ipmaclimi-00.html):
multiple addresses per host are 1)expensive for the network 2)are not
guaranteed to work.

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

Sorry, I'm not sure I understand this statement. What I'm trying to say here is:
- in a "traditional" SLAAC network (shared /64 for hosts), if a host
has 10 addresses, it would consume 10 times more network resources
- in the proposed design the number of addresses per host doesn't
matter: the scalability factor is O(n), where n is the number of
hosts, as each host would have 1 route and one ND entry.

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

The device is not becoming a router (well, maybe you mean smth
different by 'becoming 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?

What is happening currently is much worse. You randomly lose
connection to the host, or to some virtual machines etc.
Intermittent failures are the worst. First, they are hard to
troubleshoot and they impact user experience dramatically. Secondly -
and that's the most important part - they are much harder to detect
and therefore fix.
Those kinds of things are quietly waiting for network engineers who
naively believe that if they have been running dual-stack networks for
years, IPv6 is working...Nope..

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

The criteria is not 'is this a router or not', but 'how many addresses
does the device need?'.
As I've mentioned before, ChromeOS is running multiple virtual
instances and switching IPv6 traffic.
My workstation has 10 addresses even w/o any virtualisation enabled.
I want to find a consensus between letting devices use multiple
addresses and not upgrading my VXLAN devices so they can support 10
times more routes.

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

Please keep in mind that those organizations do not need to enable PD
if they don't need/want to (e.g. if they do not have any scalability
issues with 10 addresses per device).
However if they see the benefits and believe that it's worth it - they could.
We are describing a design which has some merits for some networks.
Maybe later the networks which do not need it now change their minds..

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


--
SY, Jen Linkova aka Furry