IETF Logo Mail Archive

Re: [v6ops] reclassify 464XLAT as standard instead of info

Mark Andrews <marka@isc.org> Fri, 22 September 2017 07:07 UTC

Return-Path: <marka@isc.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240E9132932 for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 00:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 YNt5pjtqbFyJ for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 00:07:25 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 32D3B1252BA for <v6ops@ietf.org>; Fri, 22 Sep 2017 00:07:25 -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 F3F4734B072; Fri, 22 Sep 2017 07:07:22 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E0CE7160074; Fri, 22 Sep 2017 07:07:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CE4B7160042; Fri, 22 Sep 2017 07:07:22 +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 E9qdwRJe4A_f; Fri, 22 Sep 2017 07:07:22 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7F865160031; Fri, 22 Sep 2017 07:07:22 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 74AA687A424E; Fri, 22 Sep 2017 17:07:19 +1000 (AEST)
To: Lorenzo Colitti <lorenzo@google.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "v6ops@ietf.org WG" <v6ops@ietf.org>
From: Mark Andrews <marka@isc.org>
References: <D5E8043B.86B21%lee@asgard.org> <E48DDA04-C058-4992-906E-8C8BC0E102AB@consulintel.es> <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <de6b9aac-a3cc-0915-77c7-9fb880c3a16a@gmail.com> <20170921223305.B72A8878E716@rock.dv.isc.org> <CAKD1Yr13ijKCB_71_2vMyGurc3-kSraLJycGxZwf121tjp8u1Q@mail.gmail.com>
In-reply-to: Your message of "Fri, 22 Sep 2017 15:17:45 +0900." <CAKD1Yr13ijKCB_71_2vMyGurc3-kSraLJycGxZwf121tjp8u1Q@mail.gmail.com>
Date: Fri, 22 Sep 2017 17:07:19 +1000
Message-Id: <20170922070719.74AA687A424E@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/c0xLFjYKc4LMeZEpf6mHjOaPDaY>
Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Sep 2017 07:07:27 -0000

In message <CAKD1Yr13ijKCB_71_2vMyGurc3-kSraLJycGxZwf121tjp8u1Q@mail.gmail.com>, Lorenzo Colitti writes:
> On Fri, Sep 22, 2017 at 7:33 AM, Mark Andrews <marka@isc.org> wrote:
> 
> > Because 464XLAT is almost always deployed with DNS64 (there are
> > potentially other ways to learn the address mappings):
> >
> > YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING
> > TERMINATED ON A IPV6 NODE.
> >
> 
> Why don't you? All you need to do is compare the destination address with
> the NAT64 prefix. If it's in that prefix, then it's an IPv4 node, otherwise
> it's an IPv6 node.

Thank you for proving my point.

IPv6 applications need to add code to WORKAROUND breakages caused
by NAT64 the way they need add WORKAROUNDS for the NAT breakages
even if they are not using NAT64 or NAT respectively.  The cancer
that is NAT64 needs to be eradicated.

Mark
-- 
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