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

Tore Anderson <tore@fud.no> Fri, 31 July 2015 20:17 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 383661ACD35; Fri, 31 Jul 2015 13:17:23 -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 0ia0SYH5IMeG; Fri, 31 Jul 2015 13:17:22 -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 EB22C1A88D0; Fri, 31 Jul 2015 13:17:21 -0700 (PDT)
Received: from [2a02:fe0:c412:1fe0::2] (port=46204 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 1ZLGk1-0000Gg-GC; Fri, 31 Jul 2015 22:17:17 +0200
Date: Fri, 31 Jul 2015 22:17:16 +0200
From: Tore Anderson <tore@fud.no>
To: Toerless Eckert <eckert@cisco.com>
Message-ID: <20150731221716.5729154a@envy.fud.no>
In-Reply-To: <20150731174421.GA9032@cisco.com>
References: <20150730205806.GI1667@cisco.com> <CAD6AjGSKc0jGSkgSKdMsY1gZwYYguJQ06f4nZsWEqBdR9J3e6w@mail.gmail.com> <55BBA7C1.3000502@gmail.com> <20150731174421.GA9032@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/Y76fAqFZETJ-NAdcYTDpXRv5zHY>
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: Fri, 31 Jul 2015 20:17:23 -0000

* Toerless Eckert

> On Sat, Aug 01, 2015 at 04:52:17AM +1200, Brian E Carpenter wrote:
> > Yes, but we assume that during the phasing-in of autonomic
> > operations, we will be forced to interface to legacy NOCs.
> 
> Right. It's just like siit-dc, just the opposite: We want to enable
> the IPv6 only autonomic network (like they an IPv6 only DC) of course
> to also encourage the IPv6 centric/only NOC but to get started also
> provide a simple, isolated, and easily removed solution (hack ?) to
> connect to legacy IPv4 NOC in our case (in siit-dc some legacy IPv4
> (network)).

Yep, but be aware that with SIIT you will need to identify all
the IPv6 endpoints you want the IPv4-only NOC folks to be able to
access. These endpoints need either to be provisioned with an
IPv4-translatable IPv6 address (traditional SIIT), or get an IPv4
mapping provisioned on the protocol translator (SIIT-DC style
deployment with EAMs). 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).

Anyway if the IPv6-only autonomic network is very dynamic in nature
and/or have a large number of managed endpoints that must be reachable
from the IPv4-only NOC, that requirement could possibly be problematic.

BTW you asked about traceroute, and I don't think anyone answered, so:
ICMPv6 packets originated by IPv6 hops behind the translator (that are
not provisioned with an IPv4-translatable IPv6 address) will appear as
originating from a "random" IPv4 address (which could repeat multiple
times in the path). That could possibly be confusing to NOC staff, so
I'd suggest giving the RFC6791 addresses descriptive PTR records in DNS
("this-apparent-ipv4-hop-really-represents-an-ipv6-router-in-the-autonomic-network-see-rfc6791.example.com").

> Actually i now think siit-eam is the easiest way - which i think is
> an extension of stateless NAT64, but i don't claim i am using all
> the terminology right.

Let me know if you want some help or pointers on how to set up a
stateless translator for testing purposes. Or you could use one of
mine, as it works just as well over the public internet too (as long as
the IPv6 endpoints you want to manage are numbered with globally
reachable addresses). I'd be happy to assist.

Tore