[v6ops] New version of draft-hunek-v6ops-nat64-srv

Martin Hunek <martin.hunek@tul.cz> Thu, 18 November 2021 23:28 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 D50F53A0BCD for <v6ops@ietfa.amsl.com>; Thu, 18 Nov 2021 15:28:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdleTpMpZcmf for <v6ops@ietfa.amsl.com>; Thu, 18 Nov 2021 15:27:59 -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 2A66E3A0BCE for <v6ops@ietf.org>; Thu, 18 Nov 2021 15:27:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from rumburak.ite.tul.cz (unknown [IPv6:2001:718:1c01:72:2e27:d7ff:fe2e:c477]) (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 270C218050DDD for <v6ops@ietf.org>; Fri, 19 Nov 2021 00:27:51 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 bubo.tul.cz 270C218050DDD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tul.cz; s=tul2021; t=1637278071; bh=V8up9JFNnIr5xKSpm1wn9EwBH1gGfKNHYionB5n9SmQ=; h=From:To:Subject:Date:From; b=DBhYAhITWhM/LeGg1/hPAAs8QLlsdmELl32MatQwNE2sjTppJt2k65m7OTuKoRNAx bnCNbb2zbbdfDMkr1h/6Wp+EZKWEjLPwcdkrHSPVUUbdsPwEN4fJ7lCzyfW++XHxSv nfZC3vbj6mS0dT/FD2HxZBsLn/HVoYW7igyjbTmCdXX89HCkVOpWEL/mMiP17wsMwh Hx9ZvjLwflhLVsJUkHUIIr6oVW4952yLCQlPj/Is8DhQgM/fXAf2DKevBUpXqkNrhr NJwrqXDXWdPhLzh9HRcCN6mJdSNlKgLGXhSyoOyCNBy77bUbVTTJodTHQ6vAURPSS9 w0uQcI6zfIsEQ==
From: Martin Hunek <martin.hunek@tul.cz>
To: v6ops@ietf.org
Date: Fri, 19 Nov 2021 00:27:45 +0100
Message-ID: <12906179.y0N7aAr316@rumburak.ite.tul.cz>
Organization: Technical University of Liberec
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4234014.MSiuQNM8U4"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tyeIwooXgzz9IWMK0HRRDcvrAjg>
Subject: [v6ops] New version of draft-hunek-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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, 18 Nov 2021 23:28:05 -0000

Dear WG,

Yesterday, I've uploaded the new version of draft-hunek-v6ops-nat64-srv (https://datatracker.ietf.org/doc/draft-hunek-v6ops-nat64-srv/).

It replaces the draft that I've by mistake, uploaded as a WG item when in fact, it was not (https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-srv).

The most significant changes are:
- Draft no longer suggests RA-DNSSL as a primary source of the local domain information. Instead, it prefers PTR records that can be verified by DNSSEC and can traverse through routers.
- Added chapters with reasons why it is necessary/useful to have yet another method.
- Added chapter on how the proposed method should interact with other methods.
- Priority of the method using NAT64 SRV record and DNS64 SRV record should be specified by a network operator.
- DNS64 SRV record should be able to override the recursive resolver used by a user for FQDNs without AAAA records.
- Mentioned how the method should interact with 464XLAT.
- Explicit statement that this method should work with ANY DNS transport protocol and ANY recursive resolver (not just DoH).
- The _ipv6 in the protocol field of SRV record is not new. It has existed since RFC5026 - the _nat64 and _dns64 are the only new services in SRV.
- Negative answer is now explicitly mentioned in the draft.
- New detection must be done before any DNS record used for detection expires (TTL).
- Possible multicast support like in RFC8115.
- Hopefully, better spelling, and grammar :-)

There is also proof of concept "code" in python at GitHub:
https://github.com/hunator/draft-v6ops-nat64-srv

However, I do not consider myself to be a programmer (much less in python), so the code is just a proof of concept, not production-ready implementation. Also, it does not do anything useful; it just shows detected prefixes and DNS64 resolvers on a console. But at least, it proves that NAT64 prefix information can be transported by SRV record to any non-privileged user-space application and without system-wide changes either on server or client. If anyone would like to try it, the domain "lbcfree.cz" and its subdomains have got SRV records published.

Any feedback would be highly appreciated.

Martin Hunek

PS: I'm sorry that it took me so long to update the initial draft.