Subject: [Softwires] map-deployment-01 draft

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Fri, 15 Mar 2013 20:04:50 +0000

I was able to follow section 5.1 of this draft somewhat but then got completely lost at step B3.
It would really help if you can also describe the reason why are you performing each step - in other words put more context around it. Otherwise, it will be very hard for the operators to follow this.

Maybe we can start from a more comprehensive example and you can include it the draft along with your steps.
Here is my example and logic that I follow:

1)      Example requirement:

-          There are about 22,000 residual IPv4 addresses that needs to be translated via MAP.

-          Each  such address should have 4K ports available. Therefore, the IP address sharing ratio is 16:1

-          The public IPv4 addresses that are available to the operator for this translation are four  /24 subnets (11.11.11.0/24 , 12.12.12..0/24, 13.13.13.0/24 and 14.14.14.0/24)  and one /22 subnet (15.15.0.0/22).

-          The IPv6 prefix that is delegated to the operator is 2001:db8::/32 .

-          4K users (or CPEs corresponding to the residual IP addresses) will get PD /56, the rest of the users will get PD /60.

-          The end-user-prefix and the rules will be delegated via DHCPv6 server

22,000 residual IP addresses in 16:1 sharing scenario could be covered with two /24 subnets and one /22 subnet  => (2 * 2^8 * 16 + 2^10 * 16 = 24, 576).

So Rule IPv4 prefix and EA bits length  will be:

1)      11.11.11.0/24    EA length: 12 bits  (8 bits for the IPv4 suffix and 4 bits for PSID)    => these users will get PD /56 (arbitrarily determined by the operator and in conformance with the requirement)

2)      12.12.12.0/24    EA length: 12 bits                                                                                              => these users will get PD /60 (arbitrarily determined by the operator and in conformance with the requirement)

3)      15.15.0.0/22      EA length: 14 bits  (10 bits for IPv4 suffix and 4 bits for PSID)          => these users will get PD/60 (arbitrarily determined by the operator and in conformance with the requirement)

That was the easy part. What we need to do now is to determine:

-          Rule IPv6 Prefix  (to complete BMR/FMR)

-          How will the end user DHCPv6 prefix (PD) be carved out by DHCP server (assumption is that DHCPv6 server delegates v6 prefix and Rules).

We will represents the bits in v6 address via the following graph (we will ignore irrelevant parts of the v6 addresses for this discussion and instead consider only the bits /32 to /64):

                /32         /36         /40         /44         /48         /52         /56         /60         /64
xxxx       xxxx       xxxx       xxxx       xxxx       xxxx       xxxx       xxxx       xxxx
                                                                | |          |                              |              |
                                                                |< --------EA=12-------->|              |                             1) this will cover subnet 1) ; EA bits extend from the PD length (/56) to the Rule IPv6 prefix length (/44)
                                                                    |          |< ---------EA=12------ >|                              2) this will cover subnet 2);  EA bits extend from the PD length (/60) to the Rule IPv6 prefix length (/48)
                                                                    |< ----------------EA=14------ >|                               3) this will cover subnet 3) ; EA bits extend from the PD length (/60) to the Rule IPv6 prefix length (/46)

Now we have determined IPv6 Rule Prefix length for each of the three rules that we need to create.
The IPv4 Prefix Rule lengths are /44, /48 and /46 for the cases 1), 2) and 3) respectively.

Now we need to determine how can each end user prefix be uniquely allocated across all users (CEs). The only way to ensure this uniqueness is to ensure that the portion of the IPv6 Rule prefix up to /44 (smallest Rule IPv6 prefix length between all the rules in the MAP domain) is unique amongst all the rules.
So, the IPv6 Rule prefixes for our three cases will be (changing the part above /44):

1)      2001:db8:0000::/44

2)      2001:db8:0010::/48

3)      2001:db8:0020::/46

The last step is to ensure that the DHCPv6 server hands out proper end-user prefixes (and along with the prefixes, the Rules are delegated as well).
So the DHCPv6 can be configured so that it is carving the prefixes from three ranges:

1)      2001:db8:000x:xxyy::  (where x denotes carving part from /44 to /56 - the EA bits; 'y' denotes further subneting that is done on the CPE -> yy=00 for MAP prefix, the remaining combinations are reserved for CPE delegation to its clients)

