Re: [v6ops] v6ops-host-addr-availability: A Little Pushback

Tore Anderson <tore@fud.no> Wed, 23 September 2015 13:54 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 C74FD1B3226 for <v6ops@ietfa.amsl.com>; Wed, 23 Sep 2015 06:54:42 -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 ThyNiGD-s4yx for <v6ops@ietfa.amsl.com>; Wed, 23 Sep 2015 06:54:40 -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 B25AE1B322C for <v6ops@ietf.org>; Wed, 23 Sep 2015 06:54:40 -0700 (PDT)
Received: from [2a02:fe0:c410:2a51::8b1] (port=41644 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <tore@fud.no>) id 1ZekVJ-0006pn-TJ; Wed, 23 Sep 2015 15:54:38 +0200
Date: Wed, 23 Sep 2015 15:54:32 +0200
From: Tore Anderson <tore@fud.no>
To: "STARK, BARBARA H" <bs7652@att.com>
Message-ID: <20150923155432.3224e547@envy.fud.no>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6113AA157E7@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <2D09D61DDFA73D4C884805CC7865E6113AA102BC@GAALPA1MSGUSRBF.ITServices.sbc.com> <20150923091756.604faf11@echo.ms.redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E6113AA157E7@GAALPA1MSGUSRBF.ITServices.sbc.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; 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/t-DhCJzHQPxMC6sbSIb-0Doevtk>
Cc: v6ops list <v6ops@ietf.org>
Subject: Re: [v6ops] v6ops-host-addr-availability: A Little Pushback
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: <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: Wed, 23 Sep 2015 13:54:43 -0000

* STARK, BARBARA H

> Good point. OK, so I change my statement to say that translation
> (like 464XLAT) only applies in an IPv6-only network. I still contend
> that tethering is specific to "3GPP"-type-technology  wireless
> networks.

If you're running virtual machines on your computer, using software
such as VirtualBox, Parallels, KVM, or VMware Workstation; you are in
principle performing tethering.

> > OpenWrt, which most commonly has a wired upstream, does support
> > 464XLAT CLAT operation.
> 
> I think of OpenWRT as router software. I'm not aware of any pure
> hosts using it.

That's right. My point here was that regardless of your uplink being
something wired like Ethernet, DSL, whatever - if you're using OpenWrt
in your home gateway, you can still use 464XLAT as long as you have an
IPv6 uplink and access to a NAT64 service (there are serveral public
ones available over the Internet if you'd like to try it yourself).
I.e., cementing the point that the 464XLAT technology is not specific
to wireless ISPs.

> Do you use 464XLAT inside all the end hosts and offer IPv6-only to
> all hosts inside the data centers? Or do you use it at the edge, and
> provide IPv4 and IPv6 addresses to the hosts? The need to do
> translation (like 464XLAT) is listed in this draft as a justification
> for providing an IPv6 prefix to all end hosts inside all networks
> (including, presumably, inside data centers). I'm still not seeing
> that.

My core network provides NAT64/DNS64 service. Most of the IPv6-only
servers I have are happy with that, since it makes stuff like "git
clone https://github.com/foo/bar" work just fine. So no, far from all
of my IPv6-only servers are using 464XLAT.

However, a minority of the servers need to run software that tries to
do low-level IPv4 stuff directly and fails if it cannot - essentially
because stuff like "ping 8.8.8.8" doesn't work when the node is
IPv6-only. On those servers specifically we activate the 464XLAT CLAT
so that stuff like AF_INET sockets and "ping 8.8.8.8" starts working.
We do not need the server to have a dedicated prefix for this to work,
but it *does* need a second IPv6 address with a global scope.

Tore