idnits 2.17.1 draft-wu-netext-pmipv6-ipv4-ro-ps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC5213], [ID-PMIP6-RO-PS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 23, 2009) is 5392 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ID-DSMIP6' is mentioned on line 204, but not defined == Unused Reference: 'RFC3775' is defined on line 282, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-liebsch-netext-pmip6-ro-ps-00 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-12 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Q.Wu 3 Internet Draft Huawei 4 J.Korhonen 5 Nokia Siemens Network 6 Intended status: Informational June 23, 2009 7 Expires: December 2009 9 Problem Statement of IPv4 Support for PMIPv6 Localized Routing 10 draft-wu-netext-pmipv6-ipv4-ro-ps-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on December 23, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 [ID-PMIP6-RO-PS] describes the problem space of localized routing 48 which allows end-to-end user traffic forwarding between MN and CN 49 directly without involving Local Mobility Anchor (LMA) in a single 50 Proxy Mobile IPv6 [RFC5213] domain. However, localized routing with 51 IPv4 support which allows IPv4 transport between MAG and LMA and/or 52 IPv4 enabled user traffic between MN and CN is not considered. This 53 document details the scenarios and problem statement for localized 54 routing with IPv4 support. 56 Table of Contents 58 1. Introduction.................................................3 59 2. Conventions used in this document............................3 60 3. Scenarios and Problem Statement..............................4 61 4. Security Considerations......................................7 62 5. References...................................................7 63 5.1. Normative References....................................7 64 5.2. Informative References..................................8 65 6. Acknowledgments..............................................8 67 1. Introduction 69 In Proxy Mobile IPv6 [RFC5213], Local Mobility Anchor (LMA) is 70 responsible for forwarding the user traffic from the correspondent 71 node to the current location of registered mobile nodes. To reduce 72 latency and backhaul load, optimized routing path without involving 73 LMA in path is expected. [ID-PMIP6-RO-PS] has outlined some possible 74 problems during setting up an optimized routing path between MN and 75 CN which requires that MN and CN are connected to same PMIP domain. 76 However, the scenarios and problems for the IPv4 support of PMIP6 77 localized routing [ID-PMIP6-IPv4] are not specified. 79 As [ID-PMIP6-IPv4] described, PMIPv6 with IPv4 support contains two 80 basic features: IPv4 transport support and IPv4 HoA support. This 81 document details these scenarios and describes its relevant problems 82 during setting up an optimized routing path. In these IPv4 support 83 localized routing scenarios, it allows a MN and a CN subscription 84 belong to different operators. 86 2. Conventions used in this document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 This document uses the terminology of [RFC5213]. The following terms 93 are used in the context of this problem statement: 95 o Routing Optimization (RO): referred as the functionality that 96 makes end-to-end user traffic between the MN and the CN go through 97 an optimized routing path in the same PMIPv6 domain. 99 o Routing Optimization Path (ROP): the direct MAG-to-MAG path for a 100 user traffic between the MAG the MN is attached to and the MAG the 101 CN is attached to. 103 o Routing Optimization States (ROS): referred as RO information that 104 is generally stored in the corresponding LMA(s) and MAG(s). Such 105 information includes RO policies and tunnel ID of ROP, etc. 107 o Routing Optimization Control (ROC): the ROP setting up and the ROS 108 management done by the PMIPv6 network entities participating to 109 the RO. 111 3. Scenarios and Problem Statement 113 Fig.1 shows a generic IPv4 support architecture. In this architecture, 114 the end-to-end user traffic routing is allowed between MN and CN (CN1, 115 CN2 or CN3). To make the description simple, we have the following 116 general assumptions to this architecture. 118 - LMA1 and LMA2 which MN and CN are respectively anchored to may be 119 the same LMA or different LMA in the same PMIPv6 domain. 121 - With IPv4 user traffic support, MN and CN both are IPv4-only 122 enabled nodes or dual stack nodes. 124 - With IPv4 transport support, we assume IPv4 network is deployed 125 between LMA1 and MAG1. However, the transport network between LMA2 126 and MAG2, MAG1 and MAG2 is not limited to IPv4 network. 128 +---------+ 129 ============|LMA1/LMA2|============ 130 // +---------+ \\ 131 || || 132 +-----+ || 133 | NAT | +-----------+ 134 +--+-----+--+ | IPv4/IPv6 | 135 | IPv4 | | Network | 136 | Network | +-----------+ 137 +-----------+ || 138 || || 139 || +-----------+ || 140 +------+ |IPv4/IPv6 +---+ +------+ 141 | MAG1 |===================|NAT|=====| MAG2 | 142 +------+ | Network +---+ +------+ 143 | | +-----------+ | | 144 +-----+ +-----+ +-----+ +-----+ 145 | | | | 146 +----+ +-----+ +-----+ +-----+ 147 | MN | | CN1 | | CN2 | | CN3 | 148 +----+ +-----+ +-----+ +-----+ 150 {IPv4-MN-HoA1} {IPv4-CN1-HoA2} {IPv4-CN2-HoA3} {IPv6-CN3-HoA4} 151 {IPv6-MN-HoA1} {IPv6-CN2-HoA3} 153 Fig.1 IPv4 support architecture 155 Based on the assumption mentioned above, we have the following three 156 use cases on IPv4 support for PMIPv6 localized routing. 158 Case 1: Both MN and CN attached MAGs are using IPv4 transport 160 In this case, the PMIPv6 signaling between MAGs and LMAs for MN and 161 CN is carried over IPv4 network. The end-to-end user traffic between 162 MN and CN can be IPv4 or IPv6 application. With IPv4 transport 163 support, the NAT may exist between MAG1 and MAG2 or between the LMA1 164 and LMA2. 166 Case 2: MN and CN attached MAGs are using IPv4 transport and IPv6 167 transport respectively 169 In this case, the PMIPv6 signaling between MAG1 and LMA1 for MN is 170 carried over IPv4 network while the PMIP6 signaling between MAG2 and 171 LMA2 for CN is carried over IPv6 network. The end-to-end user traffic 172 between MN and CN can be IPv4 or IPv6 application. With the IPv4 173 transport support, the NAT may exist between MAG1 and MAG2 or between 174 the LMA1 and LMA2. 176 Case 3: Both MN and CN are IPv4 enabled nodes 178 In this case, MN is using IPv4 address to communicate with CN through 179 the direct path between the MN and CN's MAGs located in the same 180 PMIP6 domain. The end-to-end user traffic between MN and CN belongs 181 to the IPv4 application. Furthermore, MN and CN may be attached to 182 the same or different MAGs. MN and CN attached MAGs communicate with 183 the LMAs using IPv6 transport. 185 Case 4: Roaming user MN and non-roaming user CN subscription belong 186 to different Operators 187 In this case, Roaming user MN moves to the visited network owned by 188 the operator using IPv4 transport where no-roaming CN is located. MN 189 and CN are under the same PMIP6 domain. However, MN and CN 190 subscription belong to the different operators. 192 Case 5: Both MN and CN are "roaming" and using visited network LMAs 193 In this case, both MN and CN moves to the same visited network owned 194 by the operator using IPv4 transport. MN and CN are roaming users and 195 both using visited network LMAs. However MN and CN subscription 196 belong to the different operators. 198 On the basis of the above use cases, we have several problems of IPv4 199 Support for PMIPv6 localized routing to be considered below. 201 o P1: NAT Detection 202 For IPv4 transport support, when the IPv4 network is deployed between 203 both MAG(s) in an optimized routing path, NAT [RFC3022] device may be 204 located. In general, [ID-DSMIP6] for detecting the on-path NAT device 205 may be applicable for ROP setup. However, if there existing NAT 206 between the MAGs associated with the MN and CN and the MAG is not 207 aware of it, the NAT may automatically drop the user traffic between 208 the MN and CN and prevent setting up localized routing path. 210 o P2: Encapsulation Mode Negotiation 212 There may be some situations where MN communicates with CN using the 213 direct path between the MAGs to which both MN and CN attached and 214 such MAGs support different tunnel encapsulation or transport (e.g., 215 IPv4 over IPv6 transport, IPv6 over IPv4 transport, IPv6 over IPv4 216 UDP). In such cases, there may be various encapsulation modes existed 217 between MAG1 and MAG2 for choice. Therefore, it is expected to 218 negotiate and determine the appropriate encapsulation mode for end- 219 to-end user traffic routing between MN and CN during ROC processing. 221 o P3: IPv4 address space overlapping 223 There may be some situations where mobile nodes from different 224 operators may be assigned the same IPv4 HoA from overlapping private 225 address space. In PMIPv6 domain, the MAG and the LMA can distinguish 226 each mobile node flow based on the GRE key encapsulated within the 227 tunneled packet [ID-PMIP-GREKEY], even though two mobile nodes are 228 assigned the same IPv4 HoA. However, when the traffic destined for 229 the CNs with same HoA does not pass through the tunnel between the 230 MAG and the LMA and go directly to the path between the MAGs 231 associated with MN and CN, the MAG attached by the CN can not 232 identify the right CN based on the overlapped IPv4 HoA in the 233 destination field of the incoming packet, therefore can not forward 234 the user traffic to the right CN. 236 o P4: IP Protocol Version Transition 237 There may be some situations where the IPv4 network is deployed 238 between both MAG(s) in an optimized routing path and the IPv6 network 239 is deployed between the MAG and the LMA, in such cases, once the 240 local routing is allowed between both MAG(s) and the traffic from the 241 MN or CN does not pass through the LMA and is sent directly to the 242 corresponding MAG, the dual stack MAG needs to transit from the IPv6 243 transport version to the IPv4 transport version ,e.g., change the 244 destination address of the packet from IPv6-Proxy-CoA to IPv4-Proxy- 245 CoA. This change should be considered during ROC processing. 247 o P5: ROS Maintaining 249 For IPv4 support, the ROS should include the additional source/ 250 destination IPv4 address or the transport IPv4 address (e.g. IPv4- 251 Proxy-CoA), etc. Further more, RO policy (e.g. whether per-MN based 252 RO is enabled or disabled) may be downloaded from AAA as an attribute 253 of ROS and maintained locally in the ROS. 255 4. Security Considerations 257 The scenarios and problems specified in this document can use the 258 security association between the LMA and the MAG to create security 259 association between MAGs associated with the MN and CN in the 260 communication. 262 5. References 264 5.1. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 270 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 272 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 273 Address Translator (Traditional NAT)", RFC 3022, January 274 2001. 276 [ID-PMIP6-RO-PS] Liebsch, M., "PMIPv6 Localized Routing Problem 277 Statement", draft-liebsch-netext-pmip6-ro-ps-00, February 278 2009. 280 5.2. Informative References 282 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 283 in IPv6", RFC 3775, June 2004. 285 [ID-PMIP6-IPv4] Wakikawa, R. and S.Gundavelli, "IPv4 Support for 286 Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12 287 (work in progress), April 2009. 289 [ID-PMIP-GREKEY] Muhanna, A., Khalil, M., S.Gundavelli and K. Leung, 290 "GRE Key Option for Proxy Mobile IPv6", draft-ietf-netlmm- 291 grekey-option-09, May 2009 293 6. Acknowledgments 295 Many thanks to NetExt members for their comments. 297 Authors' Addresses 299 Qin Wu 300 Huawei Technologies Co.,Ltd. 301 Floor 10, HuiHong Mansion, No.91 BaiXia Rd. 302 Nanjing, Jiangsu, 210001 303 P.R.China 305 Email: sunseawq@huawei.com 307 Jouni Korhonen 308 Nokia Siemens Network 309 Linnoitustie 6 310 Espoo FI-02600 311 Finland 313 Email: jouni.nospam@gmail.com 315 Yungui Wang 316 Huawei Technologies Co.,Ltd. 317 Floor 10, HuiHong Mansion, No.91 BaiXia Rd. 318 Nanjing, Jiangsu, 210001 319 P.R.China 321 Email: w52006@huawei.com