Subject: Re: [Softwires] 4rd Address Mapping - version-01

From: Qiong <[email-masked]>
Date: Sun, 2 Oct 2011 08:58:52 +0800

Hi Ole and Remi,

> This is my answer to your first (double) question.
> > If it is not enough, as suggested below, please explain what you don't
> understand.
>
> I specifically do not want a solution that changes forwarding behaviour for
> _all_ IPv6 packets.
> e.g. looking at 24 bits in the middle of an IPv6 address is such a change.
>
> I don't understand what requirements you are basing this 'solution' on.
> if the 4rd / dIVI CE takes (a well known or provisioned) /64 prefix out of
> the delegated prefix. then why do you need any of that?
>

Qiong : I agree that routing lookup for a provisioned /64 prefix would be
better that extracting certain bits for each IPv6 address in CE. This would
bring less change to existing routing model.

Best wishes

Qiong

_______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 3 Oct 2011 09:30:56 +0800

Hi Congxiao,
Thanks for your comment.
Please sea inline.

Le 2 oct. 2011 à 08:58, Qiong a écrit :

> > If it is not enough, as suggested below, please explain what you don't understand.
> 
> I specifically do not want a solution that changes forwarding behaviour for _all_ IPv6 packets.

Having a recognizable field in the IID doesn't imply any change of forwarding behavior (still done on up to /64s).
 
> if the 4rd / dIVI CE takes (a well known or provisioned) /64 prefix out of the delegated prefix. then why do you need any of that?
>  
> Qiong : I agree that routing lookup for a provisioned /64 prefix would be better that extracting certain bits for each IPv6 address in CE. This would bring less change to existing routing model.

Having a recognizable field in the IID doesn't change the possibility to lookup for a provisioned /64 prefix.
It only opens the ADDITIONAL possibility to recognize IPv4 addresses without knowledge of any IPv6 prefix.
This is useful in particular in use cases where:
- some ALGs are enforced by devices that can't do prefix matching
- the same IPv6 prefixes are used for real IPv6 addresses and embedded IPv4 addresses.
MORE GENERAL (open to more use cases without excluding any).

Hope it clarifies,

Regards,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 03 Oct 2011 09:46:00 +0200

On 02/10/2011 02:58, "Qiong" <[email-masked]> wrote:

>> Woj> What are you referring to? Routing ³just works² as normal and is non
>> disaggregated because of the CE-index in the prefix. Classification can/is
>> done on a subset of the v6 address, and that is perfectly legit.
>> 
> Woj> There is no change to the existing destination based routing model. Each
> CE is uniquely addressed by the CE bits in the top /64  ie the CE index is as
> proposed by all the 4rd and divi-pd drafts. The full v4 source address of each
> CE is however also embedded in the interface-id, as per RFC6052. There appears
> to be no cost for this operation, and has the upside of the full v4 info
> visible in the header and allowing source based classification (should one
> want to do that).
> 
> Regards,
> Woj.
> 
> Best wishes
> 
> Qiong 
>

---

From: Qiong <[email-masked]>
Date: Tue, 4 Oct 2011 00:13:53 +0800

Hi Remi and Wojciech,

Thanks for your clarification. I fully agree with you that embedding the
full IPv4 address in the last 64 bits would be quite helpful for some kind
of source address classification and I also suggest that this can be taken
in the same way for encapsulation-based approach. It would be easier for
systems in-the-middle to identify the IPv4 address without packet
decapsulation.

I guess the thing that Ole has mentioned to "look at 24 bits in the middle
of IPv6 address" is for CE to determine whether a downstream IPv6 packet
should be taken for translation or native forwarding. Here, for a dual-stack
host, there would be no difference in the first /64 bits for a native IPv6
packet and a translated packet. What's why the CE should further looking
into the last 64 bits to determine the translation process or native
forwarding. Maybe Ole can clarify for this part again.

However, the situation would still be different in "Hub & Spoke" and "Mesh"
mode. For Hub & Spoke case, since BR will have a default prefix/address, it
would be easily to identify the translated traffic from native IPv6 traffic
by just doing source address routing lookup for a downstream packet. So, the
corresponding mechanics would be different.

