Re: [Snac] where/how to document NAT64 (and DNS64)?

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 25 October 2022 12:45 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: snac@ietfa.amsl.com
Delivered-To: snac@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35555C14F724 for <snac@ietfa.amsl.com>; Tue, 25 Oct 2022 05:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 vrGTRMOkKrUc for <snac@ietfa.amsl.com>; Tue, 25 Oct 2022 05:45:48 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (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 69EEEC14F613 for <snac@ietf.org>; Tue, 25 Oct 2022 05:45:48 -0700 (PDT)
Received: from dyas.sandelman.ca (unknown [IPv6:2001:67c:64:49:b721:c031:e2bf:f545]) by relay.sandelman.ca (Postfix) with ESMTPS id EFECE1F450; Tue, 25 Oct 2022 12:45:46 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 1918DA09D6; Tue, 25 Oct 2022 08:45:45 -0400 (EDT)
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 15F14A09D5; Tue, 25 Oct 2022 14:45:45 +0200 (CEST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Juliusz Chroboczek <jch@irif.fr>, snac@ietf.org
In-reply-to: <87a65ki522.wl-jch@irif.fr>
References: <CAPt1N1mRS8mVcrv-HHLrHgbgvhDWW_BDq0PqzkPT8smUnG+_SQ@mail.gmail.com> <87czam88dj.wl-jch@irif.fr> <CAPt1N1nZdiCk5FGekiSXdmjd7jTU-Wfx1S9tubEV2xWPbmO3tQ@mail.gmail.com> <941809.1666528999@dyas> <CAPt1N1=urg_bNOmz64if_1p5tangzSfKWpB+o198B8dc=-+43g@mail.gmail.com> <966230.1666535849@dyas> <CAPt1N1m_qh9Es8jJDrPXN=CzH2Gd0sE2YGTo5y6dpHvoDTqzpg@mail.gmail.com> <874jvuzgiy.wl-jch@irif.fr> <CAPt1N1=84JnaC4=VHHMANVM_b3GNTixKwZdcjpvO4k8E_z5aUw@mail.gmail.com> <994282.1666543114@dyas> <87a65ki522.wl-jch@irif.fr>
Comments: In-reply-to Juliusz Chroboczek <jch@irif.fr> message dated "Tue, 25 Oct 2022 12:13:57 +0200."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 25 Oct 2022 14:45:45 +0200
Message-ID: <1619749.1666701945@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/snac/h3Wj2oOM5R-iir2mvsJcuFxAtDs>
Subject: Re: [Snac] where/how to document NAT64 (and DNS64)?
X-BeenThere: snac@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Mailing list for discussing problems relating to the automatic connection of stub networks to existing infrastructure networks. " <snac.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/snac>, <mailto:snac-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/snac/>
List-Post: <mailto:snac@ietf.org>
List-Help: <mailto:snac-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/snac>, <mailto:snac-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2022 12:45:50 -0000

Juliusz Chroboczek <jch@irif.fr> wrote:
    >> c) is there a way to detect if there even is an IPv4 uplink?  DHCPv4 has this
    >> fault that it can't not announce a default route.

    > Why do you have DHCPv4 in the first place if you have no IPv4 uplink?
    > (There's also draft-ietf-6man-ipv6only-flag, but it's expired.)

Because, historically, if you have no DHCPv4, then you have no local connectivity.
ipv6only flag doesn't really help, I think.
It's not that there is no IPv4, it's that there is no default route.

    >> Do we even care here?

    > It gives you early failure.  It reduces Happy Eyeballs traffic.  It
    > reduces the amount of state at the stub router.

I agree that those are good reasons in general.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-