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

[Maoke <[e-mail]>]

hi Remi,

thanks for the further explanation.

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

>
> Le 21 oct. 2011 à 13:34, Maoke a écrit :
> ...
>
> 2011/10/21 Rémi Després <[e-mail]>
>
> ...
>
> The PSID is WITHIN the /60 (at its end).
>>
>
> to clarify: WITHIN the /60 means within the address block of the /60, not
> *within the first 60 bits*, (then at its end = starts from 61st bit), right?
>
>
> It looks like we have a misunderstanding here, the origin of which I
> couldn't find, but which I am sure we can resolve.
>
> In the 4rd-addmapping draft:
> - The PSID is at the end of the CE Generalized IPv4 prefix (Fig 3)
> - The CE index is at the end of the CE Generalized IPv4 prefix (Fig 2)
> - The CE index is at the end of the CE IPv6 prefix (within it)
>
> Consequently, if CE IPv6 prefixes are /60s, PSIDs are in my understanding
> "within the first 6O bits".
>
> Extracts from the 4rd-addmapping draft:
> - In Figure 2:
> <----------------- at most 64 bits ------------------>
> +-----------------------------------------------------+
> |                   CE IPv6 prefix                    |
> +-----------------------------------------------------+
> :                                                     :
> +--------------------------------+--------------------+
> |        Rule IPv6 prefix        |     CE index       |
> +--------------------------------+--------------------+
>                                  :                    :
>               +------------------+--------------------+
>               | Rule IPv4 prefix |     CE index       |
>               +------------------+--------------------+
>               :                                       :
>               +---------------------------------------+
>               |       CE Generalized IPv4 prefix      |
>               +---------------------------------------+
>               <----------- at most 44 bits ---------->
> - In Figure 3:
>                (C) CE Generalized IPv4 prefix having 33 to 44 bits
> +--------------------------------------------------+
> |       CE Generalized IPv4 prefix                 |
> +--------------------------------------------------+
> :                                                  :
> +-------------------------------------------+------+
> |              CE IPv4 address              | PSID |
> +-------------------------------------------+------+
> <----------------- 32 bits -----------------><--.-->
>                                                 |
>                                           max 12 bits
>
>
>
>
> 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)
>>
>
> the CE IPv6 prefix = 1) + 2), right?
>
>
>> 3) The PSID (whose length is known iff the matching rule specifies a CE
>> IPv6-prefix length)
>>
>
> the EA bits = 2) + 3), right?
>
>
> Depending on what you call EA bits, it can be 2+3  or 2+3+4 in case of
> unknown CE-prefix length by sources
>
>
after check with some examples i can cautiously say i accept your point, :)
(i was concerning if you wasted some port-set of some IPv4 addresses if the
PSID are in different length but it seems the rough check illustrate no such
a possibility).

may i understand it as: although variant PSID attached *after* instead of
being inside in the prefixes having a common length is also deployable, but
it is not what the residual deployment means. the purpose is: when deploying
IPv6 network, we try to assign the (not-yet-used) IPv4 addresses and sharing
them, if they are not many enough to support 1:1, for those CEs whose
delegated network may still need IPv4 communications.
therefore, the address planning is always deployable in the sense of IPv6
but if we can provide good IPv4 communicability for these IPv6 CE-delegated
networks depends on how many IPv4 address we have and how small port-set we
can suffer.
is this of my understanding right now?


>
>
>
>> 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.
>>
>
> it seems to me that the draft-murakami-softwire-4rd-01 hasn't explain how
> do we use the "Domain IPv6 suffix", :(
>
>
> Indeed.
> That's why I wrote something about it in sec 5.5 of the 4rd-addmapping
> draft version -00 (where it is called the "CPE-cascade" option).
> That was based on explanations received privately from Tetsuya Murakami.
> However, having received neither approval nor criticism from him, or from
> anyone, I can't be sure it was accurate.
>
> In version -01, we decided to consider the subject out of scope, to be
> documented separately.
>
>
>
> 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.
>>
>
> sure. in this case we can help nothing.
>
>
>> If the above is still unclear (or bugged!), thanks for letting me know.
>>
>>
> Regards,
>> RD
>>
>
>
>