IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Tue, 02 July 2019 04:40 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 C1D2012008D for <ipv6@ietfa.amsl.com>; Mon, 1 Jul 2019 21:40:50 -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 jV-O2JMdEEfn for <ipv6@ietfa.amsl.com>; Mon, 1 Jul 2019 21:40:48 -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 9AAC012004D for <6man@ietf.org>; Mon, 1 Jul 2019 21:40:48 -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 7DCC93AB005; Tue, 2 Jul 2019 04:40:48 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6CAFD160048; Tue, 2 Jul 2019 04:40:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 550F5160096; Tue, 2 Jul 2019 04:40:48 +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 59xqwyy-p-RJ; Tue, 2 Jul 2019 04:40:48 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 82769160048; Tue, 2 Jul 2019 04:40:47 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: NAT64 in RA, draft-ietf-6man-ra-pref64
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAAedzxqy5U5g23xej6TYG-Zu-VWeoHfMcdKYE4cOBTg_0XwtWg@mail.gmail.com>
Date: Tue, 02 Jul 2019 14:40:45 +1000
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6man <6man@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <26E61B05-CEF8-4D9C-9BB7-6BE2C0E4DC62@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> <7F90899E-71DF-46BB-A2AB-CE0E8274C585@isc.org> <25567.1561758875@localhost> <CAAedzxqy5U5g23xej6TYG-Zu-VWeoHfMcdKYE4cOBTg_0XwtWg@mail.gmail.com>
To: ek@loon.com
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/vRFd4Pj1qX_P_bYZO9t1obWKAy0>
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: Tue, 02 Jul 2019 04:40:51 -0000

> On 2 Jul 2019, at 10:48 am, Erik Kline <ek@loon.com> wrote:
> 
> 
> 
> On Fri, 28 Jun 2019 at 14:54, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> Mark Andrews <marka@isc.org> wrote:
>     > 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.
> 
> To clarify, I think there are two ideas:
> 
> 1) reserving _dns64, + search list to get APL
> 2) sending the absolute name to get APL.
> 
> I understand you are proposing (2), and I'm thanking you for clarifying that.
> 
> Am I right in reading that https://tools.ietf.org/html/rfc3123 is Experimental?  Did another doc change the status of APL RRs?

No.

> I like APL RRs, but if we want a standards track type RA option, should APLs get a bump in status first (purely for the lie-flat seats, of course)?

I don’t see the need.  It’s not required.  It’s just something that has to be noted in the write up.

If the primary doesn’t support APL in (RFC 3123) text format it should support it in unknown record format (RFC 3597).  All intermediate servers and resolvers (including stub resolvers) if they are STD13 compliant will handle it.  It is just a opaque blob of data to be transferred and STD13 requires *all* resolvers to be able to lookup and return unknown types as opaque data.  Yes, this is a forward compatibility requirement in STD13.

All that is required is that there be a stable reference which we have with RFC 3123.

> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email