Re: [v6ops] draft-ietf-v6ops-siit-eam WGLC

Tore Anderson <tore@fud.no> Wed, 24 June 2015 07:34 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 BB9CF1B310A for <v6ops@ietfa.amsl.com>; Wed, 24 Jun 2015 00:34:03 -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 Z3pZzXhQ3cmD for <v6ops@ietfa.amsl.com>; Wed, 24 Jun 2015 00:34:02 -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 386211B3109 for <v6ops@ietf.org>; Wed, 24 Jun 2015 00:34:02 -0700 (PDT)
Received: from [2a02:c0:2:4:6666:17:0:1001] (port=60009 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 1Z7fC3-0000Ea-Ir; Wed, 24 Jun 2015 09:33:59 +0200
Date: Wed, 24 Jun 2015 09:32:56 +0200
From: Tore Anderson <tore@fud.no>
To: Ray Hunter <v6ops@globis.net>
Message-ID: <20150624093256.0075867d@echo.ms.redpill-linpro.com>
In-Reply-To: <5589BC13.6050507@globis.net>
References: <201506211800.t5LI03ux008043@irp-lnx1.cisco.com> <5589BC13.6050507@globis.net>
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/AniHOmZRkI6YBuFN9drXaZfcKSk>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-siit-eam WGLC
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, 24 Jun 2015 07:34:03 -0000

* Ray Hunter <v6ops@globis.net>

> I have read this draft. It is very well written, the intention is
> clear, and I support it.

Hi Ray -- thank you!

> Comment 1
> Sections 3.3.1 and 3.3.2 call for "an IPv4 Prefix identical to that
> of the IPv4 address being translated." and "an IPv6 Prefix identical
> to that of the IPv6 address being translated"
> 
> Surely that should be a "longest-matching-prefix based on CIDR
> [RFC4632]"

> Comment 3
> /  Overlapping EAMs SHOULD be considered an error, and attempts to
>    insert them into the EAMT SHOULD be blocked. The behaviour of an
>    SIIT implementation when overlapping EAMs are present in the EAMT
>    is left undefined./
> 
> I believe that this is an unnecessary restriction for correct 
> specification/operation provided CIDR/longest-matching-prefix is
> specified.

The reasoning behind this restiction was that it would otherwise be
possible to create a situation that does not facilitate bi-directional
communcation. For example:

EAM #1: 192.0.2.1/32,    2001:db8::/32
EAM #2: 198.51.100.1/32, 2001:db8:c000:201::/128

This would cause 192.0.2.1 to be translated to 2001:db8:c000:201::,
which in turn would be translated to 198.51.100.1. That will likely
break whatever use-case was intended. Then again, I suppose it might as
well be allowed. If the operator shoots himself in the foot he can deal
with that himself...so, yeah, we'll lift the restriction and use CIDR.

That said, do you think the draft should discuss what to do when
multiple EAMs contain *identical* IPv4/IPv6 prefix values? For example:

EAM #1: 192.0.2.0/24, 2001:db8:a::/48
EAM #2: 192.0.2.0/24, 2001:db8:b::/48

Or:

EAM #1: 192.0.2.1/32,    2001:db8::/128
EAM #2: 198.51.100.1/32, 2001:db8::/128

Suggested text would of course be very welcome.

> Comment 2
> Operational complexity:
> 
> Suggest Adding at the end of this paragraph
> /Source address selection rules on hosts may not have enough information 
> to be able to select the appropriate source address for outbound 
> sessions in the presence of SIIT./

Good idea, we'll add this. A reference to RFC6724 is probably
appropriate here too.

> Nits
> [...]

Will fix. Thanks again!

Tore