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

Ole Troan <otroan@employees.org> Thu, 21 September 2017 08:05 UTC

Return-Path: <otroan@employees.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 E18C9133072 for <v6ops@ietfa.amsl.com>; Thu, 21 Sep 2017 01:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zowSS8Vrz1LV for <v6ops@ietfa.amsl.com>; Thu, 21 Sep 2017 01:05:06 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87437132025 for <v6ops@ietf.org>; Thu, 21 Sep 2017 01:05:06 -0700 (PDT)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 31DE82D5024; Thu, 21 Sep 2017 08:05:05 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C2CE210B9FF0D; Thu, 21 Sep 2017 10:05:02 +0200 (CEST)
From: Ole Troan <otroan@employees.org>
Message-Id: <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_06A222FF-7A28-4F11-A996-6C96B0A1BA27"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 21 Sep 2017 10:05:01 +0200
In-Reply-To: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk>
Cc: Fred Baker <fredbaker.ietf@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
To: Tim Chown <Tim.Chown@jisc.ac.uk>
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>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/i5xJa9v-4RdDeomO36OdDaA3b5c>
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: Thu, 21 Sep 2017 08:05:09 -0000

>>>> From my perspective, there are multiple interoperable specs. We have several CLAT client implementations/vendors, from different vendors, and they work fine in the same and different operators and interoperate with different NAT64 and DNS64 vendors/implementations.
>>> 
>>> What I’m not sure is, because 464XLAT is basically RFC6145 (SIIT) + RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are already Standards track, if we need also to move them to STD in that case, etc.
>> 
>> I'll repeat myself earlier. Looking at the definitions of the terms, there is no reason it can't or shouldn't be BCP, which our charter does allow us to do, and which is a one-shot standard more appropriate to the case (IMHO). If you want it to be a standardard, a BCP is a standard. Let's advance it to BCP.
> 
> I think there’s an argument for this.
> 
> But there will be people who will argue that encapsulation is the ‘best’ practice.  Is there scope for a BCP by translation and a BCP by encapsulation?  Or would the BCP say NAT64/DNS64/464XLAT is the best way to serve nodes in an IPv6-only network?
> 
> With IPv4 NAT, the IETF didn’t define specific NAT mechanisms, so we ended up with many varieties, with different properties. There’s an argument also I think to nail down one single best translation approach.

Yes, I do wonder in what alternate universe the IETF consensus is that best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-)

Ole