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

Jacni Qin <jacni@jacni.com> Mon, 17 October 2011 03:05 UTC

Return-Path: <jacni@jacni.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 5EBC211E8081 for <softwires@ietfa.amsl.com>; Sun, 16 Oct 2011 20:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.883
X-Spam-Level:
X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001]
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 QI++7E4qiwP8 for <softwires@ietfa.amsl.com>; Sun, 16 Oct 2011 20:05:05 -0700 (PDT)
Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 29A2311E8073 for <softwires@ietf.org>; Sun, 16 Oct 2011 20:05:04 -0700 (PDT)
Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 1971F380059 for <softwires@ietf.org>; Sun, 16 Oct 2011 23:05:02 -0400 (EDT)
Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with SMTP id 9DF3C3400D7 for <softwires@ietf.org>; Mon, 17 Oct 2011 11:05:00 +0800 (CST)
Received: from [172.18.50.22] (unknown [221.11.61.30]) by app (Coremail) with SMTP id +AWowJBLKARWm5tOpBcdAA--.30561S2; Mon, 17 Oct 2011 11:04:57 +0800 (CST)
Message-ID: <4E9B9BC5.2090200@jacni.com>
Date: Mon, 17 Oct 2011 11:06:45 +0800
From: Jacni Qin <jacni@jacni.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Maoke <fibrib@gmail.com>
References: <D8334AA7-5001-4A92-B977-CE32931F4197@laposte.net> <CAAuHL_Cm6WYiM2Cu-fmu=gBLgTYDZ6hr56BfcXMoeS=Af4Q_jw@mail.gmail.com> <CAFUBMqUvrP-s1yrJ0=ToAA_SvRLWQtq7JCTtpASNiS1GAxdSNQ@mail.gmail.com>
In-Reply-To: <CAFUBMqUvrP-s1yrJ0=ToAA_SvRLWQtq7JCTtpASNiS1GAxdSNQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------090802030402020105060002"
X-CM-TRANSID: +AWowJBLKARWm5tOpBcdAA--.30561S2
X-Coremail-Antispam: 1UD129KBjvJXoW3GF1UZF4DJw47Zr1fGF1fCrg_yoWxWr1rpr 1fKr13KF1DJry8A397uw1UWrn8AF95J3yUJr15Jry8Ca45AF10yrsYkr4rZayUJrWfJr4Y qr4qkr18Gan8Z3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUcYb7IF0VCYb41lb7IF0VCFI7km07C26c804VAKzcIF0wAYjsxI 4VWkKwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM2kK64x0aVW7Gw IE548m6rI_Jw1UWr17M2kK6IIYrVAqxI0j4VAqrcv_Jw1UGr1DM2vj6xkI62vS6c8GOVWU tr1rJFylYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UM4x0Y48IcV AKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28IcxkI 7VAKI48JMxCIbVAxMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4UvcSsGvfC2Kf nxnUUI43ZEXa7IU0S_MDUUUUU==
X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQAEEko7lOqbKAAAsr
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: Mon, 17 Oct 2011 03:05:06 -0000

hi,

Let me try to answer your questions, please see below,

On 10/15/2011 10:14 AM, Maoke wrote:
> hi Remi and all,
> a discussion on the address mapping in -01.txt, trying to fully 
> understand the design. comments are requested.
> - what if there are two rules?
>   suppose we have 192.32../12 (0xc0200000/12, i think it's not the 
> 0x602 as Leaf previously mentioned, ;-)
>   and we also have 64.32../16 (0x40200000/16). we have a lot of CEs.
> Q1. if we use the two as the Rule_IPv4_Prefix_A and _B, can we map 
> them to a single Rule_IPv6_Prefix?
Yes.

>     Rule IPv6 Prefix: 20010db        (2001:db0::/28)
>     CE1 IPv4 address:     c02 98765         (192.41.135.101)
>             CE1 PSID:              4
>         CE1 CE index:         987654
> ---------------------------------------------------------------
> (1)  CE1 IPv6 prefix: 20010db 987654 (2001:db9:8765:4000::/52)
>     suppose we happen to have another CE somewhere else:
>     Rule IPv6 Prefix: 20010db
>     CE2 IPv4 address:    4020 9876          (64.32.152.118)
>             CE2 PSID:             54
>         CE2 CE index:         987654
> ---------------------------------------------------------------
> (2)  CE2 IPv6 prefix: 20010db 987654 (2001:db9:8765:4000::/52)
> ambiguity happens and packet encapsulated with the same CE IPv6 
> address cannot be routed to the correct CE.
This is not gonna happen, since the IPv6 address planing must be done 
natively considering nothing about the IPv4 in the very beginning. In 
your example, I see you get a 2001:db0::/28 and you want to assign a /52 
to each CE, then ok, there will be 24 bits to distinguish CEs and should 
be assigned continuously without any conflict. The next step is to check 
the available IPv4 spaces we have for the given number of subscribers, 
then based on which to design the rules. You made it in an opposite 
direction.

