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

<c-sun@bb.softbank.co.jp> Mon, 17 October 2011 12:26 UTC

Return-Path: <c-sun@bb.softbank.co.jp>
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 A170021F8569 for <softwires@ietfa.amsl.com>; Mon, 17 Oct 2011 05:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.995
X-Spam-Level:
X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, 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 wlh-qEXNgth1 for <softwires@ietfa.amsl.com>; Mon, 17 Oct 2011 05:26:40 -0700 (PDT)
Received: from bb.softbank.co.jp (m3.bb.softbank.co.jp [210.146.18.152]) by ietfa.amsl.com (Postfix) with ESMTP id D125921F8558 for <softwires@ietf.org>; Mon, 17 Oct 2011 05:26:31 -0700 (PDT)
Received: from CI-EXHB-02.bb.local (10.241.1.3) by m3.bb.softbank.co.jp (210.146.18.152) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 17 Oct 2011 21:26:29 +0900
Received: from CI-EXMB-09V.bb.local ([fe80::15e:dbec:b8a2:731f]) by CI-EXHB-02.bb.local ([::1]) with mapi; Mon, 17 Oct 2011 21:26:29 +0900
From: c-sun@bb.softbank.co.jp
To: jacni@jacni.com, fibrib@gmail.com
Date: Mon, 17 Oct 2011 21:26:29 +0900
Thread-Topic: [Softwires] 4rd Address Mapping - version-01
Thread-Index: AcyMokRzucxaWx9+SZ+hccb7JN+lpQAJTwDA
Message-ID: <6CADC58598A4D249AD3B5026CE8CC33906D75AC8@CI-EXMB-09V.bb.local>
References: <D8334AA7-5001-4A92-B977-CE32931F4197@laposte.net> <CAAuHL_Cm6WYiM2Cu-fmu=gBLgTYDZ6hr56BfcXMoeS=Af4Q_jw@mail.gmail.com> <CAFUBMqUvrP-s1yrJ0=ToAA_SvRLWQtq7JCTtpASNiS1GAxdSNQ@mail.gmail.com> <4E9B9BC5.2090200@jacni.com> <CAFUBMqUS1cATWr07Os4d6aLUbNaVwuOCcthObOiMPuDv8VfU1g@mail.gmail.com> <4E9BE001.3060202@jacni.com>
In-Reply-To: <4E9BE001.3060202@jacni.com>
Accept-Language: zh-CN, ja-JP
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: zh-CN, ja-JP
Content-Type: multipart/alternative; boundary="_000_6CADC58598A4D249AD3B5026CE8CC33906D75AC8CIEXMB09Vbbloca_"
MIME-Version: 1.0
Cc: 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: Mon, 17 Oct 2011 12:26:40 -0000

Hi,

This is my command in line.


therefore my answer to Q1, is NO, unless we carefully select IPv4 addresses for CEs with giving up to use some of them, which have been so precious.

Q2. then it must fine as long as we map them to different Rule IPv6 Prefix. (?)

    suppose CE1 is the same as (1). for 64.32../16, we use a longer stuff.
    however, there is a CE3:

  Rule IPv6 Prefix B: 20010db8       (2001:db8::/29)
    CE3 IPv4 address:    4020 1876   (64.32.24.118)
            CE3 PSID:             54
        CE3 CE index:         987654
---------------------------------------------------------------
(3)  CE3 IPv6 prefix: 20010db 987654 (2001:db9:8765:4000::/52, woops!)

ambiguity happens. then we may argue: using the ugly Rule_IPv6_Prefix_B is the root of the problem! we have not to use a prefix covered by another.

No, I think the bits of the same position are not additive. So, it should be a delegated prefix of "/53", right?

:P sorry for the typo but i have pointed out in the errata. :P however, even though this is /53, and you will have, in the route table, both
   2001:db9:8765:4000::/52 => route to CE1
   2001:db9:8765:4000::/53 => route to CE3

but for the packet encapsulated with the destination address 2001:db9:8765:4000::200:5efe, you couldn't decide the route should go to CE3 instead of CE1. here the longest-match doesn't work. right?

I guess the second delegated prefix should be 2001:db8:1876:5400::/53

  I guess the second delegated prefix should be 2011:db8:c3b2:a000::/53.
Because the CE3 Rule IPv6 Prefix length is not mulitipe of 4 bits,it need calculate using Binary as follows.

                                 v(/29)
 --elipsis(0x2001 0db)--1000                                            (2011:db8::/29)
 --elipsis(0x4020)------    000 1100 0011 1011 0                 (64.32.24.118)
                                                                   010 1010 0 (PSID 0x54)
--------------------------------------------------------------------------
CE3 IPv6 prefix: 2001:db8:c3b2:a000::/53

If the CE3 IPv4 address is 64.32.48.236, CE3 PSID is 0xa8, calculate as follows,
                                 v(/29)
 --elipsis(0x2001 0db)--1000                                            (2011:db8::/29)
 --elipsis(0x4020)------    001 1000 0111 0110 0                 (64.32.48.236)
                                                                   101 0100 0 (PSID 0xa8)
--------------------------------------------------------------------------
the CE3 IPv6 prefix is 2001:db9:8765:4000::/53

I think this  should be not gonna happen, since the IPv6 address planing must be done natively
considering nothing about the IPv4 address. As exclusiveness, each CE has unique CE IPv6 Prefix.

As described in the example Maoke given, since "Rule IPv6 Prefix B" is contained in the "Rule IPv6 Prefix A",
if the IPv6 addresses under Rule IPv6 Prefix A and the IPv6 address under Rule IPv6 prefix B are assigned independently
and have any consideration each other, same CE IPv6 prefix assigning to different CEs may be happen. I think this MUST be
 avoided when designing the mapping rules or setting the IPv6 assigning way(such as DHCPv6 etc.).

Cheers

Chunfa