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

Gert Doering <gert@space.net> Fri, 22 September 2017 18:29 UTC

Return-Path: <gert@space.net>
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 35DF713458B for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 11:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Q6NCNGaFnBwz for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 11:29:11 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B788134588 for <v6ops@ietf.org>; Fri, 22 Sep 2017 11:29:11 -0700 (PDT)
X-Original-To: v6ops@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3929640BA0 for <v6ops@ietf.org>; Fri, 22 Sep 2017 20:29:09 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 2885C40B9C; Fri, 22 Sep 2017 20:29:09 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 1A42E17E3F; Fri, 22 Sep 2017 20:29:09 +0200 (CEST)
Date: Fri, 22 Sep 2017 20:29:09 +0200
From: Gert Doering <gert@space.net>
To: Lee Howard <lee@asgard.org>
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Message-ID: <20170922182908.GI45648@Space.Net>
References: <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> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <D5EA8233.87034%lee@asgard.org> <D5EAC4D0.870DE%lee@asgard.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <D5EAC4D0.870DE%lee@asgard.org>
X-NCC-RegID: de.space
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/19nCPuLDYjMNemlC5pI_bJCcP64>
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 18:29:13 -0000

Hi,

coming back from my old man's rant (apologies) to the original question...

On Fri, Sep 22, 2017 at 01:55:24PM -0400, Lee Howard wrote:
> As to the original question, I have a couple of questions:
> 
> 1. What is gained by promoting rfc6877 "464XLAT: Combination of Stateful
> and Stateless Translation????  Regardless of whether the correct promotion
> path is BCP or Proposed Standard, what is the goal?

I do not think much is to be gained.  Implementations already exist,
so pointing to a BCP and asking vendors to "you want this, it's BCP!"
(or "Standard") isn't going to change much.  CPE vendors will add 
it if you wave money at them, and not otherwise, no matter what label
it carries.

> 2. rfc2026 ???The Internet Standards Process???  says a BCP is the "best
> current thinking on a statement of principle or on what is believed to be
> the best way to perform some operations.???  What principle or what
> operations is 464xlat best for?

464xlat is one possible approaches to enabling IPv4-to-IPv4 connections
across an IPv6-only network that provides NAT64 services and no tunneling
services.  So if you have a NAT64 / IPv6-only network already and have 
to care for IPv4-only applications, this might be the best approach.

If you need to transport IPv4 across an IPv6-only network and do not yet
have a NAT64 to use, one of the MAP-E/MAP-T stateless "transport" variants 
might be a *better* solution, given the statelessness of the MAP gateway.

So it depends on your network: if you want "IPv6-mostly" with a bit of
remaining external IPv4 to be handled by the DNS64/NAT64, and a few stubborn
applications insisting on literal IPv4 on the client side, 464xlat is
"best".  Otherwise, maybe not "WCP", but definitely just "one solution in
the toolchest"

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279