IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Fri, 28 June 2019 21:03 UTC

Return-Path: <marka@isc.org>
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 EBF3E12028B for <ipv6@ietfa.amsl.com>; Fri, 28 Jun 2019 14:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 gdHCroG-gVjG for <ipv6@ietfa.amsl.com>; Fri, 28 Jun 2019 14:03:50 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466B8120916 for <6man@ietf.org>; Fri, 28 Jun 2019 14:03:50 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id BDD623AB08E; Fri, 28 Jun 2019 21:03:49 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AFCD716006F; Fri, 28 Jun 2019 21:03:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A1B7216006C; Fri, 28 Jun 2019 21:03:49 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m2IHqzQWnfyq; Fri, 28 Jun 2019 21:03:49 +0000 (UTC)
Received: from [172.30.42.88] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 60950160068; Fri, 28 Jun 2019 21:03:49 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64
From: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <4632.1561748149@localhost>
Date: Sat, 29 Jun 2019 07:03:46 +1000
Cc: Jen Linkova <furry13@gmail.com>, 6man@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F90899E-71DF-46BB-A2AB-CE0E8274C585@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> <4632.1561748149@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IODDe-CGH0lKMw5eQUYRrsNOtW0>
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 21:03:52 -0000

Except it DOES NOT depend on search lists. The name is absolute. I was pointing out to Jen why depending on a search list was a bad idea. 

Please go back and re-read the proposal. 

-- 
Mark Andrews

> On 29 Jun 2019, at 04:55, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> 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 =-
> 
> 
>

v2.23.0 | Report a Bug | By Email