hi Senthil, interesting discussion. see inline.
2012/12/11 Senthil Sivakumar (ssenthil) <[email protected]> > > > From: <Poscic>, "Kristian (Kristian)" < > [email protected]> > Date: Monday, December 10, 2012 3:06 PM > To: "[email protected]" <[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**** > > Rule EA-bits length: 12**** > > - (BMR) Rule 2:**** > > Rule IPv6 Prefix: 2001::/40**** > > Rule IPv4 Prefix: 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 range > and for a CE from 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!). 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. 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. 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 (192.0.2.128 - 192.0.2.191) from using. 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, ea-length = 12 Rule 2) rule IPv6 prefix = 2001:0:80::/42, rule IPv4 prefix = 192.0.2.0/26, ea-length = 12 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, 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. 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] > https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