2)      2001:db8:0100:xxxy::  (where x denotes carving part from /48 to /60 - the EA bits; 'y' denotes further subneting that is done on the CPE -> y=0 for MAP prefix, the remaining combinations are reserved for CPE delegation to its clients)

3)      2001:db8:020w:xxxy::  (where x and two lower bits of 'w' denote carving part from /46 to /60 - the EA bits; 'y' denotes further subneting that is done on the CPE -> y=0 for MAP prefix, the remaining combinations are reserved for CPE delegation to its clients)

Along with each user end prefix a BMR and a DMR will be delegated to the end-users (so we will have a hub and spoke topology)

Also note that to cover the holes between the /48 and /44 for case 2) we can easily add 15 more /24 IPv4 prefixes by creating new IPv6 Rule by changing bits between /44 and /48.
Similarly for case 3), we can create 3 more IPv6 rule prefixes (and add 3 more /22 IPv4 subnets) by changing bits between /46 and /48. This would allow us to expand the coverage for residual IPs (although the purpose of NAT is to minimize their use over time not to expand :)).

---

From: Maoke <[email-masked]>
Date: Sat, 16 Mar 2013 09:45:56 +0900

hi Kristian,

thanks a lot for the comments! i totally agree with you that there should
be a comprehensive example for the step-by-step guideline. (i remember that
we put such an example in early sketch but later some said it might not
necessary. :P) i would like to ask the wg (and other authors) for the
consensus of adding the example into the draft.
2013/3/16 Poscic, Kristian (Kristian) <[email-masked]>

>  ** **
>
> I was able to follow section 5.1 of this draft somewhat but then got
> completely lost at step B3. ****
>
> It would really help if you can also describe the reason why are you
> performing each step – in other words put more context around it.
> Otherwise, it will be very hard for the operators to follow this.****
>
> ** **
>
> Maybe we can start from a more comprehensive example and you can include
> it the draft along with your steps. ****
>
> Here is my example and logic that I follow:****
>
> ** **
>
> **1)      **Example requirement:****
>
> **-          **There are about 22,000 residual IPv4 addresses that needs
> to be translated via MAP.****
>
> **-          **Each  such address should have 4K ports available.
> Therefore, the IP address sharing ratio is 16:1****
>
> **-          **The public IPv4 addresses that are available to the
> operator for this translation are four  /24 subnets (11.11.11.0/24 ,
> 12.12.12..0/24, 13.13.13.0/24 and 14.14.14.0/24)  and one /22 subnet (
> 15.15.0.0/22).****
>
> **-          **The IPv6 prefix that is delegated to the operator is
> 2001:db8::/32 .****
>
> **-          **4K users (or CPEs corresponding to the residual IP
> addresses) will get PD /56, the rest of the users will get PD /60.****
>
> **-          **The end-user-prefix and the rules will be delegated via
> DHCPv6 server
>

 i like this start of example! some further considerations sould be
included (as the example for the remarks)

#1 the public IPv4 addresses might be quite bad aggregated;
#2 the IPv6 common prefix for the MAP deployment might be not exist -- MAP
can be deployed cross autonomous systems where delegated prefices are not
aggregateable at all. (this is a typical case where 1:1 mode is needed)
#3 DHCPv6 is not the only way for the provisioning, and at least manual
configuraton MUST be supported. therefore we cannot put anything that needs
DHCPv6 as prerequisite for deployment and implementation.