We break the boundary between the IPv4 address and port, use the bits 
(24 bits in the examples above) together to identify the subscribers. 
The only reason I see to employ multiple IPv4 prefixes is we can't get a 
large enough one. Additionally, in the second example above, you changed 
the sharing ratio to make a "24-bit index", then you should change the 
Rule IPv6 prefix to, for example /27, for the two IPv4 prefixes of "same 
size". On the other hand, according to the consensus (if I get it 
correctly) of the interim meeting, more than one sharing ratios for the 
extended address case is not desirable, that flexibility should be 
offered by stateful approaches.

> 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?

> Q3. what does the exclusiveness of Rule IPv6 Prefix mean?
>     if we have 2001:da0::/28 for the Rule_IPv6_Prefix, everyone will 
> be happy. however, unfortunately, we have only one /28 IPv6 aggregate. 
> then what we have to do is splitting the /28 block into mutually 
> exclusive pieces of small blocks. in the above example, if we have the 
> following rule table:
>     Rule_IPv4_Prefix Rule_IPv6_Prefix
>    -----------------------------------
>     192.32../12      2001:db0::/29
>     64.32../16       2001:db9::/29
>    -----------------------------------
Yes, the exclusiveness. It's similar to what we do to further divide a 
subnet hierarchically. Hierarchies/exclusiveness avoid conflicts but 
lose the efficiency of addressing. BTW, the /29 example is the same as 
what I propose above. :-)

>     then it will work fine within the /28 room in total. for 
> 192.32../12, if the PSID is at least 4bit, then the *shortest* CE IPv6 
> prefix length is 29 + (32 - 12) + 4 = 53 now, rather than 52 in the 
> previous example. if we have only or want to use only at most a /44 
> IPv6 prefix for the residual deployment, for the above 2 IPv4 
> networks, we are not able to safely deploy the CE prefix shorter than 
> /64, no matter how we take the effort!
>     Jacni once mentioned that if we have a /x IPv6 prefix while the 
> "philosophy" of address planning decides to have /y for each 
> CE-delegated network, then we can play the magic with the bits between 
> the /x and the /y. i would like to point out here, because of the 
> exclusiveness requirement, there is a hard limit for the power of the 
> magic. if you have N IPv4 residual addresses, you must at 
> least satisfy the condition:
Please see my comments above.


Cheers,
Jacni

>     (4)     y - x >= log(N)
>     when (4) is not true, cutting the rule into pieces does help 
> almost nothing. i said "almost" because there is really a little we 
> can achieve: there is really some IPv4 address seldom used for any 
> routers, like 192.32.1.0. however, excluding such sort of addresses 
> from the mapping scatters the mapping table into a huge number 
> of /32-Rule_IPv4_Prefix and making the table size even longer than 
> today's IPv4 routing table.
> just my 2 cents. execuse me if the humble calculation has any 
> misunderstanding, and please point out without hesitation.
> best,
> maoke
> > 2011/9/22 Rémi Després <despres.remi@laposte.net 
> <mailto:despres.remi@laposte.net>>:
> >> Alain, all,
> >>
> >> We have just posted a new version of our I-D on the proposed 4rd 
> Address Mapping.
> >> It is available at
> >> www.ietf.org/id/draft-despres-softwire-4rd-addmapping-01.txt 
> <http://www.ietf.org/id/draft-despres-softwire-4rd-addmapping-01.txt>
> >>
> >> Our presentation will be based on THIS version, technically simpler 
> than version -00.
> >> Major differences and their justifications will be briefly explained.
> >>
> >> Regards,
> >> RD
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org <mailto:Softwires@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/softwires
> >>
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org <mailto:Softwires@ietf.org>
> > https://www.ietf.org/mailman/listinfo/softwires
> >
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires