Re: [v6ops] draft-anderson-v6ops-siit-eam-01
Tore Anderson <tore@fud.no> Mon, 08 December 2014 08:28 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 D44811A701C for <v6ops@ietfa.amsl.com>; Mon, 8 Dec 2014 00:28:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ysn0tOCLt0gE for <v6ops@ietfa.amsl.com>; Mon, 8 Dec 2014 00:28:01 -0800 (PST)
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 B1D071A700D for <v6ops@ietf.org>; Mon, 8 Dec 2014 00:28:01 -0800 (PST)
Received: from [2a02:c0:2:4:6666:17:0:1001] (port=56148 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 1Xxtfi-0007le-Vu; Mon, 08 Dec 2014 09:27:59 +0100
Date: Mon, 08 Dec 2014 09:27:46 +0100
From: Tore Anderson <tore@fud.no>
To: Ca By <cb.list6@gmail.com>
Message-ID: <20141208092746.05889c92@echo.ms.redpill-linpro.com>
In-Reply-To: <CAD6AjGTM=km98Nsb5ab9E8g_qh3wXYAVH4LJ15Fx69exgtaQdw@mail.gmail.com>
References: <CAD6AjGTM=km98Nsb5ab9E8g_qh3wXYAVH4LJ15Fx69exgtaQdw@mail.gmail.com>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.24; 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/9F8MXRGWrT-ilkP7PQXnoG9h9Uk
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-anderson-v6ops-siit-eam-01
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: Mon, 08 Dec 2014 08:28:04 -0000
Hi Cameron, > I have read draft-anderson-v6ops-siit-eam-01 > > I support the working group adopting this document, this is helpful and > meaningful work. > > I have a few comments that are mostly editorial in nature, i believe the > document is technically sound as written today. Thank you! > Purely editorial, i suggest locally adding the definitions > for IPv4-converted IPv6 addresses and IPv4-translatable IPv6 addresses. If > you are taking up space to define them, then go ahead and do the reader the > favor of defining them. > > In section 3.2 there is this sentence: "If a matching > EAM entry is found, the address MUST be translated to IPv6 by > substituting its IPv4 Prefix value for the corresponding IPv6 > Prefix from the EAM entry." > > I don't like the word "substituting" since a reader my believe that one > simply does a substitution of the IPv4 address for the IPv6. It would be > more precises to continuing using the term translate which explicitly > references the packet treatment procedure in SIIT. Perhaps rephrase to > "... MUST be translated to IPv6 in accordance with the EAMT..." This text has undergone a lot of back and forth between myself and another reviewer (Alberto Leiva). The problem he identified with saying something like what you propose, is that it fails to say *exactly* what should happen. Say you have $addr="192.0.2.123", $eam4="192.0.2.0/24", $eam6="2001:db8::/112". Now what? You have those three pieces of information, but nothing saying how those should be combined or manipulated to form a new IPv6 address. You could certainly say that it goes without saying and needs no further explanation, but Alberto thought it was best if it was explicit and as clear as possible. That's why we landed on "substitute", the reasoning is that if you start out with $addr="192.0.2.123", then you first take away the prefix bits found in $eam4, temporarily leaving you with $addr=".123" (i.e., "0x7b"), and then putting in the $eam6 prefix bits instead, leaving you with $addr="2001:db8::7b", and you're done. So what you do, essentially, is to substitute the EAM4 prefix for the EAM6 prefix. (If you're familiar with Perl, the pseudocode would go something like "$addr =~ s/^$eam4/$eam6/".) That said, I'm not terribly happy with the current text either. If you or anyone else have any suggestions on how to make it better and clearer, while still remaining explicit about the procedure/algorithm, that would be much appreciated. Tore
- [v6ops] draft-anderson-v6ops-siit-eam-01 Ca By
- Re: [v6ops] draft-anderson-v6ops-siit-eam-01 Tore Anderson
- Re: [v6ops] draft-anderson-v6ops-siit-eam-01 Fred Baker (fred)
- Re: [v6ops] draft-anderson-v6ops-siit-eam-01 Fred Baker (fred)
- Re: [v6ops] draft-anderson-v6ops-siit-eam-01 Alberto Leiva