Thanks

Best wishes

Qiong

2011/10/3 Wojciech Dec <[email-masked]>

> Woj> What are you referring to? Routing “just works” as normal and is non
> Woj> There is no change to the existing destination based routing model.
> Each CE is uniquely addressed by the CE bits in the top /64 – ie the CE
> index is as proposed by all the 4rd and divi-pd drafts. The full v4 source
> address of each CE is however also embedded in the interface-id, as per
> RFC6052. There appears to be no cost for this operation, and has the upside
> of the full v4 info visible in the header and allowing source based
> classification (should one want to do that).
>
> Regards,
> Woj.
>
> Best wishes
>
> Qiong
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 3 Oct 2011 18:42:55 +0800

Hi Qiong,

Some fields of a unified address format for double translation and encapsulation might be unnecessary for hub and spoke, but using the same format should be advantageous for maintenance and training if for nothing else (assuming that any added complexity is negligible enough).

Believing that a completely unified format is possible, I mentioned it to Alain.
Also, I volunteered to be editor-coordinator for this to happen, but decision of who does what is his.

Regards,
RD

Le 4 oct. 2011 à 00:13, Qiong a écrit :

> Hi Remi and Wojciech,
> 
> Thanks for your clarification. I fully agree with you that embedding the full IPv4 address in the last 64 bits would be quite helpful for some kind of source address classification and I also suggest that this can be taken in the same way for encapsulation-based approach. It would be easier for systems in-the-middle to identify the IPv4 address without packet decapsulation. 
> 
> I guess the thing that Ole has mentioned to "look at 24 bits in the middle of IPv6 address" is for CE to determine whether a downstream IPv6 packet should be taken for translation or native forwarding. Here, for a dual-stack host, there would be no difference in the first /64 bits for a native IPv6 packet and a translated packet. What's why the CE should further looking into the last 64 bits to determine the translation process or native forwarding. Maybe Ole can clarify for this part again.
> 
> However, the situation would still be different in "Hub & Spoke" and "Mesh" mode. For Hub & Spoke case, since BR will have a default prefix/address, it would be easily to identify the translated traffic from native IPv6 traffic by just doing source address routing lookup for a downstream packet. So, the corresponding mechanics would be different.
> 
> Thanks 
> 
> Best wishes
> 
> Qiong
> 
> Woj> What are you referring to? Routing “just works” as normal and is non disaggregated because of the CE-index in the prefix. Classification can/is done on a subset of the v6 address, and that is perfectly legit.
> 
> 
> Woj> There is no change to the existing destination based routing model. Each CE is uniquely addressed by the CE bits in the top /64 – ie the CE index is as proposed by all the 4rd and divi-pd drafts. The full v4 source address of each CE is however also embedded in the interface-id, as per RFC6052. There appears to be no cost for this operation, and has the upside of the full v4 info visible in the header and allowing source based classification (should one want to do that). 
> 
> Regards,
> Woj.
> 
> Best wishes
> 
> Qiong 
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 6 Oct 2011 17:39:53 +0800

Hi Ole,
I just found I didn't answer this mail directly.
In case other exchanged mails wouldn't have answered the point, please see below.

Le 1 oct. 2011 à 04:31, Ole Troan a écrit :

> Remi,
> 
>>>>> what are the requirements for a globally unique interface-id? how is it going to be used?
>>>>> both for encapsulation and translation?
>>>> 
>>>> In both cases, the CE node can recognize 4rd packets, and process them as such, without preempting any IID value that might be a legitimate value for a host behind the CE.
>> 

The proposed solution doesn't impact the forwarding behavior of any function that isn't specifically a 4rd function.

> I don't understand what requirements you are basing this 'solution' on.

Design objectives are listed in Sec 4. 
They include:
- Possibility of IPv6 routing plans that have no constraints related to IPv4 residual deployment.
- Possibility (even in this case) to assign differentiated sharing ratios. This is achieved by having lengths of port-set IDs determined by lengths  of CE IPv6 prefixes. 