>
>
> ** **
>
> 22,000 residual IP addresses in 16:1 sharing scenario could be covered
> with two /24 subnets and one /22 subnet  => (2 * 2^8 * 16 + 2^10 * 16 = 24,
> 576).****
>
> ** **
>
> So Rule IPv4 prefix and EA bits length  will be:****
>
> ** **
>
> **1)      **11.11.11.0/24    EA length: 12 bits  (8 bits for the IPv4
> suffix and 4 bits for PSID)    => these users will get PD /56 (arbitrarily
> determined by the operator and in conformance with the requirement)****
>
> **2)      **12.12.12.0/24    EA length: 12
> bits
> => these users will get PD /60 (arbitrarily determined by the operator and
> in conformance with the requirement)****
>
> **3)      **15.15.0.0/22      EA length: 14 bits  (10 bits for IPv4
> suffix and 4 bits for PSID)          => these users will get PD/60
> (arbitrarily determined by the operator and in conformance with the
> requirement)****
>
> ** **
>
> That was the easy part. What we need to do now is to determine:****
>
> **-          **Rule IPv6 Prefix  (to complete BMR/FMR)****
>
> **-          **How will the end user DHCPv6 prefix (PD) be carved out by
> DHCP server (assumption is that DHCPv6 server delegates v6 prefix and
> Rules).****
>
> ** **
>
> We will represents the bits in v6 address via the following graph (we will
> ignore irrelevant parts of the v6 addresses for this discussion and instead
> consider only the bits /32 to /64):****
>
> ** **
>
>                 /32         /36         /40         /44
> /48         /52         /56         /60         /64****
>
> xxxx       xxxx       xxxx       xxxx       xxxx       xxxx
> xxxx       xxxx       xxxx  ****
>
>                                                                 |
> |          |                              |              |****
>
>                                                                 |<
> --------EA=12-------->|              |                             1) this
> will cover subnet 1) ; EA bits extend from the PD length (/56) to the Rule
> IPv6 prefix length (/44)****
>
>
> |          |< ---------EA=12------ >|                              2) this
> will cover subnet 2);  EA bits extend from the PD length (/60) to the Rule
> IPv6 prefix length (/48)****
>
>                                                                     |<
> ----------------EA=14------ >|                               3) this will
> cover subnet 3) ; EA bits extend from the PD length (/60) to the Rule IPv6
> prefix length (/46)       ****
>
> ** **
>
> Now we have determined IPv6 Rule Prefix length for each of the three rules
> that we need to create. ****
>
> The IPv4 Prefix Rule lengths are /44, /48 and /46 for the cases 1), 2) and
> 3) respectively.****
>
> ** **
>
> Now we need to determine how can each end user prefix be uniquely
> allocated across all users (CEs). The only way to ensure this uniqueness is
> to ensure that the portion of the IPv6 Rule prefix up to /44 (smallest Rule
> IPv6 prefix length between all the rules in the MAP domain) is unique
> amongst all the rules.****
>
> So, the IPv6 Rule prefixes for our three cases will be (changing the part
> above /44):****
>
> **1)      **2001:db8:0000::/44****
>
> **2)      **2001:db8:0010::/48****
>
> **3)      **2001:db8:0020::/46****
>
> ** **
>
> The last step is to ensure that the DHCPv6 server hands out proper
> end-user prefixes (and along with the prefixes, the Rules are delegated as
> well).****
>
> So the DHCPv6 can be configured so that it is carving the prefixes from
> three ranges:****
>
> ** **
>
> **1)      **2001:db8:000x:xxyy::  (where x denotes carving part from /44
> to /56 – the EA bits; ‘y’ denotes further subneting that is done on the CPE
> -> yy=00 for MAP prefix, the remaining combinations are reserved for CPE
> delegation to its clients)****
>
> **2)      **2001:db8:0100:xxxy::  (where x denotes carving part from /48
> to /60 – the EA bits; ‘y’ denotes further subneting that is done on the CPE
> -> y=0 for MAP prefix, the remaining combinations are reserved for CPE
> delegation to its clients)****
>
> **3)      **2001:db8:020w:xxxy::  (where x and two lower bits of ‘w’
> denote carving part from /46 to /60 – the EA bits; ‘y’ denotes further
> subneting that is done on the CPE -> y=0 for MAP prefix, the remaining
> combinations are reserved for CPE delegation to its clients)****
>
> ** **
>
> Along with each user end prefix a BMR and a DMR will be delegated to the
> end-users (so we will have a hub and spoke topology)****
>
> ** **
>
> Also note that to cover the holes between the /48 and /44 for case 2) we
> can easily add 15 more /24 IPv4 prefixes by creating new IPv6 Rule by
> changing bits between /44 and /48.****
>
> Similarly for case 3), we can create 3 more IPv6 rule prefixes (and add 3
> more /22 IPv4 subnets) by changing bits between /46 and /48. This would
> allow us to expand the coverage for residual IPs (although the purpose of
> NAT is to minimize their use over time not to expand J).
>
>
>

