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

[Fernando Gont <[e-mail]>]

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


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

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.



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



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

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



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


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

Thanks,
-- 
Fernando Gont
e-mail: [e-mail]
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01