Re: [Softwires] 4rd-addmapping - Possible independence of the IPv6 addressing plan from IPv4 prefixes

Rémi Després <despres.remi@laposte.net> Fri, 21 October 2011 10:14 UTC

Return-Path: <despres.remi@laposte.net>
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 5C0DB21F8C0B for <softwires@ietfa.amsl.com>; Fri, 21 Oct 2011 03:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.764
X-Spam-Level:
X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
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 g89oVEKFMrhS for <softwires@ietfa.amsl.com>; Fri, 21 Oct 2011 03:14:42 -0700 (PDT)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 62E0921F8BB1 for <softwires@ietf.org>; Fri, 21 Oct 2011 03:14:41 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id D031170001CF; Fri, 21 Oct 2011 12:14:40 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 5F60570001B2; Fri, 21 Oct 2011 12:14:40 +0200 (CEST)
X-SFR-UUID: 20111021101440390.5F60570001B2@msfrf2109.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-4--565019882"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <CAFUBMqX9rrmTpksw7R4_59=rN0qDVkA_6y5B5cBP_7zgaRt=rQ@mail.gmail.com>
Date: Fri, 21 Oct 2011 12:14:39 +0200
Message-Id: <91111240-FEA5-49F4-B877-197FFA46AE1B@laposte.net>
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> <6CADC58598A4D249AD3B5026CE8CC33906D75AC8@CI-EXMB-09V.bb.local> <CAFUBMqW7xqxwzToxn1=0y4q48Dr5U8rx3pDoavcWGhPyO-OLpw@mail.gmail.com> <927947AB-FD61-4CCA-8E42-2DEC1854F2EA@free.fr> <CAFUBMqX9rrmTpksw7R4_59=rN0qDVkA_6y5B5cBP_7zgaRt=rQ@mail.gmail.com>
To: Maoke <fibrib@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] 4rd-addmapping - Possible independence of the IPv6 addressing plan from IPv4 prefixes
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: Fri, 21 Oct 2011 10:14:43 -0000

Maoke,
Please see below.

Le 20 oct. 2011 à 16:48, Maoke a écrit :

> hi Remi,
>  
> thanks a lot for the reply! it is very helpful and my latest understanding almost approach it. but still some minor clarifications.
> 2011/10/20 Rémi Després <remi.despres@free.fr>
> Hi Maoke,
> 
> Thank you for your questions concerning relationships between IPv6 and IPv4 addressing plans.
> 
> Here are address-planning steps that illustrate how an IPv6 addressing plan can be kept independent from IPv4 prefixes used for IPv4 residual deployment, even if CEs must be able to have different sharing ratios.
>  
>   (A) IPv6 considerations
> (A1) Determine the maximum number N of CEs you want to support, a power of 2 (N = 2 ^ n).
> (A2) Choose the length x of IPv6 prefixes you want to assign to ordinary customers (e.g. x = 60)
> (A2) Multiply M by a margin coefficient K, a power of two (K = 2 ^ k), to take into account that:
>  
>  
> here the M should be a typo of "N", right? ;-) 

Yes, thanks.

>  
>  
>  - Some privileged customers may be assigned IPv6 prefixes of length x', shorter than x, to have larger addressing spaces than ordinary customers, both in IPv6 and IPv4.  
>  - Due to the hierarchy of routable prefixes, many theoretically delegatable prefixes may not be actually delegatable (ref: host density ratio of RFC 3194).
> 
>   (B) IPv4 considerations
> (B1) List all (non overlapping) IPv4 prefixes Hi that are available for IPv4 residual deployment.
> (B2) Take enough of them, among the shortest ones, to get a total space whose size M is a power of two (M = 2 ^ m), and includes a good proportion of the available IPv4 space (ref www.ietf.org/mail-archive/web/softwires/current/msg02261.html).
> (B3) For each IPv4 prefix Hi of length hi, choose a "Rule index" Ri of length ri = m - hi. All these indexes must be non overlapping prefixes (e.g. 0, 10, 110, 111 for one /10, one /11, and two /12).

Oops, another bug :-(.
The right formula for ri is:  ri = m - (32 - hi) 

> 
>   (C) After (A) and (B)
> (C1) Derive the length c of the "Common prefix" C that will appear at the beginning of all delegatable prefixes (c = n + k - m)
> (C2) Take for C any prefix of length c that starts with a RIR-allocated IPv6 prefix
> (C3) For each IPv4 prefix Hi, make a rule in which it is the IPv4 prefix, and in which the IPv6 prefix is the Common prefix C followed by the Rule index Ri.
> 
> I hope this can work on your favorite example(s).
> If not, please let me know.
>  
> it seems you didn't mention the PSID part. my understanding is, after the above, when we have the, e.g., /60, the PSID is attached after the /60. then the CE delegated prefix (including IPv4 address suffix and PSID) may have different lengths if the sharing ratio is variant for different shared IPv4 addresses. but the c + m (or n + k, or x (right?)) , including the common prefix and the ipv4-address-related bits, is a constant for every CE-delegated network in the domain, right?

The PSID is WITHIN the /60 (at its end).

The IPv6 /64 prefix to be used to reach a CE contains:
1) The Rule IPv6 prefix (that of the rule whose IPv4 prefix matches the IPv4 destination)
2) The IPv4 suffix (that part of the IPv4 destination that follows the IPv4 prefix of the matching rule) 
3) The PSID (whose length is known iff the matching rule specifies a CE IPv6-prefix length) 
4) If the PSID length is unknown, the "PSID complement" that completes the Max PSID.   
5) A 0 padding if fields 1 to 4 don't reach 64 bits

Note 1: If a Domain-IPv6-suffix option is used, the PSID length is necessarily known, and the PSID complement is then replaced by the Domain IPv6 suffix found in the matching rule. (ref draft-murakami-softwire-4rd-01.

Note 2: If ordinary CE IPv6 prefixes are /60s, the PSID complement has typically 4 bits (to fit in the /64).
The only exception is if the sharing ratio needs to exceed 256, so that the PSID length exceeds 8. Then, the PSID complement of less than 4 bits.   

> on the other hand, there is a limitation. if c + m > 64, the above address planning is not deployable, but with our effort of maximum compression,

> we believe the undeployable case rarely happens for normal providers, right?

Yes.

The only impossibility is if the available IPv4 space is so small that no sharing ratio can be sufficient for the number of IPv4 shared addresses to equal the number of ordinary CE IPv6 prefixes.



If the above is still unclear (or bugged!), thanks for letting me know.

Regards,
RD

 


>  
> Note that this is by no means to say that all ISPs should plan addresses this way (i.e. with a relationship between lengths of CE IPv6 prefixes and sharing ratios). It is just to show that this  is workable.
>  
>  
> sure. but i believe this will helps operators very much, considering up to now no operators have experienced that.
>  
> thanks,
> maoke
>  
>  
> Regards,
> RD 
>