>> co-authors: we may compose the 5.1 again based on Kristian's proposed
example and includes the #1 ~ #3 above and submit for wg review. agree?

- maoke

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

---

From: "Lee, Yiu" <[email-masked]>
Date: Sat, 16 Mar 2013 01:37:43 +0000

+1. Adding an example will definitely help.

From:  Maoke <[email-masked]>
Date:  Friday, March 15, 2013 8:45 PM
To:  "Poscic, Kristian (Kristian)" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [Softwires] map-deployment-01 draft

hi Kristian, 
 
thanks a lot for the comments! i totally agree with you that there should be
a comprehensive example for the step-by-step guideline. (i remember that we
put such an example in early sketch but later some said it might not
necessary. :P) i would like to ask the wg (and other authors) for the
consensus of adding the example into the draft.
2013/3/16 Poscic, Kristian (Kristian) <[email-masked]>
> completely lost at step B3.
> performing each step  in other words put more context around it. Otherwise,
> it will be very hard for the operators to follow this.
>  
> -         The public IPv4 addresses that are available to the operator for
> this translation are four  /24 subnets (11.11.11.0/24 <http://11.11.11.0/24>
> , 12.12.12..0/24, 13.13.13.0/24 <http://13.13.13.0/24>  and 14.14.14.0/24
> <http://14.14.14.0/24> )  and one /22 subnet (15.15.0.0/22
> <http://15.15.0.0/22> ).
> 
> -         4K users (or CPEs corresponding to the residual IP addresses) will
> get PD /56, the rest of the users will get PD /60.
> 

 i like this start of example! some further considerations sould be included
(as the example for the remarks)
 
>  
> 
>  
> 22,000 residual IP addresses in 16:1 sharing scenario could be covered with
> two /24 subnets and one /22 subnet  => (2 * 2^8 * 16 + 2^10 * 16 = 24, 576).
>  
> 1)     11.11.11.0/24 <http://11.11.11.0/24>     EA length: 12 bits  (8 bits
> for the IPv4 suffix and 4 bits for PSID)    => these users will get PD /56
> requirement)
> 2)     12.12.12.0/24 <http://12.12.12.0/24>     EA length: 12 bits
> => these users will get PD /60 (arbitrarily determined by the operator and in
> conformance with the requirement)
> 
> 3)     15.15.0.0/22 <http://15.15.0.0/22>       EA length: 14 bits  (10 bits
> for IPv4 suffix and 4 bits for PSID)          => these users will get PD/60
> requirement)
> -         How will the end user DHCPv6 prefix (PD) be carved out by DHCP
> server (assumption is that DHCPv6 server delegates v6 prefix and Rules).
> 
>  
> consider only the bits /32 to /64):
>  
>                 /32         /36         /40         /44         /48
> /52         /56         /60         /64
>                                                                 | |          |
> |              |
> IPv6 prefix length (/44)
> |< ---------EA=12------ >|                              2) this will cover
> subnet 2);  EA bits extend from the PD length (/60) to the Rule IPv6 prefix
> length (/48)
>                                                                     |<
> prefix length (/46)
> that we need to create.
> Now we need to determine how can each end user prefix be uniquely allocated
> across all users (CEs). The only way to ensure this uniqueness is to ensure
> that the portion of the IPv6 Rule prefix up to /44 (smallest Rule IPv6 prefix
> length between all the rules in the MAP domain) is unique amongst all the
> rules.
> above /44):
> The last step is to ensure that the DHCPv6 server hands out proper end-user
> prefixes (and along with the prefixes, the Rules are delegated as well).
> 1)     2001:db8:000x:xxyy::  (where x denotes carving part from /44 to /56 
> the EA bits; Œy¹ denotes further subneting that is done on the CPE -> yy=00
> for MAP prefix, the remaining combinations are reserved for CPE delegation to
> its clients)
> 
> 2)     2001:db8:0100:xxxy::  (where x denotes carving part from /48 to /60 
> the EA bits; Œy¹ denotes further subneting that is done on the CPE -> y=0 for
> MAP prefix, the remaining combinations are reserved for CPE delegation to its
> clients)
> 
> 3)     2001:db8:020w:xxxy::  (where x and two lower bits of Œw¹ denote carving
> part from /46 to /60  the EA bits; Œy¹ denotes further subneting that is done
> on the CPE -> y=0 for MAP prefix, the remaining combinations are reserved for
> CPE delegation to its clients)
> 
>  
> end-users (so we will have a hub and spoke topology)
>  
> Also note that to cover the holes between the /48 and /44 for case 2) we can
> easily add 15 more /24 IPv4 prefixes by creating new IPv6 Rule by changing
> bits between /44 and /48.
> Similarly for case 3), we can create 3 more IPv6 rule prefixes (and add 3 more
> /22 IPv4 subnets) by changing bits between /46 and /48. This would allow us to
> expand the coverage for residual IPs (although the purpose of NAT is to
> minimize their use over time not to expand J).
>  
 
