hi,
On 10/17/2011 11:59 AM, Maoke wrote:
hi Jacni,
thanks a lot for the reply. please see inline.
2011/10/17 Jacni Qin <[email protected] <mailto:[email protected]>>
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.
i understand what you mean is the following steps of rule_IPv6_prefix
decision:
1. list all the IPv4 addresses we have for the given number of
subscribers;
2. aggregate these IPv4 addresses into contiguous blocks, suppose that
you start from the point of minimum waste (no unused IPv4 addresses
are involved in the rules);
3. define the share-ratio and calculate the rule_IPv6_prefix for each
rule_IPv4_prefix defined in the step 2;
4. if your IPv6 space is far bigger to accommodate all the
rule_IPv6_prefixes, then go back to step 2 and try to make some relax
(trade-off), allowing unused IPv4 addresses involved in the rule to
some extent but gaining fewer rules.
my example was, from beginning, making a fixed rule_IPv6_prefix and
two large IPv4 prefixes, where it is possible that a lot of actually
unused IPv4 addresses contained. does the "opposite direction" in you
context mean 1) i put CE index behind a predefined rule_IPv6_prefix,
or 2) i made large IPv4 prefixes as the start point?
I meant the latter one (not 100% ;-)). You can aggregate these IPv4
prefixes into contiguous blocks, by for instance as you proposed,
changing the sharing ratio of the second example (64.32../16), 4-bit
PSID to 8-bit PSID to make a 24-bit CE index as the first example
(192.32../12). The aggregation should be done through the design of Rule
IPv6 prefixes. Pick a /27 which contains two /28, use the first /28 as
the Rule IPv6 Prefix for 192.32../12, then the second /28 contains two
/29, preserve the first /29, then the second /29 contains two /30 ...,
finally pick a /32 as the Rule IPv6 Prefix for 64.32../16. Then the two
rules share the same /27 and can be aggregated.
for the point 2), i may assume that all the addresses inside these two
blocks are potentially used for our IPv4 subscribers and therefore
there is not waste, and i actually meant the same as you did. ;-)
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.
sorry, a little confused. do you mean that, if we have 192.32../12 and
64.32../16 for the rule_IPv4_prefixes and we have the 4-bit PSID (me
too, don't desire to have more than one sharing ratios), then and we
need each CE IPv6 prefix as /52, then the rule_IPv6_prefixes for the
two rules should be /28 and /32, respectively, right?
Yes, and please see my comments above.
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?
:P sorry for the typo but i have pointed out in the errata. :P
however, even though this is /53, and you will have, in the route
table, both
2001:db9:8765:4000::/52 => route to CE1
2001:db9:8765:4000::/53 => route to CE3
but for the packet encapsulated with the destination address
2001:db9:8765:4000::200:5efe, you couldn't decide the route should go
to CE3 instead of CE1. here the longest-match doesn't work. right?
I guess the second delegated prefix should be 2001:db8:1876:5400::/53
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. :-)
ok. the exclusiveness is cleared. thanks a lot for the help! then
please focus on the upper part further.
Great, we're on the same page.
Cheers,
Jacni
thanks again and regards,
maoke
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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