> if the 4rd / dIVI CE takes (a well known or provisioned) /64 prefix out of the delegated prefix. then why do you need any of that?

I don't completely follow the proposal, and what you want to avoid.
In any case, the discussion should now focus on the proposed unified address mapping.
Agreed?  

> note that I'm not arguing against having a defined IID for dIVI/4rd, that's nice for pretty printing like what we do for ISATAP.

Good, then.

Cheers,
RD

> cheers,
> Ole

---

From: Xing Li <[email-masked]>
Date: Fri, 07 Oct 2011 14:52:37 +0800

> In any case, the discussion should now focus on the proposed unified address mapping.

In the case of double stateless translation, the IPv6 /128 should 
contains [whole IPv4 address]+[PSID], while the encapsulation may not. xing

---

From: Maoke <[email-masked]>
Date: Sat, 15 Oct 2011 11:14:57 +0900

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-masked]>:
>> 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

---

From: Maoke <[email-masked]>
Date: Sat, 15 Oct 2011 11:35:33 +0900

errata:
2011/10/15 Maoke <[email-masked]>

>  Q2. then it must fine as long as we map them to different Rule IPv6
> Prefix. (?)
>
                                                             ^^53 if PSID
0x54 is 8bit.
but the generated CE3 IPv6 address is as same as CE1,
2001:db9:8765:4000:200:5efe::.

>     Rule_IPv4_Prefix Rule_IPv6_Prefix
                       ^^^^^^^^^^^^^2001:db8::/29

thanks and regards,
maoke

---

From: Jacni Qin <[email-masked]>
Date: Mon, 17 Oct 2011 11:06:45 +0800

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.
>   suppose we have 192.32../12 (0xc0200000/12, i think it's not the 
> 0x602 as Leaf previously mentioned, ;-)
> 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.

> 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.
> 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?

>     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:
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!
> "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.
> > 2011/9/22 Rémi Després <[email-masked] 
> <mailto:[email-masked]>>:
> >> Alain, all,
> >>
> >> We have just posted a new version of our I-D on the proposed 4rd 
> Address Mapping.
> >> It is available at
> <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.
> >> [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>

---

From: Jacni Qin <[email-masked]>
Date: Mon, 17 Oct 2011 11:15:05 +0800

Hi,

On 10/15/2011 10:35 AM, Maoke wrote:
> errata:
> 2011/10/15 Maoke <[email-masked] <mailto:[email-masked]>>
>
>      Q2. then it must fine as long as we map them to different Rule
>     IPv6 Prefix. (?)
>                                                              ^^53 if 
> PSID 0x54 is 8bit.
I guess, it should be 2001:db8:1876:5400::/53

Cheers,
Jacni

---

From: Maoke <[email-masked]>
Date: Mon, 17 Oct 2011 12:59:23 +0900

hi Jacni,

thanks a lot for the reply. please see inline.

2011/10/17 Jacni Qin <[email-masked]>
>   suppose we have 192.32../12 (0xc0200000/12, i think it's not the 0x602
> as Leaf previously mentioned, ;-)
> 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.
>
>
> cannot be routed to the correct CE.
>
> 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? 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?

> addresses for CEs with giving up to use some of them, which have been so
> precious.
>
> 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?

> 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.

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
> Softwires mailing [email-masked]://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Jacni Qin <[email-masked]>
Date: Mon, 17 Oct 2011 15:57:53 +0800

hi,

On 10/17/2011 11:59 AM, Maoke wrote:
> 2011/10/17 Jacni Qin <[email-masked] <mailto:[email-masked]>>
>
>     hi,
>
>>       suppose we have 192.32../12 (0xc0200000/12, i think it's not
>>     the 0x602 as Leaf previously mentioned, ;-)
>>     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.
>
>
>     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.
>
>
> 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);
> (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.
>
>
> 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.

>>     addresses for CEs with giving up to use some of them, which have
>>     been so precious.
>>     Rule_IPv6_Prefix_B is the root of the problem! we have not to use
>>     a prefix covered by another.
> :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::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

>>         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:
>     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

>>     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:
>>     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.
>>     >> We have just posted a new version of our I-D on the proposed
>>     4rd Address Mapping.
>>     >> It is available at
>>     >> Our presentation will be based on THIS version, technically
>>     simpler than version -00.

---

From: Maoke <[email-masked]>
Date: Mon, 17 Oct 2011 20:11:36 +0900

hi,

got it. i was confused. :) but as the exclusiveness has been clarified, it
is not important any more.

