Hi Maoke, Please see inline for Senthil2 From: Maoke <[email protected]<mailto:[email protected]>> Date: Tuesday, December 11, 2012 5:21 AM To: Senthil Sivakumar <[email protected]<mailto:[email protected]>> Cc: "Poscic, Kristian (Kristian)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains
hi Senthil, interesting discussion. see inline. 2012/12/11 Senthil Sivakumar (ssenthil) <[email protected]<mailto:[email protected]>> From: <Poscic>, "Kristian (Kristian)" <[email protected]<mailto:[email protected]>> Date: Monday, December 10, 2012 3:06 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [Softwires] MAP-E/T overlaping ranges and domains Can someone clarify a few things for me: 1) Does MAP support this scenario (example): - (BMR) Rule 1: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 192.0.2.0/24<http://192.0.2.0/24> Rule EA-bits length: 12 - (BMR) Rule 2: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 200.0.2.0/24<http://200.0.2.0/24> Rule EA-bits length: 12 The only difference between these two rules above is the ‘Rule IPv4 Prefix’, everything else is the same. My obvious answer would be that this scenario is not supported but wanted to be sure that I’m not missing anything. This scenario above would result in ambiguity between CEs, i.e. a single IA-PD that is delegated to a CE can be associated with either of the two rules above (EA bits can be the same for a CE from 192.0.2.0/24<http://192.0.2.0/24> range and for a CE from 200.0.2.0/24<http://200.0.2.0/24> range. what is the consequence if the CE has the two rules? NOTE the delegation is independent of the IPv4 address in use. for example, we have 2001:0:00xx:y000::/52 for the CE, where xx (8 bits) is the same as the IPv4 suffix while y (4 bits) is applied for the PSID. if the source address has been selected from either rule ipv4 prefix, then the encapsulation or translation is determined and the BR can de-capsulate or de-translate that without any difficulty because the full IPv4 address is embedded in the IID part. when the response comes, the destination address of the IPv4 packet is also determined though they would be encapsulated with the same IPv6 prefix (not the same IPv6 CE address!). [Senthil2] I don’t see any issues with correctly decapsulating/translating the packet on the BR for v6->v4. The issue is with the v4->v6. You cannot correctly know which of the two IP addresses to embed. With translation, the communication will definitely fail if you embed the wrong IP address. the only concern is: if such a configuration can make different source IPv4 address for the packets of the same session. if so, the session might be troubled especially it is connection-oriented. [Senthil2] It will. There is a 50% chance that you don’t use the same address as the one the that the client used. Because there is no state. however, we may notice that NAT44 in the CE is not stateless. what is selected for the session initialization would be continuously used for the subsequent process of the same session. if the address is not shared so that there is no NAT44, the native IPv4 source address selection logic will decide the selection and makes it unique for a specific destination. [Senthil2] With NAT44, it is even more stricter, if the BR didn’t pick the right IPv4 address the NAT44 state table wont match the incoming packet. therefore personally i doubt the above multi-rule case doesn't work. if i am right, it is not needed to make 'Rule IPv4 Prefix' unique per 'Rule IPv6 Prefix'. In this example above, it is assumed that the delegated prefix (IA-PD) that DHCPv6 Server is handing out to CEs is 2001::/40 with delegated prefix length /56. why /56 instead of /52? :P This makes me believe that each rule must not only be unique (because the above two rules are unique) but instead each rule must have a unique ‘Rule IPv6 prefix’ and a unique ‘Rule IPv4 Prefix’ per ‘Rule IPv6 prefix’ (IPv4 uniqueness is important in the downstream direction where lookup is performed based on IPv4). [Senthil] Right. The rules must not be overlapping with one another. Each domain can have a single IPv6 & single IPv4 rule prefix only. The ipv6 and ipv4 rule prefix should not overlap with other ipv6 and ipv4 rules prefixes respectively in other domains. 2) What constitutes a MAP domain? I’d think a unique ‘Rule IPv6 Prefix’ which (assuming that 1) is correct) would mean that a Domain = BMR. In other words, can a MAP domain contain a collection of BMRs? The drafts mention virtual-links, etc…but it would be simpler if we can say Domain=BMR (not sure if this is accurate though). Of course, nodes sharing the same set of those rules would be in the same MAP domain. [Senthil] Each MAP domain should have a single rule IPv6 prefix and single IPv4 prefix. I think a single IPv4 prefix may be too restrictive in some deployments and people might want to use more than one prefix. But as you have shown EA length can cause ambiguity and hence makes it undeployable. 3) Is overlapping of ‘Rule IPv6 Prefixes’ supported? For example in the above case, can we have for Rule 2) the ‘Rule IPv6 prefix’ as 2001:0:80::/42. In this case the ‘Rule IPv6 Prefix’ from Rule 1 overlaps with ‘Rule IPv6 Prefix’ from Rule 2. I assume that this would not be supported for the same reason as in 1). I didn’t think about the applicability of this scenario for now, it is more of a theoretical question. again, let's observe the consequence. again, we have the independently delegated prefix for the CE. if the CE has the pd like 2001:0:81:6000::/54, it matches both rules surely. longest-match can determine which rule is in use (though not yet specified?). however, such a way may cause a subset of IPv4 residual addresses never used (i.e., wasted). in this example, the longest match to 2001:0:80::/42 may block 192.0.2.128/26<http://192.0.2.128/26> (192.0.2.128 - 192.0.2.191) from using. [Senthil2] That is a bad thing if you have to waste any of the addresses, as that is what we are trying to conserve here. And all this pain of sharing addresses is defeated. I guess the bigger question why should one have such a design and its usefulness. the really problematic stuff is both rule IPv4 prefixes and rule IPv6 prefixes are overlapped among two rules but not aggregated. Rule 1) rule IPv6 prefix = 2001::/40, rule IPv4 prefix = 192.0.2.0/24<http://192.0.2.0/24>, ea-length = 12 Rule 2) rule IPv6 prefix = 2001:0:80::/42, rule IPv4 prefix = 192.0.2.0/26<http://192.0.2.0/26>, ea-length = 12 [Senthil2] Well, I think you are trying to prove that one can have two rule IPv6 prefixes but as long as the ipv4 addresses don’t overlap then we will be able to unambiguosly encap/decap/translate the packets. But I wonder what is the advantage of having two rule IPv6 prefixes. In the above case, the /26 is a subset of /24, so really there is no real advantage of having a separate rule ipv4 prefix. and one CE-a has delegated prefix 2001:0:3f:5000::/52, while another CE-b has 2001:0:bf:5000::/54. such a delegation seems no problem at all. CE-a matches Rule 1 while CE-b matches Rule 2. then the trouble happens: CE-a will use the IPv4 address 192.0.2.63 with PSID = binary_0101, obviously; while CE-b have 40-55bits = 0x8fd4 = binary_1011 1111 0101 0000 then EA-bits = binary_11 1111 0101 00 then IPv4 suffix = binary_11 1111, PSID = binary_0101 00 when attached to 192.0.2.0/26<http://192.0.2.0/26>, it will be 192.0.2.63 with PSID = binary_0101 00 i.e., CE-b's usable port-range is overlapped with CE-a on the same IPv4 address! therefore, IMHO, the constraint of BMR-making MUST ensure the (IPv4 address, port-range)-pair is not overlapped among different CE, therefore Rule IPv4 Prefixes cannot be overlapped among BMRs. this is necessary and sufficient. [Senthil2] I agree with your example and assertion above. But I really don’t see a good use case for having multiple rule IPv6 prefixes and overlapping rule IPv4 prefixes. Maybe the use case for a overlapping rule IPv4 case is more compelling, as you can get two blocks of public addresses that overlap on the lower n bits, where the n bits are not unique enough in the EA bits to identify which rule IPv4 address to chose (mostly an issue for BR in the v4->v6 direction). Thanks Senthil if i made mistakes, please point out without hesitation. thanks a lot! - maoke [Senthil] No, atleast in our implementation we have checks to make sure the prefixes don’t overlap. Thanks Senthil Thanks, Kris _______________________________________________ Softwires mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
