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

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

Hi Jen,

Dne úterý 20. prosince 2022 9:58:18 CET, Jen Linkova napsal(a):
> 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.

I'm glad that it is just left over. This is actually one of my main issues with this document. It scared me that every device on my network should be recommended to ask for /64 PD as it is the "best" way (BCP). :-)
> 
> > 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.

However, this is the current policy in the RIPE region (I do not know the others). If we are talking about large corporations that are non-LIR with either a single ISP in their PA space or multi ISP with their own PI prefix. It is not so easy for LIR to do the allocation or ask for PI space. If it does PA larger than /48 assignment without asking, it would be a RIPE policy violation. If it asks for either PA or PI, it has to go through an evaluation process. This means paperwork.

In my opinion, the draft should not expect every corporation to have /32 or /29. It is common only for LIRs. *The biggest prefix any end user/subject can use (even LIR) is /48* - in RIPE DB terminology, ASSIGNED, ALLOCATED-BY-LIR, or AGGREGATED-BY-LIR objects are limited to /48 right now. So even if an LIR used for itself more than /48, it would be in violation of RIPE policy - there are some tricks on how to hide that, but this should not be recommended.

If you want LIRs to use their assigned PA in such a matter, you will need to convince RIRs to relax their policy. Otherwise, this draft would have limited use cases to networks that are owned by LIRs and either violate RIR policy or have an exception.
> 
> > 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?

Sure, but then the LIR had to ask its RIR for an exception from /48 rule. Also, we would end up either with two /48s or we would need to renumber to aggregate to single /47.
> 
> > 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.

Then you cannot obsolete SLAAC by it (as some seem to suggest). Also, what if the network operator sets both flags?
>
> > 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).

I understand that it is easier on host implementation to do SLAAC internally. However, what is the problem with doing DHCPv6 or something DHCPv6-like internally? Inside a single Node, there are no artificial/external limitations on how many IPv6 addresses one service can get. The different situation is when the device is a Router (like in tethering mode) when there are other devices connected to it. However, then already existing DHCPv6-PD RFCs apply. Then the /64 is the easiest and the cleanest thing to do, but no new document is also needed for such a case - the device is a Router.

This seems to me like an implementation choice rather than a technical limitation.
> 
> > 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?

Not every node needs multiple global unicast addresses. CPEs are doing quite well with just one, and then they are using the PD only for their down-facing interfaces - this seems like the best solution to me. I think that your requirement is only relevant when the device needs more than one unicast global unique address, and it should be written there.
> 
> > 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.

Isn't this situation comparable with connecting a physical switch to an Ethernet port configured and limited for a single device? I mean, this is known even in IPv4, isn't it? At our university, if someone wants to connect a switch, they have to ask first to have that limitation lifted. Same in IPv6, if you need to have 10 global unicast addresses per device, it is not standard behavior, so you should ask first. As I understand, it is a protection against a malicious device that would ask for an infinite number of addresses or obsoleted privacy extensions that had a similar property.
> 
> > 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.

 meant that number of connected devices is limited by the number of available prefixes. In the second example, I mentioned it would be 32 devices per segment. This would scale better if /96 were allowed.
> 
> > "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').

I mean: forwarding packets, sending router advertisements, doing server/router part of address autoconfiguration, having multiple interfaces, etc. Basic stuff that IPv6 capable router has to do.
> 
> > "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..

If you are using ND Proxy for it, I'm not surprised. But if you run a virtualization platform either on a bridged or routed segment and the network is configured correctly for in (not connected to a typical client port), it should act like any other switch/router connected to the network, shouldn't it?
> 
> > 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.

I do understand that in this draft, the "router or not" isn't the criteria. For me, it is. At least in terms of if it should ask and get /64 or not. If it is a router, then I'm fine with giving it /64 or more. If it is not, it should get less than that, and the /96 seems like a reasonable compromise. It would still allow a device to manage its prefix however it sees fit while it doesn't cost LIR or its customer an insane number of resources that they might not have.

I must say that you do have quite an untypical workstation. I've checked my computers and servers, and all of them seem to have just one link-local address and one global unicast address (stable privacy or EUI-64) per interface. Only one of them also has a ULA. What OS vendor/version do you use (just curious)? I do understand that my workstation is also not typical as I'm a net admin running Linux. Also, I've forced my desktop and servers to use EUI-64 instead of stable privacy, but that would not change the address count for me.
> 
> >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..

But when they see how big the prefix demand would be, they could also be scared to touch the appropriate flag in RA. I don't think that there are so many that can afford to turn it on an organization-wide scale. :-)
> 
> > 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
>