thanks,
maoke

---

From: <[email-masked]>
Date: Mon, 17 Oct 2011 21:26:29 +0900

Hi,

This is my command in line.

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. (?)

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 2011:db8:c3b2:a000::/53.
Because the CE3 Rule IPv6 Prefix length is not mulitipe of 4 bits,it need calculate using Binary as follows.

                                 v(/29)
 --elipsis(0x2001 0db)--1000                                            (2011:db8::/29)
 --elipsis(0x4020)------    000 1100 0011 1011 0                 (64.32.24.118)
                                                                   010 1010 0 (PSID 0x54)
--------------------------------------------------------------------------
CE3 IPv6 prefix: 2001:db8:c3b2:a000::/53

If the CE3 IPv4 address is 64.32.48.236, CE3 PSID is 0xa8, calculate as follows,
                                 v(/29)
 --elipsis(0x2001 0db)--1000                                            (2011:db8::/29)
 --elipsis(0x4020)------    001 1000 0111 0110 0                 (64.32.48.236)
                                                                   101 0100 0 (PSID 0xa8)
--------------------------------------------------------------------------
the CE3 IPv6 prefix is 2001:db9:8765:4000::/53

I think this  should be not gonna happen, since the IPv6 address planing must be done natively
considering nothing about the IPv4 address. As exclusiveness, each CE has unique CE IPv6 Prefix.

As described in the example Maoke given, since "Rule IPv6 Prefix B" is contained in the "Rule IPv6 Prefix A",
if the IPv6 addresses under Rule IPv6 Prefix A and the IPv6 address under Rule IPv6 prefix B are assigned independently
and have any consideration each other, same CE IPv6 prefix assigning to different CEs may be happen. I think this MUST be
 avoided when designing the mapping rules or setting the IPv6 assigning way(such as DHCPv6 etc.).

Cheers

Chunfa

---

From: Jacni Qin <[email-masked]>
Date: Tue, 18 Oct 2011 09:53:40 +0800

hi

On 10/17/2011 8:26 PM, [email-masked] wrote:
>>>     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.
>>>     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?
>>
>>
Oops, sorry. ;-)

> if the IPv6 addresses under Rule IPv6 Prefix A and the IPv6 address
> under Rule IPv6 prefix B are assigned independently
> and have any consideration each other, same CE IPv6 prefix assigning
> to different CEs may be happen. I think this MUST be
The address assignment under one given prefix should be done with
considerations to avoid conflicts.

Cheers,
Jacni

---

From: Maoke <[email-masked]>
Date: Tue, 18 Oct 2011 11:28:20 +0900

hi Chunfa and Jacni,

thanks a lot for the corrections and clarifications. :)

2011/10/17 <[email-masked]>

>                                                                    010 1010
> 0 (PSID 0x54)
>                                                                    101 0100
> 0 (PSID 0xa8)
> if the IPv6 addresses under Rule IPv6 Prefix A and the IPv6 address under
> Rule IPv6 prefix B are assigned independently
> and have any consideration each other, same CE IPv6 prefix assigning to
> different CEs may be happen. I think this MUST be
the consensus is keeping the exclusiveness of IPv4 address blocks in IPv6.
therefore, i understand the logic of address planning for CEs in 4rd could
be the following 4 steps:

1) list all mutually exclusive IPv4 networks to be involved in the residual
deployment, i.e., Rule IPv4 prefixes;
2) calculate IPv6 prefix length for each Rule IPv4 prefix, according to the
length of the prefix and the requirement like the PSID length and the CE
prefix length;
3) allocate the IPv6 address space into exclusive blocks, i.e.
rule_IPv6_prefixes, according to the prefix length requirements in 2), and
get the mapping rules;
4) assigning IPv6 address in each block for the CE.

