Re: NAT64 in RA, draft-ietf-6man-ra-pref64

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 28 June 2019 18:55 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D781201B5 for <ipv6@ietfa.amsl.com>; Fri, 28 Jun 2019 11:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfHtZwmaoKal for <ipv6@ietfa.amsl.com>; Fri, 28 Jun 2019 11:55:51 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20C7120189 for <6man@ietf.org>; Fri, 28 Jun 2019 11:55:50 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 8184D38183; Fri, 28 Jun 2019 14:54:02 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 10EA8B1F; Fri, 28 Jun 2019 14:55:49 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Mark Andrews <marka@isc.org>
cc: Jen Linkova <furry13@gmail.com>, 6man@ietf.org
Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64
In-Reply-To: <6EC0FA5C-9B87-46A5-BD2D-93E2E2C85291@isc.org>
References: <12187.1558972629@localhost> <D3C7EB41-02E8-48D6-9335-26A041FD64C2@isc.org> <00C00FE5-C7CD-4B99-A2C9-CCBFCB1E4850@isc.org> <CAFU7BASfJ4YS6xBzK8hNJRSMnFZmdn3VE5A=sPCC3JqRa8SQEQ@mail.gmail.com> <EC63A89D-26CD-4093-8814-4461B6D3D327@isc.org> <CAFU7BASsAwitEc==Zj6qT4izy-tFosg23DHXFVVzOixidEfMFA@mail.gmail.com> <6EC0FA5C-9B87-46A5-BD2D-93E2E2C85291@isc.org>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 28 Jun 2019 14:55:49 -0400
Message-ID: <4632.1561748149@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6_ICiLwdjxIiIUhgBCQytVGKQfQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jun 2019 18:55:53 -0000

Mark Andrews <marka@isc.org> wrote:
    >>> While the first label doesn’t have to be _dns64, having a leading underscore
    >>> takes it out of hostname namespace.
    >>
    >> Stupid question: why can not we reserve a well-known label (_dns64 ?)
    >> and let the client to request APL in the domains from its search list?

    > Because there is no requirement to publish a search list and if you are
    > sane you ignore them.  Search list are also badly implemented the same
    > unqualified name to match to different fully qualified names depending
    > upon the query type in the request as search algorithms don’t stop on
    > noerror/nodata and some don’t stop on servfail either.  There is a lot
    > of history behind the behaviour.

Mark, thank you for the your reply, because I didn't understand the _dns64
proposal.  Now that you mention that it depends upon search list, I'm very
very much against it.  No sane laptop user or smartphone pays attention to
search lists, and captive portals that depend upon them are really really
broken.

It's taken me a bit of connecting the dots to understand this proposal,
but now that I understand it, I'm pretty happy with it.

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