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

Martin Huněk <martin.hunek@tul.cz> Thu, 22 December 2022 21:40 UTC

Return-Path: <martin.hunek@tul.cz>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E36C14F72F for <v6ops@ietfa.amsl.com>; Thu, 22 Dec 2022 13:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tul.cz
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62sal4eBvFYH for <v6ops@ietfa.amsl.com>; Thu, 22 Dec 2022 13:40:46 -0800 (PST)
Received: from bubo.tul.cz (bubo.tul.cz [147.230.16.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7A9C14F726 for <v6ops@ietf.org>; Thu, 22 Dec 2022 13:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.adm.tul.cz (unknown [147.230.233.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id C192418048561; Thu, 22 Dec 2022 22:40:40 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 bubo.tul.cz C192418048561
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tul.cz; s=tul2021; t=1671745241; bh=cJZ1uNCrOFGxOfI/at02IzMsbsOCj9xdsTleU5yKxjk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Fjz/4wAeCJFcyXNQj2YOVnJZuSx8P8yIfHAFlgeQBvbWd4YILNmeg/7QBaDCLbg5B JaxWKUgNzOB1C578Wb296ds6f94g+tz3z7+tAc/0gk11VSx66m8/78BR4vhTlv7mE6 rJKK30+OQU4mxQs/oCPoUXxB7eyKXEjh0HHMTmmRyGtMWoNXvFwBUEDGDy5RRU1YuD +sZRq8panzoAudIY8S21NlOKSU7NpilwjduKsxizxdkQpeS6FtoARFmS76AT6l4eQQ 5CqKf382aldUgYy3HuCvWF8wgsPYiQvGjp36v+xgwdJOnWtw48Kq2AibX5Sri7JD+8 LVKMLKCcwhdCQ==
From: Martin Huněk <martin.hunek@tul.cz>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, v6ops@ietf.org, Fernando Gont <fernando@gont.com.ar>
Date: Thu, 22 Dec 2022 22:40:35 +0100
Message-ID: <1915264.fIoEIV5pvu@asclepius.adm.tul.cz>
Organization: Technická univerzita v Liberci
In-Reply-To: <2aa6b925-f88f-69fc-70ef-926a68fea4af@gont.com.ar>
References: <167107554671.48477.568330207202509840@ietfa.amsl.com> <ac2b11e3-1860-abf9-1f7f-f2f0cae22db3@tul.cz> <2aa6b925-f88f-69fc-70ef-926a68fea4af@gont.com.ar>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3810588.fW5hKsROvD"; micalg="sha384"; protocol="application/pkcs7-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/59fjXZTkUuxwFtvdLuM8WQQ0oSE>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-collink-v6ops-ent64pd-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2022 21:40:51 -0000

Hi,

Dne čtvrtek 22. prosince 2022 2:50:39 CET, Fernando Gont napsal(a):
> Hi,
> 
> On 21/12/22 13:13, Martin Huněk wrote:
> > 
> > On 21. 12. 22 5:02, Brian E Carpenter wrote:
> >> On 21-Dec-22 13:19, Martin Huněk wrote:
> >>> Hi Brian,
> >>>
> >>> Dne pondělí 19. prosince 2022 21:59:12 CET, Brian E Carpenter napsal(a):
> >>>> On 19-Dec-22 23:30, Martin Huněk wrote:
> >>>>
> >>>>> Furthermore, this address has to be predictable for an 
> >>>>> ISP/netadmin, so it is possible to make an AAAA record for it
> >>>>
> >>>> Er, no, the creation of such an AAAA record should be automated 
> >>>> (subject to some kind of authorization).
> >>>
> >>> I would certainly not want arbitrary (BYOD) connected devices to be 
> >>> allowed to manipulate DNS records in my domain by the DDNS. There are 
> >>> security reasons for that. If I know the DUID of the device providing 
> >>> some service to the Internet users and the IID where the device 
> >>> listens is known, I can make static prefix delegation, and then I can 
> >>> make an AAAA record for it. Without it, I can run only IPv4 services 
> >>> there.
> >>
> >> 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.

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.

Please compare it with the IPv4 situation:

In IPv4, I know:
- MAC address
- IPv4 address

So it is easy to make an A record from it.

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.

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.

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. The AAAA records are made only manually, so the majority of devices have only A records now - they are running IPv4-only services on a fully dual-stack host. This is one of the biggest setbacks of the IPv6 deployment for us. The DHCPv6-PD configured host address would not help with that.

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. The DUID is a fixed number known to the user, and the delegated prefix is known to the administrator (fixed or it may change). The Internet would not know the DUID (and also IID), but an administrator may publish an AAAA in the DNS.

Privacy at any cost means no IPv6 utilization, and some devices have no use for privacy.

Martin