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
- [Softwires] MAP Open issues: Interface-id Ole Troan
- Re: [Softwires] MAP Open issues: Interface-id jouni korhonen
- Re: [Softwires] MAP Open issues: Interface-id Ole Troan
- Re: [Softwires] MAP Open issues: Interface-id Rémi Després
- Re: [Softwires] MAP Open issues: Interface-id GangChen
- Re: [Softwires] MAP Open issues: Interface-id Ole Troan
- Re: [Softwires] MAP Open issues: Interface-id GangChen
- Re: [Softwires] MAP Open issues: Interface-id Rémi Després
- Re: [Softwires] MAP Open issues: Interface-id Ole Troan
- Re: [Softwires] MAP Open issues: Interface-id jouni korhonen
- Re: [Softwires] MAP Open issues: Interface-id Rémi Després
- Re: [Softwires] MAP Open issues: Interface-id Mark Townsley
- Re: [Softwires] MAP Open issues: Interface-id Rémi Després
- Re: [Softwires] MAP Open issues: Interface-id Jacni Qin
- Re: [Softwires] MAP Open issues: Interface-id Jacni Qin