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

Momoka Yamamoto <momoka.my6@gmail.com> Sun, 16 October 2022 17:09 UTC

Return-Path: <momoka.my6@gmail.com>
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 8F851C14F747; Sun, 16 Oct 2022 10:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.857
X-Spam-Level:
X-Spam-Status: No, score=-1.857 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qH3JiGj1bcWq; Sun, 16 Oct 2022 10:09:49 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 7C924C14F723; Sun, 16 Oct 2022 10:09:49 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id e18so13057506edj.3; Sun, 16 Oct 2022 10:09:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vk+LlW8TALg48e27WxYFKHEfsgIT4123jArKxK5t7g0=; b=i04pgPsBWU5D9+jbji2JF+f3xr2wtN1XwpaQSb5HdhRSawn711SW2J66VMqe4k6Do9 5259tlBLMqJZoTfoWhhBxF/3cxvBI1KKAVluFwD20DG3+IndaNCF0jSutw8iWagnZA0g UuTVCi9VO1EtOXMsjVPIPyDTUSWaG9BXGjPBh7GtF9jxxc/bSqaIJTRgJy+1ciNxLgUI cmDJY0+BNX3YsnNf83RHXBG4YqPwEDQJVKhALwxDLoWho2v8OB0VjdVO2tf0DcYjK99x m8IW6sukorgcTcX+BTXHKwyBJQJpxo4zqZFzOjGFZaNVvCsrvlpyrrpPTDT4Ewl0WO4t U12A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vk+LlW8TALg48e27WxYFKHEfsgIT4123jArKxK5t7g0=; b=O1i5hrK0Qs04Zt8NfpjuYHs42aFExccAauJPPjqOe0DfYn0bfSAskoYQ++IcWDH/PX YODqKJUpGgHbnhOcxEG/rm0EYkjUaMJZ9Gne3I60ilE17BnQSPGd/jm6qJQwGnoCdSrS j/ChDdjssK/LIuz5UJ7bLGwJ/HJqEr1sNdkkQuDvUaK1IO1HHWVVLfAS+VrQMTtMWf9d L08C9SoC/fU42VNjqARk1Fj/gch6VS8eGBrmeQ+ZCjfkwtHNRxD42j34+k/nMlU4m44N eO7xgUltSlIE+vbBwDKzVD1A2Z5thOZ46hjcDovhL4pdS5VJNLiJ1OQ1zpyMxnmzhdwG 6/+g==
X-Gm-Message-State: ACrzQf0/FshYxFP6M+1TF2RbANDQjK5w8hEIkkfuHUNjtC8iCKImOPML y1vL+i8nv9gp8AIq8aJOksJvDs4l/kQ9IGdatPVPMDkbTr4HA4H0
X-Google-Smtp-Source: AMsMyM78ugo5KxgcyITwAtf2rqUVEElw4k0sCjzFYyDg4b/i1ZjDFpguGHw0yrqObdq0Mpfnw7yztTBAdFSWpGcmBAM=
X-Received: by 2002:a05:6402:1cc1:b0:45c:3a90:9499 with SMTP id ds1-20020a0564021cc100b0045c3a909499mr6988648edb.61.1665940186766; Sun, 16 Oct 2022 10:09:46 -0700 (PDT)
MIME-Version: 1.0
References: <166499026925.13796.13915421299077027396@ietfa.amsl.com> <CAD9w2qaiUypShb15E14sv8D0xaFw7QAoJ7QUmv2EXdaFvtM5+Q@mail.gmail.com> <A1DD12C9-6E0C-47DB-8214-4085BE612F8F@isc.org> <CAD9w2qZcpXHtLJ_e339vXNcngWLUUX=2QkvJK+Ft2rHUpPybVw@mail.gmail.com> <B5053FB6-CA61-44F6-9950-2B34F05C0A8B@isc.org>
In-Reply-To: <B5053FB6-CA61-44F6-9950-2B34F05C0A8B@isc.org>
From: Momoka Yamamoto <momoka.my6@gmail.com>
Date: Mon, 17 Oct 2022 02:09:35 +0900
Message-ID: <CAD9w2qZedv6zedSkTfa=4SyhXwc2r__xccEQsJq0o4okKDtPpg@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: dnsop <dnsop@ietf.org>, 6man list <ipv6@ietf.org>, behave@ietf.org, v6ops@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000ca07f05eb29ed75"
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/6rwKO-Tkv74AykF2CnmXXjveb9s>
Subject: Re: [BEHAVE] [v6ops] 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: Sun, 16 Oct 2022 17:09:53 -0000

Thank you for your feedback Mark,

Having the OS's support is great in the way that all applications on the OS
can use IPv4. However, we thought that in theory (but maybe not currently)
an iterative resolver is the only application that actually needs IPv4 to
operate.
You may have concerns for DNS64 (because of DNSSEC?) but we feel that it is
the best solution, and with DNS64/NAT64 all applications that use domain
names can connect to IPv4 hosts with IPv6.

We wrote this draft specifying an iterative resolver because DNS is
special. An iterative server is the only application that needs IPv4
support (please inform me if I'm wrong. my understanding of other
applications needing IPv4 is that they just haven't added IPv6 support
yet). Any other application can use DNS64/NAT64 and send IPv6 packets to
IPv4 hosts.
Unlike applications where both the server and client can be tweaked, DNS is
internet global and cannot be changed by self-help. The current state of
iterative resolvers needing support for IPv4 protocol, is a major barrier
to the future migration to IPv6.

If an iterative resolver is the only software that truly needs IPv4
support, forcing the OS to support the new protocol when only one piece of
DNS software can do it may slow down the progress of the IPv6 migration
roadmap.

Momoka


On Mon, Oct 10, 2022 at 10:24 AM Mark Andrews <marka@isc.org> wrote:

>
>
> > On 9 Oct 2022, at 04:58, Momoka Yamamoto <momoka.my6@gmail.com> wrote:
> >
> >
> > re: Mark Andrews 's comments
> > > 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.
> >
> > We did not write this draft thinking DNS64 has a problem.
>
> I didn’t think you did but it highlights the problems with DNS64.  DNS64
> does not work with address literals.
>
> > We thought that IPv6-only iterative resolvers not existing because of
> IPv4-only authoritative servers is a problem, and wanted a way to solve it
> from the resolver side and not only from the network side (e.g. using
> 464XLAT).
>
> Why do you think that promoting this niche fix is better that promoting
> that OS’s support 464XLAT, DS-Lite at the OS level?  The later fixes the
> issues for every application on the node.  We have well specified
> signalling for when a node to bring up 464XLAT, MAP-E, MAP-T, DS-Lite.  We
> should be encouraging nodes to do just that when the signalling is
> present.  We should be encouraging CPE router vendors to support copying
> the signalling from the ISP side to the internal side similar to how they
> do with DNS recursive server signalling by default except when configured
> not to.
>
> If a node can’t attach to an IPv6-only network and use the transition
> mechanism offered without applications have to know anything about it then
> it is deficient. DNS servers are an application in this context.
>
> The IETF should be trying to winnow down the number of transition
> mechanisms that vendors need to support. Less is actually more here and
> unfortunately we have not done a good job of pushing back on excessive
> choice.
>
> Mark
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>
>