[v6ops] Fwd: New Version Notification for draft-hunek-v6ops-nat64-srv-03.txt

Martin Huněk <martin.hunek@tul.cz> Sun, 12 June 2022 14:48 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 0E333C14F73F for <v6ops@ietfa.amsl.com>; Sun, 12 Jun 2022 07:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 4wG13_R-Na3D for <v6ops@ietfa.amsl.com>; Sun, 12 Jun 2022 07:48:29 -0700 (PDT)
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 51521C14F732 for <v6ops@ietf.org>; Sun, 12 Jun 2022 07:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.adm.tul.cz (unknown [IPv6:2001:718:1c01:260:73fc:b828:6ebf:30fa]) (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 1D6CE1806E3CB for <v6ops@ietf.org>; Sun, 12 Jun 2022 16:48:23 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bubo.tul.cz 1D6CE1806E3CB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tul.cz; s=tul2021; t=1655045303; bh=+LtNKCO06akfu1xFIXX4EhaNT7skXiWOeS6PAhTrHy8=; h=From:To:Subject:Date:From; b=c0l4Uw31qUbWYVpJODIuHp7hserzqGLKJX12c+aTjEw405j2e+AtSsHIo8r+l+FmE XFsRT1JGfue6kkgXtnNL4LrwXGIT0ROXIG1mK803h4rDxDcTPPaJcSlakvSFSHN8QV I9/C4SflIGJx6MNwmsXXnYVMXopinN52N/H3dQX89/SWPMMS55plrfu214zYle2GgL sfEApttDa9WJSLGAkVvKo8TLDAwshzg8F1SongiQNUqVD25bjqhX8m5fkf9wpsTeLy TujuQwt7qNNE0PCjYolXuYDSxIUsqBA5OA7h85zjmhNa3DSFwvr+Nq0Nwuk77IHekK nRlTzwWIFnqGA==
From: Martin Huněk <martin.hunek@tul.cz>
To: v6ops@ietf.org
Date: Sun, 12 Jun 2022 16:48:11 +0200
Message-ID: <3137078.aV6nBDHxoP@asclepius.adm.tul.cz>
Organization: Technická univerzita v Liberci
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1949635.PIDvDuAF1L"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/T73-oXISvRIrnIvfOqI-fTuN5ZE>
Subject: [v6ops] Fwd: New Version Notification for draft-hunek-v6ops-nat64-srv-03.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: Sun, 12 Jun 2022 14:48:34 -0000

Hi,

I'm not sure if this notification is automatically sent to the WG mailing list or not, so I do apologize if it has been sent here already (I'm new to this process). This version should reflect input from IETF 113.

I'm not sure about the reference to RFC6763 mentioned by Ted Lemon. Ted, are you suggesting transporting the NAT64 prefix in the TXT record instead of AAAA? Or is it just about the naming convention reference? The RFC6763 also suggests using mDNS for the service discovery. However, when using mDNS there is no way to validate the authenticity of received data - for this reason, this doesn't seem to be a safe solution in this case.

Here is the changelog:
v03 (2022-06-12):
==================
- Added reference to RFC6763

Diff:
https://github.com/hunator/draft-v6ops-nat64-srv/commit/0c15fa058c11fabb8aa6e295d6ddc10e78be02c8

v02 (2022-05-12):
==================
- A Node MUST run the PTR detection process only for stable suffixes or only one dynamic in the same prefix
- The SRV method doesn't need to be blocking for other methods
- Detection might stop sooner than on the second level domain (for example co.uk.)
- An example of how a negative reply should be interpreted
- Fixed: Underscores in domain names
- Added reference to Mozzila Public Suffix List

Diff:
https://github.com/hunator/draft-v6ops-nat64-srv/commit/086ea5759a38a9284e8326e78ae052de5d647501

v01 (2022-03-07):
==================
- Explicitly define the process of local domain detection from PTR records

Diff:
https://github.com/hunator/draft-v6ops-nat64-srv/commit/6f9b1cc7e5760446e9ee64ed6d7cc5e38f24bb17

I would apretiate any input or suggestions.

Best Regards,
Martin Hunek
--- Begin Message ---
A new version of I-D, draft-hunek-v6ops-nat64-srv-03.txt
has been successfully submitted by Martin Hunek and posted to the
IETF repository.

Name:		draft-hunek-v6ops-nat64-srv
Revision:	03
Title:		NAT64/DNS64 detection via SRV Records
Document date:	2022-06-12
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/archive/id/draft-hunek-v6ops-nat64-srv-03.txt
Status:         https://datatracker.ietf.org/doc/draft-hunek-v6ops-nat64-srv/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hunek-v6ops-nat64-srv
Diff:           https://www.ietf.org/rfcdiff?url2=draft-hunek-v6ops-nat64-srv-03

Abstract:
   This document specifies how to discover the NAT64 pools in use and
   DNS servers providing DNS64 service to the local clients.  The
   discovery made via SRV records allows the assignment of priorities to
   the NAT64 pools and DNS64 servers.  It also allows clients to have
   different DNS providers than NAT64 providers while providing a secure
   way via DNSSEC validation of provided SRV records.  This way, it
   provides DNS64 service regardless of DNS operator and DNS transport
   protocol.

                                                                                  


The IETF Secretariat


--- End Message ---