Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

Tetsuya Murakami <tetsuya@ipinfusion.com> Tue, 11 October 2011 23:35 UTC

Return-Path: <tetsuya@ipinfusion.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B63021F8B5C for <softwires@ietfa.amsl.com>; Tue, 11 Oct 2011 16:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLU0Urza9nDu for <softwires@ietfa.amsl.com>; Tue, 11 Oct 2011 16:35:10 -0700 (PDT)
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id CEC8A21F8B64 for <softwires@ietf.org>; Tue, 11 Oct 2011 16:35:10 -0700 (PDT)
Received: by pzk37 with SMTP id 37so263449pzk.9 for <softwires@ietf.org>; Tue, 11 Oct 2011 16:35:10 -0700 (PDT)
Received: by 10.68.19.225 with SMTP id i1mr49571376pbe.63.1318376110449; Tue, 11 Oct 2011 16:35:10 -0700 (PDT)
Received: from [10.70.2.159] ([12.248.239.142]) by mx.google.com with ESMTPS id o6sm954094pbb.1.2011.10.11.16.35.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 16:35:05 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="us-ascii"
From: Tetsuya Murakami <tetsuya@ipinfusion.com>
In-Reply-To: <B8DEB256-0585-4279-BC8F-96064B4FF606@employees.org>
Date: Tue, 11 Oct 2011 16:35:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C1E96B3-47C4-45A7-9064-03E70612F5AD@ipinfusion.com>
References: <F259BF79-B3C9-4434-AAC4-9F84B8D9A0FA@laposte.net> <CAH3bfACp_xvzotgrAhBrYhZ9ki47kbBVb-vmSsRtOOoyXxRSrA@mail.gmail.com> <10DF6CE6-394E-4FC9-BB80-9F24D4D2634B@laposte.net> <4E9065BD.3050001@jacni.com> <2904870A-866E-4093-8754-3D75510B82AA@laposte.net> <4E92A32C.30306@jacni.com> <B8DEB256-0585-4279-BC8F-96064B4FF606@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.1244.3)
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Oct 2011 23:35:11 -0000

On 2011/10/10, at 1:58, Ole Troan wrote:

>>> The 4rd function examines ALL packets that reach the CE.
>>> It processes all those that have V in their destination addresses, and only those.
>>> 
>> This is a big change to the current forwarding behavior of CPE devices, doable, but quite different from, for example, some encapsulation/decapsulation implementations.
> 
> +1.
> doable in theory, but I share your concerns.

+1.

From a developer point of view, I think there is a big impact on the current forwarding behavior on every major operating systems. In fact, I have never seen a similar implementation of any encapsulation/decapsulation so far.

Normally, the decapsulation could be done for the packet having the tunnel end-point address as the destination or having the specific IPv6 prefix as the destination. There is a big impact on the current implementation to look into a specific value in the last 64bit of IPv6 destination address. From the developer point of view, I would like to utilize the existing implementation as much as possible.

Thanks,
Tetsuya Murakami