am i right?

cheers,
maoke

---

From: Jacni Qin <[email-masked]>
Date: Tue, 18 Oct 2011 10:54:24 +0800

hi,

On 10/18/2011 10:28 AM, Maoke wrote:
> ...
>
>
> the consensus is keeping the exclusiveness of IPv4 address blocks in
> IPv6. therefore, i understand the logic of address planning for CEs in
> 4rd could be the following 4 steps:
>
> 1) list all mutually exclusive IPv4 networks to be involved in the
> residual deployment, i.e., Rule IPv4 prefixes;
> 2) calculate IPv6 prefix length for each Rule IPv4 prefix,
For clarifications, you mean the "Rule IPv6 Prefix" length, right? since
the length of Delegated Prefix should have been settled before this step.

Cheers,
Jacni

> according to the length of the prefix and the requirement like the
> PSID length and the CE prefix length;
> rule_IPv6_prefixes, according to the prefix length requirements in 2),
> and get the mapping rules;

---

From: Maoke <[email-masked]>
Date: Wed, 19 Oct 2011 07:21:18 +0900

hi Jacni,

> the length of Delegated Prefix should have been settled before this step.
sure. i meant the Rule IPv6 Prefix length. :)

there is still another issue, the MAX PSID. personally i like the algorithm
of making longest-match for the PSID. however, the position of the PSID is
somehow a problem. in the step 2) (or a little before), when you setting the
delegated prefix length, this length only covers the IPv4 suffix and the
PSID itself, right?

then if the length is, e.g., /64, and the PSID occupies the last 4 bits.
then the MAX PSID for a CE is put at 60 ~ 71 bits. this is fine with the
routing, which can get the encapsulated stuff to the right CE. however, it
may hurt the IID to some extent, for example, we have the PSID=0x4, while
for a certain packet, it contains destination port 0xe488, then the MAX PSID
= 0x488, and then the IID part for this packet towards the dst CE will be
not 200:5efe:: any more but

           8800:5efe::

right? making the "u" bit destroyed, and the destination CE cannot identify
this is a packet for encapsulation or a packet for direct forwarding. it
also detroys the V-bit in the unified address format.

thus, may i understand that the planning should accommodate the MAX PSID in
the first 64 bits as well? if so, can we really satisfy the requirement R-1
at the Beijing interim, stating "Efficient bit representation.  Address +
Port range in =/56", if the PSID is less than 4 bits?

sorry if i made anything, wrong. just try to understand the design, its
strength and limitations.

best,
maoke

---

From: Jacni Qin <[email-masked]>
Date: Wed, 19 Oct 2011 09:36:07 +0800

hi,

On 10/19/2011 6:21 AM, Maoke wrote:
> hi Jacni,
> 在 2011年10月18日 上午11:54，Jacni Qin <[email-masked] 
> <mailto:[email-masked]>>写 道：
>
>>     1) list all mutually exclusive IPv4 networks to be involved in
>>     the residual deployment, i.e., Rule IPv4 prefixes;
>     For clarifications, you mean the "Rule IPv6 Prefix" length, right?
>     since the length of Delegated Prefix should have been settled
>     before this step.
>
Ok, good.

> there is still another issue, the MAX PSID. personally i like the 
> algorithm of making longest-match for the PSID. however, the position 
> of the PSID is somehow a problem. in the step 2) (or a little before), 
> when you setting the delegated prefix length, this length only covers 
> the IPv4 suffix and the PSID itself, right?
The Max PSID idea has been dropped by restoring the parameter "L", in 
each rule.

Cheers,
Jacni

