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

[Maoke <[e-mail]>]

hi Remi,

2011/10/21 Rémi Després <[e-mail]>

> 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 <[e-mail]>
>
>> 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)
>>
>>
>
 is this another bug? i think:

|<------------        x       ---------------->|
|            |<---------   n   ----------->|<k>|
+------------+---------+-------------+-----+---+
|Common Pref.|Rule idx | IPv4 suffix |PSID |   |
+------------+---------+-------------+-----+---+
|            |<---------   m  ------>|
|<--- c ---->|<-- ri ->|<--- hi ---->|

and thus c = x - (n + k), right? ;-)

cheers,
maoke

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