Re: [BEHAVE] [v6ops] protocols without need for ALG ?

Tore Anderson <tore@fud.no> Sun, 02 August 2015 15:25 UTC

Return-Path: <tore@fud.no>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54341AC3C2; Sun, 2 Aug 2015 08:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.91
X-Spam-Level:
X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_44=1, T_RP_MATCHES_RCVD=-0.01] autolearn=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 D6NrUTZdJkw1; Sun, 2 Aug 2015 08:25:01 -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 572331AC3B5; Sun, 2 Aug 2015 08:25:01 -0700 (PDT)
Received: from [2a01:79d:4fcf:67e4:b6b6:76ff:fe17:2e83] (port=57027 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 1ZLv8D-00025E-Ir; Sun, 02 Aug 2015 17:24:57 +0200
Date: Sun, 2 Aug 2015 17:24:56 +0200
From: Tore Anderson <tore@fud.no>
To: Toerless Eckert <eckert@cisco.com>
Message-ID: <20150802172456.39635936@envy.fud.no>
In-Reply-To: <20150801093303.GA4585@cisco.com>
References: <20150730205806.GI1667@cisco.com> <CAD6AjGSKc0jGSkgSKdMsY1gZwYYguJQ06f4nZsWEqBdR9J3e6w@mail.gmail.com> <55BBA7C1.3000502@gmail.com> <20150731174421.GA9032@cisco.com> <20150731221716.5729154a@envy.fud.no> <20150801093303.GA4585@cisco.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/behave/dJteI-pb5TiaqD2ZjiRsJxJoS6k>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] [v6ops] protocols without need for ALG ?
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Aug 2015 15:25:02 -0000

* Toerless Eckert

> On Fri, Jul 31, 2015 at 10:17:16PM +0200, Tore Anderson wrote:
> > You could also use Stateful NAT64 (RFC6146)
> > with statically configured BIB entries to accomplish pretty much the
> > same thing as the SIIT-DC approach, but you do get a lot of superfluous
> > baggage that way (all the stateful connection/session tracking stuff).
> 
> Is there a Yang model for 4146 so i can beter understand what the
> intended operator experience is ? ;-))
> 
> Yes, it does mention "static configured mapping" in three places in the
> text, and i see in Cisco IOS implementation also the ability to
> configure 1:1 IPv4<->IPv6 mappings, and i therefore guess that these
> are the "static configured mappings" of 4146, but what i can't find
> is any explanation why the operations of such entries would have
> to be stateful at all. What would those 4146 entries do different than
> stateless siit-eam /32 <-> /128 entries, and whats the "benefit" ?

Well, one implementation I tested (Cisco ASR1K) allowed these 1:1
IPv4<->IPv6 mappings in Stateful NAT64 mode. However I noticed that it
did install session table entries for every connection made towards the
statically mapped IPv4 address. Not sure if those session table entries
were ever used for anything though.

Another implementation (Jool) would allows adding static BIB entries in
Stateful NAT64 mode, but it requires you to also include the ports used
- so if you wanted to do a full 1:1 mapping between an IPv4 address and
an IPv6 address you'd have to add 64k static BIB entries in order to
make traffic to arbitrary ports work...

> But obviously, in a network with 50,000 IPv6 nodes with ULAs,
> i wouldn't want to set up an orchestration to configure 50,000
> 1:1 entries, even stateless, but rather a single /16 <-> /112
> (or a few similar slightly longer prefixes). 

Indeed, if the IPv6 destinations are nicely aggregatable in a small
prefix like a /112 SIIT with an EAM sounds like exactly what you want.
I'll follow up off-list.

Tore