> then if the length is, e.g., /64, and the PSID occupies the last 4 
> bits. then the MAX PSID for a CE is put at 60 ~ 71 bits. this is fine 
> with the routing, which can get the encapsulated stuff to the right 
> CE. however, it may hurt the IID to some extent, for example, we have 
> the PSID=0x4, while for a certain packet, it contains destination port 
> 0xe488, then the MAX PSID = 0x488, and then the IID part for this 
> packet towards the dst CE will be not 200:5efe:: any more but
>            8800:5efe::
> right? making the "u" bit destroyed, and the destination CE cannot 
> identify this is a packet for encapsulation or a packet for direct 
> forwarding. it also detroys the V-bit in the unified address format.
> thus, may i understand that the planning should accommodate the MAX 
> PSID in the first 64 bits as well? if so, can we really satisfy the 
> requirement R-1 at the Beijing interim, stating "Efficient bit 
> representation.  Address + Port range in =/56", if the PSID is less 
> than 4 bits?
> sorry if i made anything, wrong. just try to understand the design, 
> its strength and limitations.
> best,
> maoke
>
>
>     Cheers,
>     Jacni
>

---

From: Maoke <[email-masked]>
Date: Wed, 19 Oct 2011 11:00:18 +0900

hi Jacni,

2011/10/19 Jacni Qin <[email-masked]>

> algorithm of making longest-match for the PSID. however, the position of the
> PSID is somehow a problem. in the step 2) (or a little before), when you
> setting the delegated prefix length, this length only covers the IPv4 suffix
> and the PSID itself, right?
>
>
>
> The Max PSID idea has been dropped by restoring the parameter "L", in each
> rule.
>

then it is a parameter in configuration or embedded into the address format?
a single value over the domain or possible variable among different shared
IPv4 addresses? (to my understanding, one address should have a common value
of PSID length for all the CEs sharing the address, right?)

thanks and regards,
maoke

---

From: Jacni Qin <[email-masked]>
Date: Wed, 19 Oct 2011 11:19:33 +0800

hi,

On 10/19/2011 10:00 AM, Maoke wrote:
> hi Jacni,
>
> 2011/10/19 Jacni Qin <[email-masked] <mailto:[email-masked]>>
>
>     algorithm of making longest-match for the PSID. however, the
>     position of the PSID is somehow a problem. in the step 2) (or a
>     little before), when you setting the delegated prefix length, this
>     length only covers the IPv4 suffix and the PSID itself, right?
>     The Max PSID idea has been dropped by restoring the parameter "L",
>     in each rule.
>
>
It's a parameter in the rule.

> a single value over the domain or possible variable among different 
> shared IPv4 addresses? (to my understanding, one address should have a 
> common value of PSID length for all the CEs sharing the address, right?)
The number of L equals the number of Delegated Prefixes of different 
lengths totally within a given domain, which should be determined during 
IPv6 address planning.

Cheers,
Jacni

---

From: Maoke <[email-masked]>
Date: Wed, 19 Oct 2011 14:50:31 +0900

hi,

> lengths totally within a given domain, which should be determined during
they are equal to each other. but which determines which, in or before the
IPv6 address planning? delegated prefix length decides PSID length (sharing
ratio), or inversely? is it not that the sharing ratio is determined by how
many CEs sharing a unique IPv4 address?

best,
maoke

---

From: Jacni Qin <[email-masked]>
Date: Wed, 19 Oct 2011 15:52:10 +0800

hi,

On 10/19/2011 1:50 PM, Maoke wrote:
>>     a single value over the domain or possible variable among
>>     different shared IPv4 addresses? (to my understanding, one
>>     address should have a common value of PSID length for all the CEs
>>     sharing the address, right?)
>     The number of L equals the number of Delegated Prefixes of
>     different lengths totally within a given domain, which should be
>     determined during IPv6 address planning.
>
>
> they are equal to each other. but which determines which, in or before 
> the IPv6 address planning?
IMHO, I guess the length of Delegated Prefix settled in phase of the 
native IPv6 address planning without considering anything about IPv4 
addressing, determines the L.

Cheers,
Jacni

> delegated prefix length decides PSID length (sharing ratio), or 
> inversely? is it not that the sharing ratio is determined by how many 
> CEs sharing a unique IPv4 address?
>
> best,
> maoke
>
>     Cheers,
>     Jacni
>
>

---

From: Maoke <[email-masked]>
Date: Wed, 19 Oct 2011 20:33:11 +0900

