Subject: [Softwires] MAP-E/T overlaping ranges and domains

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Mon, 10 Dec 2012 20:06:20 +0000

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.
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.

                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).

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.

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.

Thanks,
Kris

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 11 Dec 2012 01:03:03 +0000

From: <Poscic>, "Kristian (Kristian)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, December 10, 2012 3:06 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Softwires] MAP-E/T overlaping ranges and domains

-          (BMR) Rule 1:

Rule EA-bits length:        12

-          (BMR) Rule 2:

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.
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.

                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.

[Senthil] No, atleast in our implementation we have checks to make sure the prefixes don’t overlap.

Thanks
Senthil

Thanks,
Kris

---

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Tue, 11 Dec 2012 05:56:10 +0000

Very helpful. Thanks!

From: Senthil Sivakumar (ssenthil) [mailto:[email-masked]]
Sent: Monday, December 10, 2012 5:03 PM
To: Poscic, Kristian (Kristian); [email-masked]
Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains

-          (BMR) Rule 1:

Rule EA-bits length:        12

-          (BMR) Rule 2:

Rule EA-bits length:        12

[Senthil] No, atleast in our implementation we have checks to make sure the prefixes don't overlap.

Thanks
Senthil

Thanks,
Kris

---

From: Maoke <[email-masked]>
Date: Tue, 11 Dec 2012 19:21:04 +0900

hi Senthil,

interesting discussion. see inline.

2012/12/11 Senthil Sivakumar (ssenthil) <[email-masked]>

>
>
>   From: <Poscic>, "Kristian (Kristian)" <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>
>   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

> ****
> ** **
> Thanks,****
> Kris ****
> ** **
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 11 Dec 2012 19:33:33 +0000

Hi Maoke,
Please see inline for Senthil2

From: Maoke <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 11, 2012 5:21 AM
To: Senthil Sivakumar <[email-masked]<mailto:[email-masked]>>
Cc: "Poscic, Kristian (Kristian)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains

hi Senthil,

2012/12/11 Senthil Sivakumar (ssenthil) <[email-masked]<mailto:[email-masked]>>

-          (BMR) Rule 1:

Rule IPv4 Prefix:               192.0.2.0/24<http://192.0.2.0/24>

Rule EA-bits length:        12

-          (BMR) Rule 2:

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.

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'.

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

- maoke

Thanks
Senthil

Thanks,
Kris

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Tue, 11 Dec 2012 23:04:55 +0000

For the first case where we would allow multiple Rule IPv4 prefixes per single Rule IPv6 prefix, I agree that downstream lookup would be problematic.
But don't we even have a problem even before we get to that point...The whole scenario presuppose that the two (or more) CEs would need the same delegated IPv6 prefix - this process can be independent of MAP and the IA-PD is assigned for example via DHCP server  (plain IPv6 address assignment).
It is simply not doable that a DHCP server hands out the same DHCP leases to two different clients. It seemed to me that this was not that big of a deal in this discussion and I just wanted to make sure I'm not missing anything.

For the overlapping cases I think as long as the bits from the shortest Rule IPv6 prefix length all the way to the PD length are unique, things should work but carving out non-overlapping subnets,ports  may be bigger trouble for the operators than not .

why /56 instead of /52? :P     => yes I agree it would be less wasteful.

Kris

From: Senthil Sivakumar (ssenthil) [mailto:[email-masked]]
Sent: Tuesday, December 11, 2012 11:34 AM
To: Maoke
Cc: Poscic, Kristian (Kristian); [email-masked]
Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains

Hi Maoke,

hi Senthil,

---

From: Maoke <[email-masked]>
Date: Wed, 12 Dec 2012 10:24:23 +0900

hi Senthil,

inline for maoke2

2012/12/12 Senthil Sivakumar (ssenthil) <[email-masked]>

>   From: Maoke <[email-masked]>
> To: Senthil Sivakumar <[email-masked]>
> Cc: "Poscic, Kristian (Kristian)" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> 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
>    [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.

>  [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

[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.

>  [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? ;-)

> 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.

>  [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

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Wed, 12 Dec 2012 18:45:43 +0000

Please see [Senthil3]
Date: Tuesday, December 11, 2012 8:24 PM

hi Senthil,

inline for maoke2

2012/12/12 Senthil Sivakumar (ssenthil) <[email-masked]<mailto:[email-masked]>>
Hi Maoke,
Please see inline for Senthil2

hi Senthil,

-          (BMR) Rule 1:

Rule EA-bits length:        12

-          (BMR) Rule 2:

Rule EA-bits length:        12

[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.

[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<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

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?

[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.

[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?

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.

[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.

thanks,
maoke

Thanks
Senthil

- maoke

Thanks
Senthil

Thanks,
Kris

---

From: Maoke <[email-masked]>
Date: Thu, 13 Dec 2012 10:49:08 +0900

2012/12/13 Senthil Sivakumar (ssenthil) <[email-masked]>

>  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).

> [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.
>
>
>> Rule 2) rule IPv6 prefix = 2001:0:80::/42, rule IPv4 prefix =
>> 192.0.2.0/26, ea-length = 12
>>
>  [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.
>>
>
>>  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

---

From: [email-masked]
Date: Thu, 27 Dec 2012 17:29:14 +0800

hi Sentihil and Maoke,
  Things come a little confused, let us come to the first email Kris had 
sent and I cut some discussion from before emails:

Discussion from before emails:
  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. 

[Linda]: I think Maoke is right, BR needn't to choose an IPv4 address to 
embed because the IPv4 address is already in the inbound packet's 
destination address field. 
BUT when the encapsulated V6 packet arrived at CE, CE de-capsulated the V6 
packet and then check the NAT binding table according to the V4 
destination address 192.0.2.191, then translated 192.0.2.191 to 
corresponding V4 address of the host behind this CE+Port, and then forward 
the V4 packet to the corresponding application at the host. I can't find 
any issues at CE. Am i missunderstanding ?

And because there were two V4 address block at this CE, if one V4 address 
block had no V4 address to allocate for new sessions, then CE could use 
another V4 address block to create new sessions.
So I think if a MAP domain supports several BMRs with same Ruled IPv6 
prefix and different Ruled IPv4 prefix is OK.  If I misunderstand please 
point out without hestitant. 

Thanks.
Linda

"Poscic, Kristian (Kristian)" <[email-masked]> 
发件人:  [email-masked]
2012-12-11 04:06

收件人
"[email-masked]" <[email-masked]>
抄送

主题
[Softwires] MAP-E/T overlaping ranges and domains

 
                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.
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.
 
                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).
 
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.
 
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.
 
Thanks,
Kris