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; #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 protected] > https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