> IMHO, I guess the length of Delegated Prefix settled in phase of the native
> IPv6 address planning without considering anything about IPv4 addressing,
> determines the L.
>
>
?? i suppose previously with your clarification you HAVE admitted your
consensus to my 1) ~ 4) as the logic of the operation, but now you said
"without considering anything about IPv4". may you clarify your process with
starting from the following example?

i allocate:
   CE1 2001:db9:8765:4320::/60
   CE2 2001:db8:7654:3210::/60
then the IPv6 address planning is finished according to your statement.

then what information should i use to determine the L for each? you mean the
IPv6 address planning is enough?

thanks,
maoke

> inversely? is it not that the sharing ratio is determined by how many CEs
> sharing a unique IPv4 address?
>
>  best,
> maoke
>
>
>> Cheers,
>>  Jacni
>>
>
>

---

From: Maoke <[email-masked]>
Date: Wed, 19 Oct 2011 20:37:58 +0900

hi Remi,

2011/10/19 Rémi Després <[email-masked]>

> Hi Maoke,
>
> CE PSIDs are never such that CE IPv6 prefixes exceed /64.
> The Max PSID of a CE, as opposed to its exact PSID, is only used to reach
> the CE from a BR or other in which  CE IPv6-prefix length is unknown.
>

for finding the destination CE, even with no knowledge about its PSID
length, right?

>
> As shown in Figure 6-A of the addmapping draft, if the Max CE index that is
> derived from the destination A+P is such that Rule IPv6 prefix + Max CE
> index exceeds 64 bit, the Max CE index is truncated to 64 bits. None of the
> 4rd-addmapping addresses has an IPv6 prefix longer than /64.
>
> Hope it clarifies.
>

then "truncated to 64 bits" clarifies. thank you, Remi, for the explanation.
:)

best,
maoke

---

From: Jacni Qin <[email-masked]>
Date: Thu, 20 Oct 2011 08:59:56 +0800

hi,

On 10/19/2011 7:33 PM, Maoke wrote:
> ..
>>>         address should have a common value of PSID length for all
>>>         the CEs sharing the address, right?)
>>         different lengths totally within a given domain, which should
>>         be determined during IPv6 address planning.
>>
>>
>>     they are equal to each other. but which determines which, in or
>>     before the IPv6 address planning?
>     IMHO, I guess the length of Delegated Prefix settled in phase of
>     the native IPv6 address planning without considering anything
>     about IPv4 addressing, determines the L.
>
>
> consensus to my 1) ~ 4) as the logic of the operation, but now you 
> said "without considering anything about IPv4". may you clarify your 
> process with starting from the following example?
>
Sorry, maybe there was some misunderstanding between us.
I mean you don't need to consider IPv4 when try to decide the length of 
delegated prefix to be assigned to customer. Maybe it was appropriate to 
use the word "anything". ;-)
Something should be considered if you need multiple sharing ratios.

> then what information should i use to determine the L for each? you 
> mean the IPv6 address planning is enough?
>
Yes.

Cheers,
Jacni

>>     inversely? is it not that the sharing ratio is determined by how

---

From: Maoke <[email-masked]>
Date: Thu, 20 Oct 2011 13:34:35 +0900

2011/10/20 Jacni Qin <[email-masked]>
> delegated prefix to be assigned to customer. Maybe it was appropriate to use
> the word "anything". ;-)
>  then what information should i use to determine the L for each? you mean
> the IPv6 address planning is enough?
>
>   Yes.
>
>
your yes is in the case of there is not multiple sharing ratios, right? ;-)

if it is right, i agree with you that the planning is independent of IPv4
knowledge. if there are multiple ratios, i understanding the start of the
PSIDs must be aligned among the delegated IPv6 prefixes.

best,
maoke

---

From: Maoke <[email-masked]>
Date: Thu, 20 Oct 2011 23:48:40 +0900

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-masked]>

> 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? ;-)

