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 <[email protected]
<mailto:[email protected]>>:
>> 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
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/softwires
>>
> _______________________________________________
> Softwires mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/softwires
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
