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

wang.cui1@zte.com.cn Thu, 27 December 2012 09:29 UTC

Return-Path: <wang.cui1@zte.com.cn>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA12D21F8414 for <softwires@ietfa.amsl.com>; Thu, 27 Dec 2012 01:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -90.491
X-Spam-Level:
X-Spam-Status: No, score=-90.491 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2LtD4GOk57G for <softwires@ietfa.amsl.com>; Thu, 27 Dec 2012 01:29:44 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3C23021F8319 for <softwires@ietf.org>; Thu, 27 Dec 2012 01:29:42 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4CBAC95EF5 for <softwires@ietf.org>; Thu, 27 Dec 2012 17:29:31 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 5BE21716890; Thu, 27 Dec 2012 17:18:59 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qBR9TFcX008033; Thu, 27 Dec 2012 17:29:15 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn)
In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AA2894A@US70UWXCHMBA05.zam.alcatel-lucent.com>
To: "Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com>, Maoke <fibrib@gmail.com>, "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>
MIME-Version: 1.0
X-KeepSent: 3654BA23:2BE26817-48257AE1:0031F105; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF3654BA23.2BE26817-ON48257AE1.0031F105-48257AE1.00341DE3@zte.com.cn>
From: wang.cui1@zte.com.cn
Date: Thu, 27 Dec 2012 17:29:14 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-27 17:29:11, Serialize complete at 2012-12-27 17:29:11
Content-Type: multipart/alternative; boundary="=_alternative 00341DE048257AE1_="
X-MAIL: mse02.zte.com.cn qBR9TFcX008033
Cc: "softwires@ietf.org" <softwires@ietf.org>
Subject: [Softwires] 答复: MAP-E/T overlaping ranges and domains
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Dec 2012 09:29:47 -0000

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:

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
 
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)" <kristian.poscic@alcatel-lucent.com> 
发件人:  softwires-bounces@ietf.org
2012-12-11 04:06

收件人
"softwires@ietf.org" <softwires@ietf.org>
抄送

主题
[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.
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 
 _______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires