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?
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. 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.
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
-----------------------------------
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:
(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]>:
>> 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
>>
>> 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]
>> 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
