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

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

Hello Fernando,

Dne sobota 31. prosince 2022 1:01:23 CET, Fernando Gont napsal(a):
> Hello, Martin,
> 
> On 22/12/22 18:40, Martin Huněk wrote:
> [...]
> >>>> 
> >>>> Completely understood. But the bad old days of using the MAC
> >>>> address to create the IID are gone, and numbering hosts from 1
> >>>> upwards would be extremely helpful for some kinds of attack.
> >>> 
> >>> Again, I do not suggest that it should, by default, number 
> >>> hosts/services from 1 upwards. I'm saying that when (and only
> >>> when) the device is providing service to the Internet, the IID on
> >>> which the service is listening should be predictable.
> >> 
> >> No. It does not need to be predictable -- that's one of the reasons
> >> for which you have the DNS. If anything, it needs to be stable, to
> >> avoid the hassle (and glitches) to perform DNS updates regularly.
> > 
> > That's precisely why it must be predictable, so the admin is actually
> > able to put it into the DNS. Or at least it needs to be predictable
> > to the admin.
> 
> It doesn't need to be predictable, If anything, it has to be stable
> (indeed, these two characteristics are design goals of RFC7217).
> 
There is not even a stability requirement in this document. It seems that it is strictly up to the host implementation. If this should be the SLAAC replacement, then it is not worse than the SLAAC in this aspect. However, if this should be something balancing the lack of DHCPv6 support on some platform/vendor, stable IID is not enough - it has to be predictable.
> 
> > As a network admin, I know the following: - Client's DUID - Client's
> > Link-local address - Delegated prefix - Maybe the MAC address
> > 
> > I do not know the IID, so I cannot know the IPv6 address needed to
> > make an AAAA record. This I know with DHCPv6, and I knew that back in
> > the days when only EUI-64 was used with SLAAC. Also, in the draft,
> > there is no stability requirement.
> 
> If you use DHCPv6, then you know the addresses, because you're leasing them.
> 
Yes, when using DHCPv6, you can do that. However, not the case for the DHCPv6-PD discussed in the referenced document. You would not know the IID used by the host inside the delegated prefix - that is the problem.

> OTOH, if you use SLAAC, you're somehow advocating for hosts to do their 
> own thing -- so it shouldn't be you registering addresses in the DNS, 
> but the hosts tehmselves should do it with Dynamic DNS updates.
> 
Allowing the unrestricted Dynamic DNS would be a security issue, and from what I know, there is no way how to indicate to the device what domain name it is allowed to modify/register when using SLAAC. It is sort of open access to the network with no trust established. So only viable solution to allow Dynamic DNS would be a separate sub-domain per network segment. But even this way, there are risks for the domain. That is why you want to keep the domain under manual control - but this way, you cannot use SLAAC (nor DHCPv6-PD in its current state).
> 
> 
> > Long story short, if we keep overlooking the need for
> > autoconfiguration predictability in the name of privacy, we will end
> > up with hosts with privately generated addresses that will use IPv4
> > only, as there would be no IPv6 autoconfigured services in the DNS.
> 
> If you want managed configuration, you do DHCPv6, not SLAAC -- slaac is, 
> in a way, configuaration anarchy.
> 
I agree. The DHCPv6 is now the only way. No DHCPv6-PD as it is written in this document and no SLAAC after EUI-64 has been replaced.
> 
> 
> > Even with stable privacy addresses, I cannot know the IID generated
> > by the host with SLAAC (it uses internal values for generating IID).
> > Currently, I have got just three options: 1) Force clients to use
> > EUI-64. 2) Use DHCPv6 and force users to report DUID manually. 3) Use
> > static configuration, losing all benefits autoconfiguration has.
> 
> #1 has been known to be bad for a long time, so I hope you don't even 
> consider it. ;-)

Actually, I do. Not for mobile clients - it is too bad for them. But I have no issue with EUI-64 for fixed clients, especially for those without human users sitting behind them (servers, printers etc.), as they have no use for privacy ... :-)
> 
> With SLAAC, hosts do their own thing, such as generating addresses. If 
> you don't like SLAAC because you cannot predict addresses, then... don't 
> use SLAAC. ;-)
> 
I don't like that we have been forced to use SLAAC when implementing IPv6 in our network, as the SLAAC is the only required autoconfiguration option (the DHCPv6 is not mandatory). Back then, the EUI-64 was the only IID option - so we could use it for AAAA records. Then privacy extensions came along, followed by RFC7217 - which rendered EUI-64 AAAA-generated records useless and broken. So it seems that the only option left is the non-mandatory DHCPv6. If there is not and should not be any other way, then it is vital for IPv6 deployment, so DHCPv6 MUST be mandatory for every client device.

If the suggested DHCPv6-PD for a client should be an alternative for DHCPv6, then it must allow either to predict IID or there has to be a way how to secure Dynamic DNS updates. The securing of the DDNS would need to consist of indicating to a client what names it is allowed to modify/register and some way how to negotiate TSIG for it. Most importantly, it had to be administratively effortless and automated.
> 
> 
> > What happened at our university (fully dual-stack) was that when the
> > IPv6 was deployed, there was only EUI-64 we had made, for every
> > registered device in the network, both A and AAAA records. When the
> > privacy extension came, we had to abandon the idea of making
> > automated EUI-64-based AAAA records.
> 
> If you wanted, you could map MAC <--> IPv6 address, and create DNS names 
> from there.
> 
Yes, it was possible when the EUI-64 was the only option for SLAAC, or with DHCPv6 when the relay/server provides information about client MAC (not always the case) or when a client is using DUID-LL or DUID-LLT (not recommended now) or collect it from the neighbor table (resource heavy). It is not an easy task nowadays.
> 
> > I'm not saying that IID has to be a fixed value known to everybody.
> > It can be, for example (just to illustrate an idea): SHA256(Client
> > DUID + Delegated prefix) and use first n bits where n is length of
> > IID.
> 
> I think we have had enough lessons suggesting: do not employ predictable 
> IDs.

For client privacy, yes. However, unpredictable IIDs caused other problems - a headache for (IPv6) network administrators being one of them. :-)

Best Regards,
Martin