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

GangChen <phdgang@gmail.com> Tue, 08 November 2011 09:08 UTC

Return-Path: <phdgang@gmail.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 A61CD21F8B7B for <softwires@ietfa.amsl.com>; Tue, 8 Nov 2011 01:08:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.305
X-Spam-Level:
X-Spam-Status: No, score=-3.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 KMjtP89WbyMc for <softwires@ietfa.amsl.com>; Tue, 8 Nov 2011 01:08:52 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C72F821F8B7A for <softwires@ietf.org>; Tue, 8 Nov 2011 01:08:51 -0800 (PST)
Received: by wwi36 with SMTP id 36so257880wwi.13 for <softwires@ietf.org>; Tue, 08 Nov 2011 01:08:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=twhCDQq9ZU0AEm7uM52/Nx5ioml7GRDliV6hsbsgFkE=; b=vQa6xbhbIj4LmEz0rymmcZtFXY8Pzl7GPNOaAdagAnkue0AJBbg8pn5rYcdSBC9TYg xa1zf/X5XMbxozoyW73DgQA1fH+XlYrmoTcJ5YCQkBd3Cw3MGW9B+PbJBDvDdnGjgHgq pP1ubFxSsO2hE2UE/d7ml1RNOYMpmzAgedFIQ=
MIME-Version: 1.0
Received: by 10.181.13.165 with SMTP id ez5mr11961803wid.51.1320743330929; Tue, 08 Nov 2011 01:08:50 -0800 (PST)
Received: by 10.180.102.8 with HTTP; Tue, 8 Nov 2011 01:08:50 -0800 (PST)
In-Reply-To: <C09B8E42-A13F-4B30-AC88-43F98C709EDD@cisco.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>
Date: Tue, 08 Nov 2011 17:08:50 +0800
Message-ID: <CAM+vMERnV962MVte1f784aT_Rmq-GSQ+ZJREv98hY9oQYjOBUA@mail.gmail.com>
From: GangChen <phdgang@gmail.com>
To: Ole Troan <ot@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Softwires WG <softwires@ietf.org>
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: Tue, 08 Nov 2011 09:08:52 -0000

2011/11/8, Ole Troan <ot@cisco.com>:
>>> 1. Checksum neutrality being an open question, it is relevant here.
>>> 2. It is useful AFAIK to distinguish CE addresses from BR addresses.
>>>
>>> The best proposal I know so far is as follows (with CNP = Checksum
>>> neutrality preserver)
>>>
>>> CE ADDRESS
>>>
>>> <- - - - - - IPv6 Unformatted  address (104 bits) - - - ->
>>> +-------------------+----------+----------+---------------+
>>> | Rule IPv6 prefix  |IPv4 suff.| Max PSID |  Padding = 0  |
>>> +-------------------+----------+----------+---------------+
>>> :
>>> :<- - - - - - - - - 64  - - - - - >:<- - - - 40 - - - - ->:
>>> :                                  :\                      \
>>> :                                  <8>                      :<- 16 ->
>>> :                                  : :                      :        :
>>> +----------------------------------'-'----------------------+--------+
>>> | IPv6 unformatted address (part 1)|V|                      |   CNP  |
>>>
>>> +----------------------------------+-+----------------------+--------+
>>> <- - - - - - - - - - -  IPv6 address (108 bits)  - - - - - - - - - - >
>>>
>>>
>>>
>>> BR ADDRESS
>>>
>>> +------------------------------------+-+-----------------+-+-------+
>>> |              BR IPv6 prefix        |V|   IPv4 address  |0|  CNP  |
>>> +------------------------------------+-+-----------------+-+-------+
>>> < - - - - - - - - - 64  - - - - - - ><8><- - -  32 - - -><8><  16  >
>>>
>>
>> +1
>> The checksum neutrality is desirable for translation case.
>> I suggest to take above format into consideration
>
> 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
ii) Should we let MAP node interface bind to a route to
IPv4-translatable IPv6 prefix

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

BRs

Gang