[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 ---
- [v6ops] Fwd: New Version Notification for draft-h… Martin Huněk