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 protected]> 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. > 2013/3/16 Poscic, Kristian (Kristian) <[email protected]> >> >> >> 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; 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 >> >> >> >> >> 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 protected] >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
