hi Remi, 2011/10/21 Rémi Després <[email protected]>
> 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 <[email protected]> > >> 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 > > > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