>> co-authors: we may compose the 5.1 again based on Kristian's proposed example
and includes the #1 ~ #3 above and submit for wg review. agree?
 
- maoke

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 22 Mar 2013 14:47:33 +0800

Hi Maoke, Kristian,

Thanks for your comments! I totally agree with you that we should add an example for step-by-step guideline. Please see some further comments inline.

On 2013-3-16, at 8:45, Maoke <[email-masked]> wrote:

> hi Kristian,
>  
> thanks a lot for the comments! i totally agree with you that there should be a comprehensive example for the step-by-step guideline. (i remember that we put such an example in early sketch but later some said it might not necessary. :P) i would like to ask the wg (and other authors) for the consensus of adding the example into the draft. 
>> It would really help if you can also describe the reason why are you performing each step – in other words put more context around it. Otherwise, it will be very hard for the operators to follow this.
>> 
>>  
>> 
>  i like this start of example! some further considerations sould be included (as the example for the remarks) 
>  
I agree we should take this feature into consideration. However, in this case, as the number of mapping rules will increase accordingly, more careful considerations should be taken on MAP domain planning and rule planning. I think it might be useful to give a recommended maximum number of rules for which a domain would have, especially for mesh mode.
> #2 the IPv6 common prefix for the MAP deployment might be not exist -- MAP can be deployed cross autonomous systems where delegated prefices are not aggregateable at all. (this is a typical case where 1:1 mode is needed)
For EA bit = 0 case, we already have some text on section 5.2. Are you suggesting to improve this paragraph by explaining more clearly about the scenario requirement?
> #3 DHCPv6 is not the only way for the provisioning, and at least manual configuraton MUST be supported. therefore we cannot put anything that needs DHCPv6 as prerequisite for deployment and implementation.
Agree. For DHCP based solution, as the finally conclusion has not come out yet, I think we should wait for dhc's decision and also be consistent with unified CPE draft for provisioning. 

Thoughts ?

Best wishes
Qigong
>> 1)      2001:db8:000x:xxyy::  (where x denotes carving part from /44 to /56 – the EA bits; ‘y’ denotes further subneting that is done on the CPE -> yy=00 for MAP prefix, the remaining combinations are reserved for CPE delegation to its clients)
>> 
>> 2)      2001:db8:0100:xxxy::  (where x denotes carving part from /48 to /60 – the EA bits; ‘y’ denotes further subneting that is done on the CPE -> y=0 for MAP prefix, the remaining combinations are reserved for CPE delegation to its clients)
>> 
>> 3)      2001:db8:020w:xxxy::  (where x and two lower bits of ‘w’ denote carving part from /46 to /60 – the EA bits; ‘y’ denotes further subneting that is done on the CPE -> y=0 for MAP prefix, the remaining combinations are reserved for CPE delegation to its clients)
>> 
>>  
>> 
>> Similarly for case 3), we can create 3 more IPv6 rule prefixes (and add 3 more /22 IPv4 subnets) by changing bits between /46 and /48. This would allow us to expand the coverage for residual IPs (although the purpose of NAT is to minimize their use over time not to expand J).
>> 
>  
> >> co-authors: we may compose the 5.1 again based on Kristian's proposed example and includes the #1 ~ #3 above and submit for wg review. agree?
>  
> - maoke
>  
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>>