[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
- Re: [Softwires] MAP-E/T overlaping ranges and dom… Senthil Sivakumar (ssenthil)
- [Softwires] MAP-E/T overlaping ranges and domains Poscic, Kristian (Kristian)
- Re: [Softwires] MAP-E/T overlaping ranges and dom… Poscic, Kristian (Kristian)
- Re: [Softwires] MAP-E/T overlaping ranges and dom… Maoke
- Re: [Softwires] MAP-E/T overlaping ranges and dom… Senthil Sivakumar (ssenthil)
- Re: [Softwires] MAP-E/T overlaping ranges and dom… Poscic, Kristian (Kristian)
- Re: [Softwires] MAP-E/T overlaping ranges and dom… Maoke
- Re: [Softwires] MAP-E/T overlaping ranges and dom… Senthil Sivakumar (ssenthil)
- Re: [Softwires] MAP-E/T overlaping ranges and dom… Maoke
- [Softwires] 答复: MAP-E/T overlaping ranges and dom… wang.cui1