Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

Tore Anderson <tore@fud.no> Fri, 20 March 2015 12:42 UTC

Return-Path: <tore@fud.no>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8BE1A898D for <v6ops@ietfa.amsl.com>; Fri, 20 Mar 2015 05:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ofuMtdD0Fu9P for <v6ops@ietfa.amsl.com>; Fri, 20 Mar 2015 05:42:38 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0152B1B2CE0 for <v6ops@ietf.org>; Fri, 20 Mar 2015 05:42:38 -0700 (PDT)
Received: from [2a02:c0:2:4:6666:17:0:1001] (port=52848 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <tore@fud.no>) id 1YYwG3-0004Lv-F0; Fri, 20 Mar 2015 13:42:35 +0100
Date: Fri, 20 Mar 2015 13:42:04 +0100
From: Tore Anderson <tore@fud.no>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Message-ID: <20150320134204.32af9c67@echo.ms.redpill-linpro.com>
In-Reply-To: <alpine.DEB.2.02.1503200639340.20507@uplift.swm.pp.se>
References: <CAD6AjGT-hG-uvRQvRosrZtfrf0Nb8ne9jy=tD9oh=5zNM42Xsg@mail.gmail.com> <alpine.DEB.2.02.1503200639340.20507@uplift.swm.pp.se>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/RzaMV6YpGcF9R6cjrRgaJoZ1jBc>
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 20 Mar 2015 12:42:40 -0000

* Mikael Abrahamsson <swmike@swm.pp.se>

> Until then, the operating system will have to implement functions
> like 464XLAT to work around this situation. It's not good, but I'd say
> this is pretty typical transition problem.

Yep.

Justine Vick from Microsoft held a very interesting presentation at the
V6 World Congress on Wednesday about their plans to make one of their
buildings IPv6-only. One of the things she had identified a need for
was to have a CLAT in the desktop version of Windows. She had already
established contact with the relevant teams to try to make that happen
(I asked her to add the Windows Server folks to her CC list). Fingers
crossed!

Once we can translate IPv4 on our network borders/edges and keep the
network itself IPv6-only we have way to proceed with the transition.
Hopefully it will eventually dawn on the apps and web sites that use of
literals or depending on AF_INET sockets isn't particularly smart if
they want the optimal performance and functionality. (But if they don't
it's no big deal either, they can get the best-effort service level.)

Tore