Re: [BEHAVE] [DNSOP] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt

Mark Andrews <marka@isc.org> Fri, 07 October 2022 05:47 UTC

Return-Path: <marka@isc.org>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDD5C159A2F; Thu, 6 Oct 2022 22:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=isc.org header.b=BjjMpWvW; dkim=pass (1024-bit key) header.d=isc.org header.b=d/NJtNM9
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 K5TlXz5vyeDs; Thu, 6 Oct 2022 22:47:13 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D821C159A2E; Thu, 6 Oct 2022 22:47:11 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 37F243AB014; Fri, 7 Oct 2022 05:47:10 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 37F243AB014
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.1.12
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1665121630; cv=none; b=dtljzneLYgdbdG0yaFd8W8e89eg0XKT5tkNrdOVUS+gvaVtkqFr3QaZ5BVRday3kSv5VgpLB6ZEsyEOslAXa8V7EBRnMhkGhzI29sJoEGItLaC5jD7HjxbVk3jHx0Ev+EQILyFJQXRfCs2SQP+iPv5x1xpaUrfPAOvzhMzgTylo=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1665121630; c=relaxed/relaxed; bh=+ftJ7GN2Ea5q+ygWXgtgCmdazx4Zz2U7J/Rc8hY19Z8=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=KevMonVoR0U8rGC6kWJ6Hj8XbxGpo51Xco22vumT1syYNQe9AYNQB0LozpWAdmYQNcjYI8agEbclSQaFOKJR9tI0VoI9Dgq4wJTDeyjpA+uRmbTACjxOK1u8g/LLDi7udgPuW245w/YKgvuTMb4UJMqOXdb3AET/B+3XkePhAzY=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 37F243AB014
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1665121630; bh=JHJwwPs8T0elyo3GKuMTBgXVSYGSC9NsRSwZg1y08OE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=BjjMpWvWc74g9zuKSwvboypO5Fn0b2A+BXxKoyLhPvs73mi0kEGc8S41+tbF/SAug 6dN8xbT+BDE3Vvstk6Bvt12Fo6zXvKp4npH+uBUiR4O7Yti3Bf4+9VE9X12cTvycg3 yeZjgAtJNwnIDZMbQPChe0ScZQJe1YTJqIX3UlHI=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 22702E082F4; Fri, 7 Oct 2022 05:47:10 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 5D30AE082F9; Fri, 7 Oct 2022 05:47:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 5D30AE082F9
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1665121629; bh=+ftJ7GN2Ea5q+ygWXgtgCmdazx4Zz2U7J/Rc8hY19Z8=; h=Mime-Version:From:Date:Message-Id:To; b=d/NJtNM95l5943shDovK03m0VjQFe/7OlHP62RYXF8wkjmEQJfwA/FbaTdy+AJKeM 3G+aTwxKAAFBBNQ8VyPlDWUAaHvs4xXoDkEO6iiR+jQaYmmbY/d2TLx15u+ubDONa2 dKMR5Ye57bBwAwNm5AZ6v+NrSPDHdl8om8MbPhpM=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id s8m52YKi59wg; Fri, 7 Oct 2022 05:47:09 +0000 (UTC)
Received: from smtpclient.apple (n49-187-27-239.bla1.nsw.optusnet.com.au [49.187.27.239]) by zimbrang.isc.org (Postfix) with ESMTPSA id 1F087E082F4; Fri, 7 Oct 2022 05:47:07 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAD9w2qaiUypShb15E14sv8D0xaFw7QAoJ7QUmv2EXdaFvtM5+Q@mail.gmail.com>
Date: Fri, 07 Oct 2022 16:47:04 +1100
Cc: dnsop <dnsop@ietf.org>, 6man list <ipv6@ietf.org>, behave@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1DD12C9-6E0C-47DB-8214-4085BE612F8F@isc.org>
References: <166499026925.13796.13915421299077027396@ietfa.amsl.com> <CAD9w2qaiUypShb15E14sv8D0xaFw7QAoJ7QUmv2EXdaFvtM5+Q@mail.gmail.com>
To: Momoka Yamamoto <momoka.my6@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/j6F-FWkR2Oe8TX_YRX0r3cNibjo>
Subject: Re: [BEHAVE] [DNSOP] New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2022 05:47:17 -0000

While we (ISC) have been working on this for years <https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/2166>, this is yet another example of why DNS64 should be made historic.  This
is requesting even more support to work around problems introduced by DN64, a poorly thought out, supposedly short term hack.

It is NOT needed with 464XLAT, DS-Lite and other transition technologies where the IP stack maps
from IPv4 to IPv6 or the CPE maps from IPv4 to IPv6.

Additionally this is an indication the BCP91 is now out of date.  Best current practice has been
to operate dual stack servers for many years now.

Mark

> On 7 Oct 2022, at 16:12, Momoka Yamamoto <momoka.my6@gmail.com> wrote:
> 
> Hello,
> 
> I have submitted an informational draft that describes resolvers performing IPv4 to IPv6 translation to send queries to IPv4-only authoritative servers.
> We thought it would be beneficial to document that we can operate a resolver with only an IPv6 address if we utilize the NAT64. 
> Despite that it is stated in BCP91 [RFC3901], "every recursive name server SHOULD be either IPv4-only or dual stack."
> 
> Since this is more related to IPv6/IPv4 translation I have submitted the draft to the v6ops wg,
> but because this is DNS related I would very much appreciate it if I could have comments from the dnsop list as well.
> 
> Momoka. Y
> 
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Thu, Oct 6, 2022 at 2:17 AM
> Subject: New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt
> To: Momoka Yamamoto <momoka.my6@gmail.com>, Toyota Yasunobu <yasnyan@sfc.wide.ad.jp>
> 
> 
> 
> A new version of I-D, draft-momoka-v6ops-ipv6-only-resolver-00.txt
> has been successfully submitted by Momoka Yamamoto and posted to the
> IETF repository.
> 
> Name:           draft-momoka-v6ops-ipv6-only-resolver
> Revision:       00
> Title:          IPv6 only iterative resolver utilising NAT64
> Document date:  2022-10-05
> Group:          Individual Submission
> Pages:          9
> URL:            https://www.ietf.org/archive/id/draft-momoka-v6ops-ipv6-only-resolver-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/
> Html:           https://www.ietf.org/archive/id/draft-momoka-v6ops-ipv6-only-resolver-00.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-momoka-v6ops-ipv6-only-resolver
> 
> 
> Abstract:
>    By performing IPv4 to IPv6 translation, IPv6-only iterative resolvers
>    can operate in an IPv6-only environment.  When a specific DNS zone is
>    only served by an IPv4-only authoritative server, the iterative
>    resolver will translate the IPv4 address to IPv6 to access the
>    authoritative server's IPv4 address via NAT64.  This mechanism allows
>    IPv6-only iterative resolvers to initiate communications to IPv4-only
>    authoritative servers.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org