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

Momoka Yamamoto <momoka.my6@gmail.com> Sun, 16 October 2022 17:30 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 80987C14F722; Sun, 16 Oct 2022 10:30:06 -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 qsmfwU6bjAML; Sun, 16 Oct 2022 10:30:04 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 3F750C14F693; Sun, 16 Oct 2022 10:30:04 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id k2so20336321ejr.2; Sun, 16 Oct 2022 10:30:04 -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=jb92OBR+VaUfra9fGeABy+fFh8D7BMPQT1ldlj01viA=; b=JP2tfv0KyYJETzzxUFjKn+gqpg8xL6/WwFwSx2nJMQL8VQ/yMesJTqvHeh6J/mwBZ0 f/yNEBTDGuCU0msdEbvaKOy8/lKEVFtexaaPQLcQ6Aj9U27sc1/ZKhcfef83JvBrt/5Q HCL0dt19L1qis03d+WQeW1QYl28XzaSiF9gLLWJY5u6BiCssNjSwr0Gg0+GwJpsGUI+8 tSVghOTwDevMe/O2TPko9PdBDZYEXcNrVckKNPSW06IO+C88lyE/nWZTrM4FKiOi9EN0 ovh9kFA0sj/HiTVul2hFeUClSx/qMrnw+dqYLCDGBJ4cqFAk7oQtN0LzZ/6E71wVqGLX tIVg==
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=jb92OBR+VaUfra9fGeABy+fFh8D7BMPQT1ldlj01viA=; b=TAg6uAP4mY1RTs6YdxBoHGt142a19meo1U5s2cqf3kaWiW9uKXyPo3cEMvF+lICzOE 9MjjVJsuOaaeSKhqg8aDTADnzov9XdzxlVpIJm5wtuvHfcug/ExD1/6PqeOwQJ/Ych+8 RPsyVV6eo3VqUIiqfUpdVfGxdfZkn5qgCArZcM2+bfRGpcw078aSt6m5Cu+ysuKb84Pe N3OW4fBNEcphv4pLeBBVqhBYlHQd2FEG/xw+w0tcZA+ntkeriauQrfXzvyszWPjojBTQ 8Uk1jrBElB6X3c89KlSqXDGb83x+VZqgw+RL3sAkaQRD5dfVplkmDPeyEFLX+E+qJx6i xYKw==
X-Gm-Message-State: ACrzQf2WGecPQXkn9gKcbyWnUYuRcWh2IZEHSVxzYAvVf873W+pIG5Gs zextmRNDju4TJ18TdOCnuhseqyQUOryhERMDTMay3hG8AdCMMqhI
X-Google-Smtp-Source: AMsMyM4tRW5L8PUavd+6aJCgA+y3n2z+tXlG6aA693ugRZq33fUhuy8spiogXXdM2aeh/zvNJpCw3QZoatvxrXkb6PU=
X-Received: by 2002:a17:906:ef8c:b0:78d:96b9:a0ad with SMTP id ze12-20020a170906ef8c00b0078d96b9a0admr5849981ejb.529.1665941402339; Sun, 16 Oct 2022 10:30:02 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9w2qZcpXHtLJ_e339vXNcngWLUUX=2QkvJK+Ft2rHUpPybVw@mail.gmail.com> <AF7B8CE4-3EC3-4C1C-8467-4D25D7CA2E56@hopcount.ca>
In-Reply-To: <AF7B8CE4-3EC3-4C1C-8467-4D25D7CA2E56@hopcount.ca>
From: Momoka Yamamoto <momoka.my6@gmail.com>
Date: Mon, 17 Oct 2022 02:29:50 +0900
Message-ID: <CAD9w2qbBrDyBCXuLbmx_9sJCbMbTXb4wwVeP=8fa5Q646oQF+A@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: Mark Andrews <marka@isc.org>, dnsop <dnsop@ietf.org>, 6man list <ipv6@ietf.org>, behave@ietf.org, v6ops@ietf.org
Content-Type: multipart/alternative; boundary="00000000000080cdeb05eb2a3551"
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/Nio9hcDIiK7vX0PXPhC6aX8_WIA>
Subject: Re: [BEHAVE] [DNSOP] [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:30:06 -0000

Thank you for your comments.

I think the word "dual-stack" can mean different states for people.

My understanding was that a client under a NAT64 that can only send IPv6
packets is an IPv6-only client.
It may contact IPv4 servers using DNS64 and NAT64, but the client
application will be under the illusion that it is contacting an IPv6 server
because of the DNS64 translation.
So the client is only sending IPv6 packets to the internet.

Any other client that uses an IPv4-as-a-Service technology that doesn't use
a DNS64 can be considered "dual-stack" as an application on that client
machine can send IPv4 packets.


In this draft we consider an IPv6 network that uses the DNS64/NAT64
mechanism so all clients are IPv6-only, but the iterative resolver can
still access IPv4 authoritative servers by using the translation method.
The machine it is hosted on is IPv6-only but the DNS resolver software can
perform the translation mechanism.

We thought this might be useful to document as we thought that an iterative
resolver is the only software that theoretically needs IPv4.

Momoka



On Sun, Oct 9, 2022 at 5:31 AM Joe Abley <jabley@hopcount.ca> wrote:

> Hi there,
>
> On Oct 8, 2022, at 13: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.
> 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).
>
>
> A host connected to a v6 network that has access to v4 networks via
> translation mechanisms is a dual-stack host for the purposes of initiating
> queries and receiving responses. It is not a v6-only resolver in a
> practical sense.
>
> Another example of such a host might be one which has v4 connectivity, and
> which has v6 connectivity through a tunnel. That host is also dual-stack.
>
> Your document seems to say, in essence, "your resolver should be
> dual-stack if it needs to be able to send queries over both v4 and v6". But
> this is unsurprising news, since it's basically the definition of
> "dual-stack".
>
> Perhaps I am missing something?
>
>
> Joe
>