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

Martin Huněk <martin.hunek@tul.cz> Wed, 21 December 2022 00:20 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 9BC7BC14CEE5 for <v6ops@ietfa.amsl.com>; Tue, 20 Dec 2022 16:20:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.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_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 seFP6o_EKR8p for <v6ops@ietfa.amsl.com>; Tue, 20 Dec 2022 16:20:10 -0800 (PST)
Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (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 BA6DBC14F73F for <v6ops@ietf.org>; Tue, 20 Dec 2022 16:20:08 -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 B87A91804CCC2; Wed, 21 Dec 2022 01:20:03 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 bubo.tul.cz B87A91804CCC2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tul.cz; s=tul2021; t=1671582003; bh=DNcFKuVG8PY79/TTz5oFw8d5yJnjpDGeciHPqneYbn8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UI5C0flRyB6xswJFN+bYCGrzBQW+1AcfSHG+ozlCmuSwZ7j2faFDUXprYhUP4GfR1 q3id9k/K20dvXsl/tjXUi9ek7dDw+9IDvGz82ewKaUhtZjUFhthFsnf2FeF4LRCnkE QiA9BiPCXdM1RzU+eonH1FUvPoykoTBYOE4VJR5t5yhTC/8ncrx02kK1EIe+/TiHda fqKrza+vzcrBZSF7EvLaycRxwTdTe0793JgbVuuavHQs7ahzts6hcvwIHiL7O9JTbW J1tpmEmwhvlHBErvLG4EjMCUHilE3vOUlYIkDe+s9Y+3SSXnNXOzHI1P0rt7hfSDFw 2NpvOBTds8dJw==
From: Martin Huněk <martin.hunek@tul.cz>
To: v6ops@ietf.org, Brian E Carpenter <brian.e.carpenter@gmail.com>
Date: Wed, 21 Dec 2022 01:19:58 +0100
Message-ID: <2148317.C4sosBPzcN@asclepius.adm.tul.cz>
Organization: Technická univerzita v Liberci
In-Reply-To: <3cac1c98-8cdb-8b5b-4d03-7b03c24f8124@gmail.com>
References: <167107554671.48477.568330207202509840@ietfa.amsl.com> <2859685.e9J7NaK4W3@asclepius.adm.tul.cz> <3cac1c98-8cdb-8b5b-4d03-7b03c24f8124@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2486290.4XsnlVU6TS"; micalg="sha384"; protocol="application/pkcs7-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/us4u06n7ZhK8CutpEYxE2n2eqRc>
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: Wed, 21 Dec 2022 00:20:14 -0000

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.

Is there some existing solution for it other than that? Open, not vendor specific.
> 
> An IID cannot be zero, since that value is reserved (https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml). There are reasonable arguments why it should be pseudo-random, even for a server.

Sorry, I've missed that zero is not allowed.

Anyway, network administrator predictable IID would be a huge help in providing IPv6 services from it (without resolving it by static configuration). I see no such arguments if the prefix doesn't leave a single device and when this predictable IID is used only when it is configured with a service that needs to be reachable from outside.

By the way, in this case, the admin predictable IID source is even the DUID, and that is not predictable for the rest of the Internet.
> 
>     Brian
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>