Re: [v6ops] WG call for adoption: draft-collink-v6ops-ent64pd-03

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

One case is the prefix/address assignment to host - this seems to be the aim of your draft.
The second is the router getting the PD prefix which is already solved regardless of this draft or any flags within RA.

We need to clearly distinguish between these two cases. The host OS, in fact, does have full control over the used addresses - it is up to it what addresses will be used. It can reuse SLAAC, use some random number generator, or even use DHCPv6 internally; it doesn't really matter. But only the SLAAC method requires/64; others do not.

If the host has got an internal routed segment or the downstream interface, then it is, in fact, a router, and it should act like it. The PD for routers is already solved, and it works. No need to change it.

Of course, these roles can change over time, but it is solvable. For example, a laptop (as host) would ask for /80 (or whatever is small enough) for itself. But then you would start VM on it and connect it to the newly created internal network segment instead of the network bridge. Then the laptop would have a downstream interface, so it should start to act like a router. It means: asking for a new larger PD for its downstream interfaces, responding internally to RS, and providing periodical RA. The same would go for mobile phone on which a tethering function is switched on. For its needs, it doesn't need the whole /64, but if it is providing connectivity to other devices, then it makes sense to ask for at least /64. But then again, it is not an ordinary host. It is a router.

So what is the scope of this draft? If it is for hosts, then the host doesn't need /64 and SLAAC. If it is for routers, then why are we trying to solve something that already works quite well? The document abstract suggests the first case - the host.

On 18. 04. 23 8:17, Jen Linkova wrote:
> On Tue, Apr 11, 2023 at 1:36 AM Martin Huněk <[e-mail]> wrote:
>> As I read the -03 version, it still requires /64 at minimum. It is just better hidden in the text.
> 
> No, it doesn't require /64. It requires whatever hosts need to support
> SLAAC. If someone is willing to work on making SLAAC work with, let's
> say, /80 - nothing would change for this document.
> 
Not explicitly. But we can probably agree that there is an implicit requirement by the SLAAC. One way or the other, the result is the same.
>>
>> Small thing first - section 6:
>>> The server MUST provide a prefix short enough for the client to assign addresses to its interfaces and connected systems via SLAAC.
>> The server doesn't know that.
> 
> Currently SLAAC only works with /64 (see rfc7421, for example). It's
> basically a protocol constant.
> It may change over time indeed - in that case it should be up to the
> administrator to decide if their endpoints fleet supports the new
> standard or not yet.

No dispute here. But we are talking about prefixes for the host, not for the downstream interface - this is the router thing.

>> It may guess that from the prefix-length hint, but it has no way of knowing it for sure. Also, it MAY be restricted by the network policy. It should say: "The server SHOULD honor prefix-length hint if able."
> 
> I believe https://www.rfc-editor.org/rfc/rfc8168.html already covers
> what the server SHOULD do with the hint. Maybe we shall rephrase this
> section, making it clear that it doesn't introduce any new
> requirements to the server (as it would be in scope for the DHC group)
> but provides some guidance for the administrators on what features
> MUST/SHOULD be enabled and how the server shall be configured for the
> proposed deployment to work.
> Would it be better?
> 
Sure, the reference to RFC8168 would be great. I would still object to the SLAAC part.

>> In section 4 you wrote:
>>> "Chosing longer prefixes would require the host and any connected system to use some other form of address assignment and therefore would drastically limit the applicability of the proposed solution."
>>
>> I would argue about that as it seems to me quite the opposite.
>>
>> If you force minimum /64, you would limit the applicability of the proposed solution address space-wise to:
>> - Large companies that are also LIRs (having at least /32 PA spaces)
>> - Small companies and persons with large enough allocations/assignments (/48 PA or PI)
>>
>> The medium to large companies that are not LIRs would be unable to get large enough assignments to facilitate the proposed solution. As I already wrote here, the RIPE allows at most /48 to a single subject. A larger assignment had to be authorized, and if you follow the RIPE AP-WG, then you could read the "horror story" about requesting /47 PI. In theory, it is possible. Practically, it is not (at least by the book).
> 
> What I mean by "limiting the applicability of the solution" is that
> using any prefix which is longer that $PREFIX_REQUIRED_FOR_SLAAC means
> that some if the devices would not be able to function/get IPv6
> addresses if you deploy this. I see this scenario as a much more
> serious limitation than "some networks which might not even want to
> deploy this, would need to justify more address space".
> It would change the situation from "I do not have resources required"
> to "some of my hosts would not be able to connect to the network".
> 
This is the "router case" situation.

