2012/12/13 Senthil Sivakumar (ssenthil) <[email protected]> > > Please see [Senthil3] > From: Maoke <[email protected]> > Date: Tuesday, December 11, 2012 8:24 PM > > To: Senthil Sivakumar <[email protected]> > Cc: "Poscic, Kristian (Kristian)" <[email protected]>, " > [email protected]" <[email protected]> > Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains > > hi Senthil, > > inline for maoke2 > > 2012/12/12 Senthil Sivakumar (ssenthil) <[email protected]> > >> Hi Maoke, >> Please see inline for Senthil2 >> >> From: Maoke <[email protected]> >> Date: Tuesday, December 11, 2012 5:21 AM >> To: Senthil Sivakumar <[email protected]> >> Cc: "Poscic, Kristian (Kristian)" <[email protected]>, " >> [email protected]" <[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]> >> >>> >>> >>> 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!). >> >> [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. >> > > [maoke2] i cannot catch your point. you mean v4->v6 at BR, right? which > IPv4 address to embed is determined by the session initiator. for example, > if a host behind CE makes a connection to 8.8.8.8, and if the CE happens to > have picking up 192.0.2.191 as the src IPv4 address, then the 8.8.8.8 will > response 192.0.2.191 definitely. i don't see that BR needs to choose an > IPv4 address to embed: the destination address in the packet replying to > the session initiator is determined. > > >> >> 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. >> > > [maoke2] misunderstanding. BR don't have the chance to *pick up* IPv4 > address. > > [Senthil3] You are right, I missed that. But lets take your example: > 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 > > CE1 sends the packet with its prefix and using the global address > 192.0.2.20 sends a packet to the BR. The BR matches rule 1 (assuming that > the longest matching prefix was that), and the resulting packet is a ipv4 > packet with a destination of 192.0.2.20 and the return packet comes back > with the destination of 192.0.2.20. That will match the rule2 because the > longest prefix match for the v4 address is 192.0.2.0/26. So we use rule2 > to construct the v6 packet. The destination v6 address is different now, > even though you embedded the right v4 address in IID. How does that reach > the CE-1? >
[maoke3] we are on the same floor that rule IPv4 prefix MUST NOT overlap among different CEs. but multiple rules can share the same rule IPv6 prefix (as long as the rule IPv4 prefixes are not overlapped). > > > >> >> >> 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. >> >> [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. >> > > [maoke2] agree that it is bad if we have waste. > > >> I guess the bigger question why should one have such a design and its >> usefulness. >> > > [maoke2] the bigger question is not only about the significance of > allowing it but also about the significance of forbidding it, and about > what if it happens even we have tried to forbid it. i surely don't > encourage any waste but try to understand what we might have if we don't > forbid it -- in order to make a proper statement in the specification. > > >> 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 >> >> [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. >> > > [maoke2] if all controlled by one party, it is true there is no obvious > advantage at current understanding. however, what if two rule IPv6 prefixes > are the reality, out of our control? ;-) > > [Senthil3] Do you see a use case or a scenario that is happening, that > we would end up with multiple IPv6 rule prefixes and ipv4 rule prefixes? > [maoke3] as the above, it is possible that two or more parties are deploying MAP domains on some common CEs, if the MAP domain != AS is allowed. to clarify: with multiple rules where rule IPv6 prefixes can be shared / overlapped but rule IPv4 prefixes must not. thanks, - maoke > > Thanks > Senthil > > > >> 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. >> > > [maoke2] rule IPv4 prefix overlapping is another question. and i tried to > show it is really harmful. in practice, it is understood that aggregateable > IPv4 prefixes' corresponding IPv6 prefixes MUST be aggregated in the same > way. > > >> >> 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. >> >> [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. >> > > [maoke2] when we deploy a MAP domain, it is definitely not necessary to > make complicated scenarios. however, it is possible happen in reality: as > prefix delegation is independent of the MAP deployment, it is possible that > two MAP domains deployed so that a CE possibly joins both. i also highlight > the use-case that MAP domain can be deployed across ASes, where the > delegated prefix is not controlled by the party deploying MAP and surely > the party cannot make sure if this pd is also used by another MAP > deployment party or not. > > [maoke2] i have not yet concluded that the above scenario makes sense or > not. however, your thread raises very important questions related to such a > scenario and therefore we need to understand/clarify what does make sense > what really doesn't. > > >> 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, > maoke > > >> >> 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] >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
