Re: [Softwires] MAP Open issues: Interface-id

Jacni Qin <jacni@jacni.com> Thu, 10 November 2011 07:22 UTC

Return-Path: <jacni@jacni.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 1CB4911E8088 for <softwires@ietfa.amsl.com>; Wed, 9 Nov 2011 23:22:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.04
X-Spam-Level:
X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001]
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 gOaKONrBRQb6 for <softwires@ietfa.amsl.com>; Wed, 9 Nov 2011 23:22:41 -0800 (PST)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4F511E80AB for <softwires@ietf.org>; Wed, 9 Nov 2011 23:22:41 -0800 (PST)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 207853801BE for <softwires@ietf.org>; Thu, 10 Nov 2011 02:22:40 -0500 (EST)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id BFDDC34010B for <softwires@ietf.org>; Thu, 10 Nov 2011 15:22:36 +0800 (CST)
Received: from [172.18.41.14] (unknown [221.11.61.29]) by app (Coremail) with SMTP id +AWowJD7kAK2e7tO5Y0GAA--.10359S2; Thu, 10 Nov 2011 15:22:33 +0800 (CST)
Message-ID: <4EBB7C32.9080504@jacni.com>
Date: Thu, 10 Nov 2011 15:24:34 +0800
From: Jacni Qin <jacni@jacni.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: GangChen <phdgang@gmail.com>
References: <703EB6B3-AB8C-4690-91C6-2666C5779874@cisco.com> <9D6EBB21-38BC-4E6C-99E6-C3448FA2D3C8@laposte.net> <CAM+vMESudUt5PT+qxQED_P2s7DB7T+3D_M4OWQ1yUvNN-xqhzA@mail.gmail.com> <C09B8E42-A13F-4B30-AC88-43F98C709EDD@cisco.com> <CAM+vMERnV962MVte1f784aT_Rmq-GSQ+ZJREv98hY9oQYjOBUA@mail.gmail.com>
In-Reply-To: <CAM+vMERnV962MVte1f784aT_Rmq-GSQ+ZJREv98hY9oQYjOBUA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000801080207020907010704"
X-CM-TRANSID: +AWowJD7kAK2e7tO5Y0GAA--.10359S2
X-Coremail-Antispam: 1UD129KBjvdXoWrKr13ZF4Duw4xZw1fCFWxJFb_yoWkZFb_ur 4vgrykZw18Ar48K3y5tFs8J39xCr4rWF18Ja4kGrW7ur98ArZ8Grn2gryI93yxGrW7tr4D Wrn7Gry5Aa47WjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUj5kYjxAI6xkYrwAYjxAI6xCIbckI1I0E57IF64kEYxAxM7k0a2IF 6F4UM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s1ln4vEF7Iv6F18KV Aqrcv_GVWUtr1rJF1ln4vEIxkG6c02xx0F6c8GOVWUtr18Jw1lnx0Ec2IEnICE548m6r1D JrWUZwAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64 vIr41l7480Y4vEI4kI2Ix0rVAqx4xJMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij 64vIr41l4IxY624lx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrbIYCTnIWIevJa 73UjIFyTuYvjxUs0PSUUUUU
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEHEko7lPO8hgAUst
Cc: Softwires WG <softwires@ietf.org>, Ole Troan <ot@cisco.com>
Subject: Re: [Softwires] MAP Open issues: Interface-id
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: Thu, 10 Nov 2011 07:22:42 -0000

hi,

On 11/8/2011 5:08 PM, GangChen wrote:
> ...
>> the consequence of that is that the destination IPv6 address will change for
>> every flow.
>> the MAP node cannot any longer listen to a single IPv6 address for MAP
>> traffic, but has to intercept packets for a whole prefix.
> Yes. I see there are two choices when MAP nodes process incoming packages
> i) Should we let MAP node interface bind to a single static IPv6 address
Well, by an interface-id for MAP, works.
> ii) Should we let MAP node interface bind to a route to
> IPv4-translatable IPv6 prefix
This is what I ever proposed, a new interpretation of the V/U octet, 
forming a specific route, say /72 pointing to the MAP function.

>
> In translation case, above two cases are possible. That is
> implementation specific. So I suggest to put above design as int-id
> candidate for more inputs from the community
But the variable destination addresses to target MAP function makes the 
above impossible. We can't ignore this issue during the MAP design.


Cheers,
Jacni
>
> BRs
>
> Gang
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>