> Please keep in mind that if you'd like to implement the solution
> described in this document in a fully controlled environment and use
> some other forms of address assignments, you can do this already. You
> do not need this draft. Run DHCPv6-PD client on endhosts and DHCPv6-PD
> servers/relays on the infrastructure. The purpose of this draft is not
> to allow or deny this. The purpose is to document the deployment
> scenario when  a random host can connect to the network, even if the
> host and the network infrastructure are not under the same management.
> 
> I'd be extremely uncomfortable to publish an IETF document which
> recommends a deployment model which randomly breaks hosts.
> Recommendations in the section 6 of the draft are provided to ensure
> that such deployments are not making the situation worse.
> 
Not at all. IMHO, the *new* thing is the use of PD for the host itself, not for the downstream interfaces, VMs, and other devices. Routers are doing those things already, so they do not need this draft. The reuse of SLAAC inside a single host is unnecessary and wasteful of the address pool. However, nothing prevents you from asking the second, larger PD if the need arises. At least you would not end up with every single device having /64 (= IPv6 address space reduced by a factor of 2^64).
> 
>> There is no technical reason why this *new* method *MUST* use SLAAC code for the IID generating process on the host
> 
> You are assuming that the system requesting a prefix is always the
> same system which is going to use all addresses.
> 
Yes, I do. If we are talking about hosts getting addresses, then it should be the case.

>> or why it cannot modify it in the end so the IID can be shorter than 64 bits. It had to be implemented anyway.
> 
> There is a difference between expecting a host OS to run a PD client
> and send the received prefix downstream in RAs and implementing a new
> way of assigning addresses in *all* downstream systems.> 
Yet again, this would be the router, not the ordinary host.

>> If the host is a router with downstream interfaces, the situation is different, but most devices are not routers.
> 
> Interesting. Your experience may vary but what I've discovered by
> deploying IPv6-only networks, is that *most* devices are actually
> routers. We (administrators) just do not know/do not care about it in
> the IPv4 world, because we have NAT and hence are not capable of
> telling if this device is a router or not. That problem caused *most*
> of support tickets we got during IPv6-only migration. At that point I
> realized we need PD if we do not want to do NAT.
> I did see a lot of cases like "oh, we thought it's just a host but
> when you open it, it actually has an openwrt router and a few tables
> inside".
> 
Inside the "enterprise" network, I do expect that connecting routers to the network is regulated by the network policy. At least it is in ours. So yes, there might be some devices that act like routers connected to the network but not *most* of them. The situation would differ in the ISP sector, but there, you would use the DHCPv6-PD already - if you are not the cellular network provider so you are blocked by one large mobile system vendor.

>> In my opinion, the current system of every address space-heavy companies forced to become an LIR is the v4 mess.
> 
> Sorry, could you please elaborate?  How does this proposal *force*
> anyone to do anything?
> Nobody *has to* deploy this. It's up to an administrator.
> 
I mean: If you would like to deploy this in a large network, you would need to become an LIR to get a large enough allocation. Otherwise, with /48 PI or PA, you would face the same problem as the B-class holder in IPv4 is facing (just 16b to work with). Yes, you are not forced to implement it, but then it is not really applicable to you, isn't it?

>> The client MUST ask for the minimum prefix delegation size that would suffice its needs. For a single host, the RECOMMENDED size is /96. For a client with downstream interfaces, it SHOULD ask for a large enough prefix to address every downstream interface with /64. The DHCP-PD server SHOULD honor the length of the requested prefix if able.
> 
> Interestingly enough it means that practically you'd need to provide
> /64 per host.
> 
> This deployment model doesn't need to suit *everyone's* needs. But
> what we must ensure is that if someone decides to deploy it, devices
> should be able to work.
> 
You do not need the /64 on a single host not running VMs, containers, and downstream interfaces. The host/client knows if these things are running on it, so it knows if it needs /64s (and how many) or if it will fit in a smaller prefix.

>> There is just one reason against that: the reuse of SLAAC code at hosts. It doesn't actually matter so much. This proposal is a new method of address assignment anyway, so one way or the other, there is still a need for a new code.
> 
> Again, you seem to assume that the system requesting a prefix is the
> same one assigning all those addresses. As a network administrator
> who'd like to deploy this, I just can not make this assumption, as I
> know that even now it's not the case for my network.
> 
In the case of routers, it already works without this draft. Just in the case of hosts, it is not expected now.

