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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 21 September 2017 20:39 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 C6CD0133072 for <v6ops@ietfa.amsl.com>; Thu, 21 Sep 2017 13:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WWgTjZNcVoMD for <v6ops@ietfa.amsl.com>; Thu, 21 Sep 2017 13:39:29 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B32133065 for <v6ops@ietf.org>; Thu, 21 Sep 2017 13:39:29 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id j16so4148044pga.1 for <v6ops@ietf.org>; Thu, 21 Sep 2017 13:39:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qO6wMSugkbRntEp5VAio9HA1gnDfNIhGnDEComCH3Ok=; b=tDoOQLZlyswWKYwPFdT+FWN6P/y0UcgPDHcy+b3rmDPJmOufpnmrlh28f6LPbXr1aA W8rDOotCoSNR8g5AdpKPPK3kp0U8O3Ku9WbbDQBbaS7Wxj+7miol/RAPnMa9pau34BBD bkvQjeWPpSxSd7XVRT3/9wLSsmBOlPXyKImXwYycqTcQwcKZcsVdOwpozNgKStKWO0t3 FZTMzMyVJvX/BNgKHzKOqCjrUjg51h48LCqkTcZTkpeOtNqR2taXHEt7wxBfbcBqu9B0 3OssnyTNlCLeDKkPx80yabtQUTap9qKBBnqJgcMTzjbqVNd0ArEQwExT1KgJNAkTUjdo Spgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qO6wMSugkbRntEp5VAio9HA1gnDfNIhGnDEComCH3Ok=; b=l6UVYd3i0wfRmp/VC7fv81DeWaQPSlXceep+tyXfI/7wcV/oZzJVk1gCOi7h5H1DVR kUH/kT6VzOvWAJyX7rnnzjiVRpIpzRf4NyxLERA4CdFGkQVXNZKYAyo0EbQl+ShEj87s 8bFMHD0G8f77XE1JUSoOcYonoePfutuNlrmkTObeg3q+JvWt8eHzfDxaKcon+w2TYm1K ulGGvE1h7Rv4TevWqfZ7rkrtmT56r2AQbJrxCentQEaxkrg4fgvSWMxooIMJ29AN7Z7w EuOjc5826pz913YZuRHooHvBiJuD1SpcpUqimz3WvzxVvYKk39RkjhawV4wQDsFlIV0v Ks7g==
X-Gm-Message-State: AHPjjUj5yhg4IfwU3sC/6a5oDLW0SzEdFFJt8D4FBfr/SdbH18zXYJDk L4yhNkYMskjW/Ror1qzQjxwdOw==
X-Google-Smtp-Source: AOwi7QAtcoNpJPkSY4dSIIdf1d2TYAQceXtvNtjB9WrvH6Itgyl67bRCUx66pw68H95V2gUuwiqYTQ==
X-Received: by 10.99.96.10 with SMTP id u10mr7000515pgb.370.1506026368222; Thu, 21 Sep 2017 13:39:28 -0700 (PDT)
Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s81sm5314685pfg.162.2017.09.21.13.39.26 for <v6ops@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Sep 2017 13:39:27 -0700 (PDT)
To: v6ops@ietf.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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <de6b9aac-a3cc-0915-77c7-9fb880c3a16a@gmail.com>
Date: Fri, 22 Sep 2017 08:39:34 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/sgl-DXPmEUAKNy6UqApi_GYehPM>
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 20:39:31 -0000

On 21/09/2017 20:05, Ole Troan wrote:
>>>>> 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. ;-)

We have a problem in that people confuse "a standard" with "the standard" and
"a best current practice" with "the best current prcatice". But in the end that's
just a matter of wording in the Abstract and Introduction. We say: if you want
to run a pure IPv6 network service while supporting IPv4-only clients and servers,
and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a good way to do it.

That does sound like a BCP to me.

    Brian