Re: [Softwires] 4rd Address Mapping - version-01

Tetsuya Murakami <tetsuya@ipinfusion.com> Wed, 28 September 2011 05:34 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 37A6221F8CCA for <softwires@ietfa.amsl.com>; Tue, 27 Sep 2011 22:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.677
X-Spam-Level:
X-Spam-Status: No, score=0.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067]
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 Stv0OKFZWS1j for <softwires@ietfa.amsl.com>; Tue, 27 Sep 2011 22:34:07 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6EE21F8CC7 for <softwires@ietf.org>; Tue, 27 Sep 2011 22:34:07 -0700 (PDT)
Received: by gyd12 with SMTP id 12so7346160gyd.31 for <softwires@ietf.org>; Tue, 27 Sep 2011 22:36:54 -0700 (PDT)
Received: by 10.68.59.10 with SMTP id v10mr42714128pbq.16.1317188214194; Tue, 27 Sep 2011 22:36:54 -0700 (PDT)
Received: from 3.87.202.1.static.bjtelecom.net ([1.202.87.3]) by mx.google.com with ESMTPS id u1sm4102466pbr.9.2011.09.27.22.36.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 22:36:52 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FDF7FEBC-46B5-4C7B-A42B-6D5C28391D70"
From: Tetsuya Murakami <tetsuya@ipinfusion.com>
In-Reply-To: <CAM+vMERSbGuraAC9snvGUgPBOY40m5p0SX46qfVqJaB6bHmvCw@mail.gmail.com>
Date: Tue, 27 Sep 2011 22:36:11 -0700
Message-Id: <D8B8F1D1-1FE7-44E1-A6C6-E1480BD91C0A@ipinfusion.com>
References: <D8334AA7-5001-4A92-B977-CE32931F4197@laposte.net> <CAAuHL_Cm6WYiM2Cu-fmu=gBLgTYDZ6hr56BfcXMoeS=Af4Q_jw@mail.gmail.com> <B3D5FABA-72BA-4C35-A068-D823CC0A4682@laposte.net> <CAM+vMERSbGuraAC9snvGUgPBOY40m5p0SX46qfVqJaB6bHmvCw@mail.gmail.com>
To: Rémi Després <despres.remi@laposte.net>
X-Mailer: Apple Mail (2.1244.3)
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] 4rd Address Mapping - version-01
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: Wed, 28 Sep 2011 05:34:08 -0000

Hi Remi,

I have one question about your new address mapping draft.

In the draft, you mentioned the special IID can be used for distinguishing 4rd packets from other IPv6 packet whose destination start with CE IPv6 prefixes.

But I think it is difficult to distribute the IPv6 prefix matching to the assigned Domain IPv6 prefix. Here is one example.

CE IPv6 Prefix:
+----------------------------+------------------+
| Domain IPv6 Prefix (36bit) | CE index (20bit) |
+----------------------------+------------------+

Domain IPv4 Prefix:
+--------------+
|   16 bits    |
+--------------+

In this case, the first 16bits of CE index can be embedded in the last 16bits of IPv4 address followed by Domain IPv4 prefix. And then the remaining 4bits of CE index can be embedded as PSID followed by 4bit port head.

At the BR, BR can generate the destination IPv6 address from the IPv4 destination and the destination port number as shown below.

<---------------------------------- 64bit --------------------------------------->
+----------------------------+--------------------------------+------------------+
| Domain IPv6 Prefix (36bit) | suffix of IPv4 address (16bit) | MAX PSID (12bit) |
+----------------------------+--------------------------------+------------------+
<---------------- CE IPv6 Prefix (56bit)--------------------------->

PSID can be derived from the port number after removing the first 4bit even though the length of the actual PSID is only 4bit. In this case, CPE should terminate the packet whose IPv6 destination is matched to CE IPv6 Prefix and then process the decapsulation for 4rd. So, I think this means that any IPv6 prefix matching to CE IPv6 Prefix can be terminated at 4rd functionality in CE. For this, even though CE IPv6 Prefix can be delegated to the CE, CE can not delegate any IPv6 prefixes matching to CE IPv6 Prefix to any hosts connected on the LAN side of the CE. Usually, if the CE can get an IPv6 prefix whose length is 56bit, CE can delegate an IPv6 prefix having the different prefix length (i.e. 64bit) to the hosts locating on the LAN side of the CE. But I don't think it can be working because the IPv6 destination matching to CE IPv6 prefix (delegated prefix) should be terminated at CPE for 4rd processing. So, in order to provide Dual-stack for the hosts locating on the LAN side of the CE, an additional IPv6 prefix different from CE IPv6 Prefix needs to be delegated.

Is my understand correct?

Thanks,
Tetsuya Murakami