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

[Jen Linkova <[e-mail]>]

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.

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

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

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

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.


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

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

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

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

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

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

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

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

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

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

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

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

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


-- 
SY, Jen Linkova aka Furry