>> There is also one more use case when the proposed solution would perform worse than having a shared/on-link network segment. This would be a large data transfer. Switched, the directly reachable network would not be so heavy on the computation power of the router as in the case of a routed network (with hosts using delegated prefixes).
> 
> Maybe this solution is not suitable for this setup then?
> I'd be perfectly happy to have a text saying "this solution is not
> recommended if peer2peer communication is allowed between onlink
> hosts".
> 
But there needs to be also some mechanism that would allow the concurrent use of different methods. Like: If both "PD flag" and the "L flag" + "A flag" is set the client is supposed to use both SLAAC and DHCPv6-PD. If the "L flag" is not set and "PD flag" is, only the DHCPv6-PD should be used.

>>
>> Section 8 says:
>>> "... it's highly desirable for the host NOT to use the PIO prefix tto form global addresses and only use the prefix delegated via DHCPv6-PD."
>> With this, it would not allow using the on-link feature (L flag) - the higher amount of traffic would need to go through the router.
>>
>> The last issue I've already mentioned in this list is an inability to place any host using this method to the DNS by static entry. The same disadvantage is present in the SLAAC (after the EUI-64 has been left). However, this is possible by DHCPv6 with static reservation. Due to that, the DHCPv6-PD for clients does not supersede the DHCPv6 itself in its applicability.
> 
> 
> Actually, you might find
> https://datatracker.ietf.org/doc/draft-wkumari-dhc-addr-notification/
> useful.
> 
Thanks, I'll look on it.

>> I would advise against adoption in this state because:
>> - With minimum /64, it is way too address space heavy, so it cannot fit in current address space plans,
>> - The per host /64 is not feasible for larger non-LIR organizations due to the current RIR rules - it needs consensus on the RIR level first,
>> - Computation power-wise more resource heavy on routers (between host traffic and assignment/renew process),
> 
> Those seem to be cases when an administrator might decide not to
> deploy this solution.
> As long as solution limitations are documented and the administrator
> can make a decision based on data, what's harm in having options?
> It's like...I don't know...RFC7404 - I really like it and had been
> operating a network like that for years. But my other backbone can't
> use it, so it wasn't deployed there.
> 
Harm is in the expectation that there is enough space to provide such wasteful addressing.

>> - Doesn't help with static DNS records for services running on PD hosts,
> 
> But it doesn't make it worse. Again, happy to add it as a solution
> limitation (never considered creating DNS entries for mobile phones..)
> 
Yeah, won't help either. The networks do not consist only of mobile phones. :-)

>> - Solves the symptoms, not the cause: clients are using too many addresses - instead, we should ask for old privacy extensions to be disabled by default and/or generally limit the maximum number of addresses a client can have from a single prefix,
> 
> 
> Let's discuss this. So I'm connecting a kitchen smart scale (or
> ChromeOS) laptop to the network. It needs Z addresses but can only get
> X (X < Z).
> Whatever you do it would mean a failure for the system. Why would we
> recommend anything which breaks hosts?
> 
Precisely, so we should say that clients should limit the number of their addresses to some number (min.) so vendors on both sides would know how many they can expect.

>> - It concentrates on SLAAC reuse instead of describing a more proper (less address space-heavy) method of IID generation that would not need 64b IID.
> 
> This is v6ops draft, it documents a deployment scenario using existing
> technologies.
> 
>> If it has allowed (and recommended) smaller prefixes (/64+), I would not see it as such a big problem.
> 
> It would mean publishing the recommendations which are not guaranteed
> to work. I can not deploy it because an unknown number of devices in
> the network would fail.
> 
They would work for the host if it is written in that document. If it acts like router then it will work even now without this draft.

Martin

>>
>> Dne neděle 9. dubna 2023 2:37:28 CEST, Jen Linkova napsal(a):
>>> Dear v6ops WG,
>>> Even if you read -02, please take a look at -03 (or at the diff, available
>>> at  https://author-tools.ietf.org/iddiff?url2=draft-collink-v6ops-ent64pd-03
>>> )
>>> The new version addresses comments received during the IETF116, including
>>> the prefix length.
>>>
>>> On Sun, Apr 9, 2023 at 8:02 AM Xipengxiao <xipengxiao=
>>> [e-mail]> wrote:
>>>
>>>> Folks,
>>>>
>>>>
>>>>
>>>> In order to facilitate quick development of a solution, this message
>>>> initiates a WG call for adoption for draft-collink-v6ops-ent64pd-03. The
>>>> call for adoption will end on Aug. 23, 2023.
>>>>
>>>>
>>>>
>>>> Ron & XiPeng
>>>>
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>
>>>
>>>
>>
> 
>