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

[Vasilenko Eduard <[e-mail]>]

Martin made a good point that a DNS extension would be needed to register prefixes in the DNS.
Because this solution makes it extremely difficult to update DNS for IIDs that are fully "local matter".
Is it a new "AAAP" record? But stub resolvers are asking only "AAAA".
On the other side, such a record would greatly decrease the load on the whole DNS infrastructure.
Ed/
-----Original Message-----
From: Jen Linkova [mailto:[e-mail]] 
Sent: Friday, December 16, 2022 4:03 AM
To: Vasilenko Eduard <[e-mail]>
Cc: V6 Ops List <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt

On Fri, Dec 16, 2022 at 1:23 AM Vasilenko Eduard <[e-mail]> wrote:
> I like this proposal for the SLAAC deprecation in the limited (Enterprise) domain. It would greatly help for IPv6 Enterprise adoption. DHCP's absence is the biggest issue for this market segment.
> The solution needs a name for a short reference. Something like "DHCP prefix per host".
>
> 1.      What is the point to keep SLAAC if DHCP infrastructure is mandatory? I do not understand what SLAAC is left in this solution. DAD, PIO - all looks gone. In fact, this proposal is the SLAAC deprecation (despite many claims that it is not). It is visible in section 8 when discussing "SLAAC" against "prefix per host" methods.

Eventually, if the administrator of the particular network can be 100% sure that all devices support PD, the SLAAC prefix can be indeed removed from the router configuration.
However I'd expect it would be a while till we get to that point.
In other networks using PD might not be desirable at all (the draft has a section on applicability). I do not want it in my home network - OK, I have 10 devices, it's OK to have 100 ND entries, not a big deal.
It's completely different in my VXLAN network, when I suddenly get 10 times more Type 2 routes.

So we are not going to deprecate SLAAC as a protocol. Some networks would be still using it. Even more, the hist itself would be using SLAAC to assign addresses from the delegated prefix.

> 2.      Choosing the IID is a fully "local matter" for this solution. The host could easily choose from /96. It is discussable how many bits are needed for good IID randomization (is 32 bits enough?).
> It is a good opportunity to move the prefix to something much longer. It is not a problem for DHCP.

I have a number of concerns:
- there are still devices out there which are not particularly happy with processing routes with prefix length between 65 and 126 in hardware.
- how long would it take before /96 would become /128? ;)
- that would require changing the address assignment logic for the device - now it's just doing SLAAC using the delegated prefix (incl.
privacy address generation), which would complicate things and slow the adoption, probably.


> 3.      The proposal would not resolve MHMP (on PA addresses): the host is still not capable of properly choosing which prefix to use. The root cause is that the next hop is chosen before the source address (by getaddrinfo()). It could be discussed separately.

The draft is solving the different problem: how to let the host to have as many addresses as the host needs/wants w/o creating scalability issues for the network.
Multihoming issue is still here.

> 4.      It was possible to improve a little routing (aggregation) by asking the DHCP server to delegate prefixes closest (by mask) to the router interface on the link. In the case of longer prefixes (/96) - it is possible to delegate from the single /64.

Yes, the server might need to map the relay link-address field in the relay-forward message and the pool.

> it is probably needed to have two /64 for the router on the link to 
> support the transition period of the new solution and the SLAAC at the 
> same time.ot

I do not think it's needed.
I configure 2001:db8::/64 on the router interface and use it for SLAAC.
The DHCP server is instructed to allocate /64 subnets from
2001:db8::/46  (assigned, for example, for the guest wifi on that
site) with the first /64 being reserved.

> 5.      The current privacy RFC is broken by this solution but it is not a problem - it may be updated later.

I do not think it's "broken". The host still uses RFC8981 for assigning addresses from /64.
If you mean that an eavesdropper may assume that the same /64 is always the same host, Section 11 talks about that.

> Indeed, it could be v6ops RFC because it is "local matters" for hosts and routers.

A separate 6MAN document would be required indeed, but it would be the next step.

> It does not break SLAAC. It just deprecates it.

It provides an alternative for the networks which need it.

> Some sort of SLAAC replacement by DHCP.

A hybrid, taking the best of both ;)

> Exactly what many Enterprise people were demanding for a long time.

Glad to hear that you find it useful, thanks!

--
SY, Jen Linkova aka Furry