>
>  - 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).
>
>   (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)
> (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?

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?

> Note that this is by no means to say that all ISPs should plan addresses
> this way (i.e. with a relationship between lengths of CE IPv6 prefixes and
> sharing ratios). It is just to show that this  is workable.
>
>

sure. but i believe this will helps operators very much, considering up to
now no operators have experienced that.

thanks,
maoke

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Oct 2011 12:14:39 +0200

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.
> 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:
>  
>  

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)
> (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.
> 
> 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

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.

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.

If the above is still unclear (or bugged!), thanks for letting me know.

Regards,
RD

>  
> Note that this is by no means to say that all ISPs should plan addresses this way (i.e. with a relationship between lengths of CE IPv6 prefixes and sharing ratios). It is just to show that this  is workable.
>  
>  
> sure. but i believe this will helps operators very much, considering up to now no operators have experienced that.
>  
> thanks,
> maoke
>  
>  
> Regards,
> RD 
>

---

From: Maoke <[email-masked]>
Date: Fri, 21 Oct 2011 20:34:18 +0900

Remi,

thanks for the further explanation. let me remove the cleared part and make
the message shorter. :P

2011/10/21 Rémi Després <[email-masked]>

> The right formula for ri is:  ri = m - (32 - hi)

yeah. :P i didn't discover that.

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?

> 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

the EA bits = 2) + 3), right?

> 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", :(

> 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.
>
> planning is not deployable, but with our effort of maximum compression,
>
> 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.

Regards,

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Oct 2011 15:20:39 +0200

Le 21 oct. 2011 à 13:34, Maoke a écrit :
...
...
> 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 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

> 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.

---

From: Washam Fan <[email-masked]>
Date: Fri, 21 Oct 2011 22:55:02 +0800

Hi Remi,

Please see inline.

> 5) A 0 padding if fields 1 to 4 don't reach 64 bits

What if fields 1 to 4 exceed 64 bits? truncated, right?
Want to confirm again from you. The max length of CE IPv6 prefix is 64
bits, right?

Thanks,
washam

---

From: Rémi Després <[email-masked]>
Date: Fri, 21 Oct 2011 17:28:21 +0200

Hi Washam,
 
Le 21 oct. 2011 à 16:55, Washam Fan a écrit :

>> 4) 

Yes.
4) would have better been written "If the PSID length is unknown, the "PSID complement" (remainder of the Max PSID, truncated if necessary for the subnet prefix not to exceed 64 bits).

Yes.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Sat, 22 Oct 2011 02:30:00 +0900

hi Remi,

thanks for the further explanation.

> *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.
>
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?

> 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).
>> 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.
>>

---

From: Maoke <[email-masked]>
Date: Mon, 24 Oct 2011 01:25:33 +0900

hi Remi,

2011/10/21 Rémi Després <[email-masked]>

>> Here are address-planning steps that illustrate how an IPv6 addressing
>> plan can be kept independent from IPv4 prefixes used for IPv4 residual
 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

---

From: Maoke <[email-masked]>
Date: Mon, 24 Oct 2011 01:39:23 +0900

sorry, bug-fix on bug-fix. :P it should be (32 - hi) rather than hi in the
pic. - M.

2011/10/24 Maoke [email-masked]

> |<--- c ---->|<-- ri ->|<- (32-hi) ->|
>
>

---

From: Rémi Després <[email-masked]>
Date: Sun, 23 Oct 2011 19:22:41 +0200

> |            |<---------   n   ----------->|<k>|

Correct (with the correction made in your next mail: hi replaced by 32 - hi)

> and thus c = x - (n + k), right? ;-)

Indeed.
Thanks fot the careful review.

Cheers,
RD

---

From: Jiang Dong <[email-masked]>
Date: Tue, 25 Oct 2011 15:45:20 +0800

Hi,Softwirers,

	Since the Softwire Mesh MIB is also on the milestones, I think we need to do something to improve the progress about it.
	
	Following is the link about the mesh MIB draft: http://tools.ietf.org/html/draft-cui-softwire-mesh-mib-02. This version intrduces the relationship between If MIB and IP Tunnel MIB. Since there's no encapsulation message in the IP tunnel MIB, we add an encapsulation table in the softwire mesh MIB.	

	We really appreciate for any valuable comments about this draft. Thank you very much!