Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
GangChen <phdgang@gmail.com> Tue, 04 October 2011 17:06 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 A2FE321F8AED for <softwires@ietfa.amsl.com>; Tue, 4 Oct 2011 10:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.424
X-Spam-Level:
X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 DI89cFWTo-5s for <softwires@ietfa.amsl.com>; Tue, 4 Oct 2011 10:06:58 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAADC21F8ADC for <softwires@ietf.org>; Tue, 4 Oct 2011 10:06:57 -0700 (PDT)
Received: by wyh21 with SMTP id 21so895920wyh.31 for <softwires@ietf.org>; Tue, 04 Oct 2011 10:10:02 -0700 (PDT)
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:content-transfer-encoding; bh=In/hrtv8zSYKO7zkavsBQ21xypZ6bw/4Wz198i6tG4o=; b=HaFbXXE7b5OhZiZY+X6mCAhVwN3zUtmxWFjergagJdjjXVynWOqo8MpZy1T2zWka+d 7txPvXW1T2rALI4JSH59J0sgaJ2veaG5NNf71/5rbQzJNyBpd/ZShFQalqVeOT0ueiqA J+D8zUCL9ybYhJEUAG99NTMSnj05xoIa1eKOE=
MIME-Version: 1.0
Received: by 10.227.7.159 with SMTP id d31mr1849483wbd.18.1317748202672; Tue, 04 Oct 2011 10:10:02 -0700 (PDT)
Received: by 10.180.84.161 with HTTP; Tue, 4 Oct 2011 10:10:02 -0700 (PDT)
In-Reply-To: <F259BF79-B3C9-4434-AAC4-9F84B8D9A0FA@laposte.net>
References: <F259BF79-B3C9-4434-AAC4-9F84B8D9A0FA@laposte.net>
Date: Wed, 05 Oct 2011 01:10:02 +0800
Message-ID: <CAM+vMER2CBTpYOhcu63th7AJejCJ4sv0_GqeiZmwHVHEEeW1WA@mail.gmail.com>
From: GangChen <phdgang@gmail.com>
To: Rémi Després <despres.remi@laposte.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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, 04 Oct 2011 17:06:58 -0000
Hello Remi, I'm trying to put some comments for such unified address mapping. Regarding the deterministic benefit for double translation, I guess we only could use V bits to achieve. There are no necessary to put IPv4 and Port-set ID information in last 64 bits. If I understand correctly, the encoded IPv4 and Port-set ID could help to derive a shared/dedicated IPv4 address or IPv4 subnet from the IPv6 prefix. It may help encapsulation in same cases(e.g. IPv4 based traffic classification,IPv4 ACL, etc). However, the translation case is more preferable doing pure IPv6 based control for the sake of simpler operation reasons (e.g. IPv6 ACL). It's desirable identifying a customer depending on first 64 bits. Many thanks Gang 2011/10/4, Rémi Després <despres.remi@laposte.net>: > Hi all, > > 1. > Here is a unified Address Mapping, for both encapsulation and > double-translation approaches, that is PROPOSED for IPv4 residual deployment > across IPv6-only routing domains. > > It results from an informal meeting among participants having different > preferences between double-translation and encapsulation solutions (Xing Li, > Congxiao Bao, Wojciech Dec, myself, at the end of the Beijing meeting). > > The idea is to have a common format that is good for both types of > solutions. > In particular: > - It enriches Double translation by introducing a deterministic way to > distinguish a translated IPv4 packet from a native IPv6 packet. > - It enriches Encapsulation by expressing, in clear format within an IPv6 > address, an IPv4 address, an IPv4 prefix, or an IPv4 address + port-set ID. > > > 2. > (a) > The IPv6 Source address of an IPv4 packet from a CE is: > > a1- If the CE has an exclusive or shared IPv4 address: > > <--------- 64 ------------><8 ><------ L >= 32 -------><48-L><8 > > +-------------+--------+---+---+----------------+------+-----+---+ > | IPv6 prefix |CE index| 0 | V | IPv4 address | PSID | 0 | L | > +-------------+--------+---+---+----------------+------+-----+---+ > > a2- If the CE has an IPv4 prefix: > > <--------- 64 ------------><8 ><-- L < 32 --><--- 48-L -----><8 > > +-------------+--------+---+---+-------------+---------------+---+ > | IPv6 prefix |CE index| 0 | V | IPv4 prefix | 0 | L | > +-------------+--------+---+---+-------------+---------------+---+ > > (b) > V is the mark that characterizes IPv6 packets that are in reality IPv4 > packets. > Its value differs from any permitted value of this octet in IPv6 IIDs (ref > RFC 4291). > > It is understood that, if double Translation coexists with single > translation, concerned ISPs may notify their CEs to use the U octet of RFC > 6052 instead of V. > > An unambiguous mark is fortunately possible because currently permitted IIDs > have in their first octet either bit6 = 0 (the "u" bit"), or bit6 = 1 and > bit7= 0 (the "g" bit). > With V having "u" = 1 (signifying Universal scope) AND "g" = 1, distinction > is therefore deterministic. > > The proposed V is = 00000011. > (With other values of this octet, other IID formats can be defined in case > some would be useful in the future.) > > Note that, if and when a consensus is reached in Softwire, an extension of > RFC 4291 will have to be submitted to 6MAN. > > (c) > A Destination address from a CE to the outside IPv4 Internet is: > <--------- 64 ------------>< 8 ><---- 32 ----><--- 16 ----><8 > > +--------------------------+----+---------------+------------+---+ > | BR subnet prefix | V | IPv4 address | 0 |32 | > +--------------------------+----+---------------+------------+---+ > > Note that if double-translation CEs are notified to use U instead of V, the > last octet becomes 0 per RFC 6052. > > > 3. > All comments are most welcome. > > Kind regards to all, > RD > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >
- [Softwires] Proposed Unified Address Mapping for … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Congxiao Bao
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Congxiao Bao
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Congxiao Bao
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … xiaohong deng
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Zhen Cao
- Re: [Softwires] Proposed Unified Address Mapping … Zhen Cao
- Re: [Softwires] Proposed Unified Address Mapping … GangChen
- Re: [Softwires] Proposed Unified Address Mapping … liu dapeng
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Leaf yeh
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … Satoru Matsushima
- Re: [Softwires] Proposed Unified Address Mapping … Satoru Matsushima
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Satoru Matsushima
- Re: [Softwires] Proposed Unified Address Mapping … Leaf yeh
- Re: [Softwires] Proposed Unified Address Mapping … Satoru Matsushima
- Re: [Softwires] Proposed Unified Address Mapping … Satoru Matsushima
- Re: [Softwires] Proposed Unified Address Mapping … Tetsuya Murakami
- Re: [Softwires] Proposed Unified Address Mapping … Jacni Qin
- Re: [Softwires] Proposed Unified Address Mapping … Tetsuya Murakami
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Leaf yeh
- Re: [Softwires] Internal routing based on the V o… Rémi Després
- Re: [Softwires] Internal routing based on the V o… Ole Troan
- Re: [Softwires] Proposed Unified Address Mapping … Qiong
- Re: [Softwires] Proposed Unified Address Mapping … Leaf yeh
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després
- Re: [Softwires] Proposed Unified Address Mapping … Maoke
- Re: [Softwires] Proposed Unified Address Mapping … Rémi Després