idnits 2.17.1 draft-liebsch-netext-pmip6-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.) 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 (July 13, 2009) is 5401 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-13 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Liebsch 3 Internet-Draft NEC 4 Intended status: Informational S. Jeong 5 Expires: January 14, 2010 ETRI 6 Q. Wu 7 Huawei 8 July 13, 2009 10 PMIPv6 Localized Routing Problem Statement 11 draft-liebsch-netext-pmip6-ro-ps-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 14, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Proxy Mobile IPv6 is the IETF standard for network-based localized 50 mobility management. In Proxy Mobile IPv6, mobile nodes are 51 topologically anchored at a Local Mobility Anchor, which forwards all 52 data for registered mobile nodes. The set up and maintenance of 53 localized routing, which allows forwarding of data packets between 54 mobile nodes and correspondent nodes directly without involvement of 55 the Local Mobility Anchor in forwarding, is not considered. This 56 document describes the problem space of localized routing in Proxy 57 Mobile IPv6. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 63 3. Problem Statement for Localized Routing in PMIPv6 . . . . . . 5 64 4. IPv4 Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. Localized Routing between IPv4 Home Addresses . . . . . . 9 66 4.2. IPv4 Transport Network Considerations . . . . . . . . . . 9 67 4.3. NAT Presence Issues . . . . . . . . . . . . . . . . . . . 10 68 4.4. IPv4 Address Space Overlapping Issues . . . . . . . . . . 10 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Appendix A. Change Notes . . . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the 80 base protocol for network-based localized mobility management 81 (NetLMM), which takes basic operation for registration, de- 82 registration and handover into account. In scope of the base 83 protocol is the set up and maintenance of a forwarding tunnel between 84 an MN's Mobility Access Gateway (MAG) and its selected Local Mobility 85 Anchor (LMA). Data packets will always traverse the MN's MAG and its 86 LMA, irrespective of the location of the MN's remote communication 87 endpoint. Even though two communicating MNs might be attached to the 88 same MAG or to different MAGs of the same local mobility domain, 89 packets will traverse the MNs' LMA(s). 91 Objectives of designing a solution for localized routing in PMIPv6 92 are to specify protocol messages and enable associated protocol 93 operation between PMIPv6 components to support the set up of a direct 94 routing path for data packets between the MNs' MAGs without 95 forwarding these packets through the MNs' LMA(s) and to maintain 96 localized routing in case one or both MNs handover to a different 97 MAG. Relevant protocol interfaces may include the interface between 98 associated MAGs, between a MAG and an LMA as well as between LMAs. 100 This document analyzes and discusses the problem space of using 101 always the default route through two communicating mobile nodes' 102 local mobility anchors. Furthermore, the problem space of enabling 103 localized routing in PMIPv6 is analyzed and described, while 104 different communication and mobility scenarios are taken into 105 account. 107 2. Conventions and Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 This document uses the terminology of [RFC5213]. The following terms 114 are used in the context of this problem statement: 116 o Mobile Node (MN): Mobile Node without IP mobility support, which 117 is attached to a Mobility Access Gateway (MAG) and registered with 118 a Local Mobility Anchor (LMA) according to the PMIPv6 119 specification [RFC5213]. 121 o Correspondent Node (CN): Correspondent Node with or without IP 122 mobility support. The CN represents the communication peer of an 123 MN, which is attached to a MAG and registered with an LMA 124 according to the PMIPv6 specification. 126 o Localized Routing: Result of signaling to set up routing states on 127 relevant network entities to allow forwarding of data packets 128 between an MN and a CN within a single PMIPv6 domain without 129 intervention of the MN's LMA and the CN's LMA in data forwarding. 131 o Localized Routing States: Information for localized routing on 132 relevant forwarding entities on the direct data path between an MN 133 and a CN. Such information includes route entries and may include 134 further information about the MN and the CN, such as IDs. 136 3. Problem Statement for Localized Routing in PMIPv6 138 The Mobile IPv6 (MIPv6) protocol [RFC3775] has built-in mechanisms 139 for direct communication between a MN and a CN. Mechanisms for route 140 optimization in MIPv6 cannot be directly applied in PMIPv6, as MNs do 141 not take part in mobility management and associated signaling. 142 Following the architecture of PMIPv6, rather entities of the network 143 infrastructure are dedicated to perform signaling to set up a more 144 direct route between an MN and a CN. In case of communication 145 between two nodes, which are attached to the PMIPv6 network 146 infrastructure and each node is registered with an LMA, data packets 147 between these two nodes will always traverse the responsible LMA(s). 148 At least some deployment would benefit from having such communication 149 localized, rather than traverse the core network to the LMA(s). In 150 the context of this document, such localized communication comprises 151 offloading traffic from LMAs and establish a direct forwarding path 152 between the two communication endpoints. 154 Localized routing is understood in [RFC5213] as optimization of 155 traffic between a MN and a CN under the same access router, whereas 156 the MN connects to the MAG function of this access router and is 157 registered with an LMA, but the CN is a regular IPv6 node without 158 getting PMIPv6 service. In such case, the MAG forwards traffic 159 directly between the MN and the CN, assuming the MAG is enabled to 160 support this feature (setting of the EnableMAGLocalRouting flag on 161 the MAG) and the MN's LMA enforces this optimization. [RFC5213] does 162 not specify how an LMA can enforce optimization for such local 163 communication. Maintaining local forwarding between the MN and the 164 regular IPv6 CN gets more complex in case the MN performs a handover 165 to a different MAG. Such use case is not considered in the 166 specification and out of scope of this problem statement. This 167 document focuses on use cases, where both nodes, the MN and the CN, 168 are each registered with an LMA and both obtain PMIPv6 mobility 169 service. 171 Localized routing is crucial at least for the following two reasons: 172 First, by limiting the communication to the access nodes, the data 173 traffic traversing the MAG - LMA path (network) can be reduced. This 174 is significant considering that the transport network between the 175 access and the core is often the bottleneck in terms of costs and 176 performance. And there are performance benefits in terms of delay 177 and packet loss, especially when the MNs are attached to the same MAG 178 and the LMA is topologically far away from that MAG. Even when the 179 MNs are attached to different MAGs, there could be benefit in 180 limiting the communication to the access network only, rather than 181 traversing the transport network to the LMA. Hence, providing the 182 necessary protocol specification to enable localized routing in 183 PMIPv6 is necessary. 185 Several tasks need to be performed by the network infrastructure 186 components before relevant information for such direct communication 187 is discovered and associated states for localized routing can be set 188 up. The following list summarizes some key functions, which need to 189 be performed by the PMIPv6 enabled network infrastructure to 190 substitute mobile nodes in setting up a direct route. 192 o Detection of the possibility to perform localized routing. This 193 function includes looking at data packets' source and destination 194 address. 196 o Initiation of a procedure, which sets up a localized routing path. 198 o Discovery of stateful entities (i.e. the LMA(s) and/or the 199 MAG(s)), which maintain and can provide relevant information 200 needed to set up a localized routing path. Such information may 201 include the routable address of an LMA or MAG, where one or both 202 mobile nodes are connected to and registered with. 204 o Control in setting up and maintaining (e.g. during handover) the 205 localized routing path. Control is also needed to terminate the 206 use of a localized routing path and to delete associated states, 207 whereas a trigger for the termination may come from a non-PMIPv6 208 related component. 210 This problem statement focuses on local communication between PMIPv6 211 managed nodes within a single PMIPv6 domain. The following list 212 analyzes different use cases, which are limited to the communication 213 within a single PMIPv6 domain, but they consider the existence of 214 multiple LMAs. Figure 1 depicts the network of a PMIPv6 domain with 215 two mobility anchors. 217 Internet Backbone 218 : : 219 +------------------+ 220 | | . . . . . . 221 +----+ +----+ ^ 222 |LMA1| |LMA2| | 223 +----+ +----+ | 224 | | | 225 | | |PMIPv6 226 +----+------------------+-+ |domain 227 | | | 228 +----+ +----+ | 229 |MAG1| |MAG2| v 230 +----+ +----+ . . . . 231 : : : 232 +---+ +---+ +---+ 233 |MN | |CN1| |CN2| 234 +---+ +---+ +---+ 236 Figure 1: Reference architecture for localized routing in PMIPv6 238 All use cases A assume that both the MN and the CN are registered 239 with an LMA according to the PMIPv6 protocol. Whereas MAG1 is always 240 considered as the MN's current pCoA, the CN can be either connected 241 to the same or a different MAG or LMA as the MN. Accordingly, these 242 topological difference are denoted as follows: 244 A[number of MAGs][number of LMAs] 246 A11: MN and CN (CN1) connect to the same MAG (MAG1) and are 247 registered with the same LMA (LMA). The common MAG may forward 248 data packets between the MN and the CN directly without forwarding 249 any packet to the LMA. 251 A12: MN and CN (CN1) connect to the same MAG (MAG1) and are 252 registered with different LMAs (LMA1 and LMA2) of the same PMIPv6 253 domain. The common MAG may forward data packets between the MN 254 and the CN directly without forwarding any packet to the LMAs. 255 Following the policy of [RFC5213] and enforcement of the set up of 256 a localized forwarding path, potential problems exist in case LMA1 257 and LMA2 differ in their policy to control the MAG. 259 A21: The CN (CN2) connects to a different MAG (MAG2) as the MN 260 (MAG1), but MN and CN are registered with the same LMA (LMA1). 261 The result of localized routing should be the existence of routing 262 information at MAG1 and MAG2, which allows direct forwarding of 263 packets between the MN's MAG1 and the CN's MAG2. As LMA1 is the 264 common anchor for MN and CN and maintains location information for 265 both nodes, no major race condition and instability in updating 266 the states for localized routing is expected. 268 A22: The CN (CN2) connects to a different MAG (MAG2) and a different 269 LMA (LMA2) as the MN (MAG1, LMA1) in the same PMIPv6 domain. The 270 result of localized routing should be the existence of routing 271 information at MAG1 and MAG2, which allows direct forwarding of 272 packets between the MN's MAG1 and the CN's MAG2. As the location 273 information of the CN and the MN is maintained at different LMAs, 274 both LMAs need to be involved in the procedure to set up localized 275 routing. In case of a handover of MNs to a different MAG, not 276 synchronized control of updating the states for localized routing 277 may result in race conditions, superfluous signaling and packet 278 loss. 280 The following list summarizes general problems with setting up and 281 maintaining localized routing between an MN and a CN within a PMIPv6 282 domain. In the context of this problem statement, the MN and the CN 283 are always assumed to be registered at an LMA according to the PMIPv6 284 protocol [RFC5213]. 286 o MNs do not participate in mobility management, hence cannot 287 perform binding registration at a CN on their own. Rather 288 entities in the network infrastructure must take over the role of 289 MNs to set up and maintain a direct route. Accordingly, a 290 solution for localized routing in PMIPv6 must specify protocol 291 operation between relevant network components, such as between a 292 MAG and an LMA, to enable localized routing for data traffic 293 without traversing the MNs' LMA(s) 295 o In case the MN and the CN are both registered with different LMAs 296 according to the PMIPv6 protocol, relevant information for the set 297 up of a localized routing path, such as the current MAGs of the MN 298 and the CN, is distributed between these LMAs. This may 299 complicate the set up and stable maintenance of states enabling 300 localized routing. 302 o In case localized routing between an MN and a CN has been 303 successfully set up and both nodes move and attach to a new access 304 router simultaneously, signaling the new location and maintenance 305 of states for localized routing at relevant routers may run into a 306 race condition situation. This can happen in case coordination of 307 signaling for localized routing and provisioning of relevant state 308 information is distributed between different network entities, 309 e.g. different LMAs. 311 4. IPv4 Considerations 313 According to [I-D.ietf-netlmm-pmip6-ipv4-support], the basic 314 configuration requirements for supporting IPv4 in PMIPv6 are that 315 LMAs and MAGs are both IPv4 and IPv6 enabled. Also, LMAs and MAGs 316 must have a globally unique IPv6 address configured, irrespective of 317 enabled support for IPv6 routing between these components. This 318 requirement should also apply to configuration requirements of 319 localized routing. 321 4.1. Localized Routing between IPv4 Home Addresses 323 In case an LMA and a MAG hold a registration to support IPv4 Home 324 Address mobility for an MN, the MAG and the LMA must support 325 appropriate encapsulation of IPv4 packets. To enable localized 326 routing, the MN's MAG must encapsulate and forward routing path 327 optimized packets to the CN's MAG and needs to ensure, that the 328 chosen encapsulation mode is supported by the correspondent MAG. 329 Incompatibility in a selected encapsulation mode causes failure in 330 setting up a localized route. Probably a capability exchange with 331 encapsulation mode selection or negotiation scheme between MAGs must 332 be supported to counteract such failure. Selection of an 333 encapsulation mode is not needed in case both nodes attach to the 334 same MAG, but needs to be performed each time a node hands over to a 335 different MAG. 337 MAGs must maintain a routing state for each MN-CN-pair and take 338 routing decisions for uplink traffic based on the packets' complete 339 IPv4 source and destination address. Hence, conceptual data 340 structures to handle states for localized routes need to comprise 341 this address tuple for unique identification. 343 4.2. IPv4 Transport Network Considerations 345 As stated in the beginning of Section 4, LMA and MAG are both IPv4 346 and IPv6 enabled when IPv4 is supported in PMIPv6. However, when 347 using IPv4 transport, it is not necessary to enable IPv6 routing 348 between LMA and MAG. Thus, the MN's MAG and the CN's MAG may use 349 different IP versions for the transport of PMIPv6 signaling messages 350 to the LMA. For example, it is possible that the MN's MAG supports 351 IPv4 home address mobility and IPv6 transport, whereas the CN's MAG 352 supports IPv4 home address mobility and IPv4 transport. In that 353 case, it is necessary that the MN's and CN's MAGs negotiate the IP 354 version for localized routing signaling and data forwarding. 356 When the MN hands over to a new MAG, the MAG may use a different IP 357 version for PMIPv6 signaling as the MN's previous MAG. In that case, 358 the new MAG may need to re-negotiate the IP version of the data 359 forwarding tunnel for localized routing and signaling or to restart 360 the localized routing procedure. 362 4.3. NAT Presence Issues 364 In [I-D.ietf-netlmm-pmip6-ipv4-support], packets originated from or 365 sent to a MN are routed by default through a bidirectional tunnel 366 between MAG and LMA and the presence of a NAT between MAG and LMA is 367 considered. Even though there may not be any NAT between the MAG and 368 the LMA, there may exist a NAT on the direct routing path between 369 MN's MAG and the CN's MAG or between the MN and CN's LMAs. 370 Therefore, NAT detection and traversal mechanisms should be utilized 371 during initializing localized routing procedures for IPv4 support. 373 4.4. IPv4 Address Space Overlapping Issues 375 As described in [I-D.ietf-netlmm-grekey-option], GRE keys being 376 encapsulated within tunneled packets can be used to distinguish each 377 MN's flow between the MAG and the LMA, even though two MNs may have 378 assigned the same HoA from an overlapping IPv4 address space managed 379 by each MN's operator. However, special care may be taken of a use 380 case where a packet from the CN is sent to two MNs which are assigned 381 the same IPv4 HoA and attach to the same MAG. If the packet does not 382 traverse the tunnel between the MN's MAG and its LMA but is forwarded 383 directly from the CN's MAG to the MN's MAG due to localized routing, 384 the MN's MAG may not be able to identify the MN to which the packet 385 must be delivered. Therefore, in this context there may be the need 386 to utilize some service differential mechanism to identify flows 387 being forwarded directly between MAGs. 389 5. Security Considerations 391 Since network entities rather than MNs and CNs perform signaling to 392 set up localized routing, the MIPv6 return routability test [RFC3775] 393 is not suitable to authenticate associated signaling messages in 394 PMIPv6. Solutions for localized routing in PMIPv6 need to mitigate 395 or to provide sufficient defense against possible security threats. 396 When PMIPv6 participants are administered within the same domain, 397 infrastructure-based authorization mechanisms, such as IPsec, may be 398 usable to protect signaling for localized routing. 400 Existing security associations according to [RFC5213] can be re-used 401 to protect signaling for localized routing on the interface between a 402 MAG and an LMA. In case a protocol solution for localized routing in 403 PMIPv6 relies on protocol operation between MAGs, means for 404 protection of signaling between these MAGs must be provided. The 405 same applies for signaling on a possible protocol interface between 406 two LMAs of the same domain. 408 6. Acknowledgments 410 Many aspects of the problem space for route optimization in PMIPv6 411 have been discussed in the context of a PMIPv6 Route Optimization 412 Design Goals document, which has been submitted to the NetLMM WG in 413 November 2007. This group of contributors includes Sangjin Jeong, 414 Christian Vogt, Ryuji Wakikawa, Behcet Sarikaya, Shinta Sugimoto, 415 Long Le, Alice Qinxia and Jaehwoon Lee. Many thanks also to Rajeev 416 Koodli for his comments about the structure and scope of this problem 417 statement. 419 This version of the problem statement relects the results of the 420 discussion in the NetExt group based on the initial version of the 421 document. Many thanks to Hidetoshi Yokota, Carlos Bernardos, 422 Ashutosh Dutta, Sri Gundavelli and Jouni Korhonen for their comments. 424 7. References 426 7.1. Normative References 428 [I-D.ietf-netlmm-grekey-option] 429 Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 430 "GRE Key Option for Proxy Mobile IPv6", 431 draft-ietf-netlmm-grekey-option-09 (work in progress), 432 May 2009. 434 [I-D.ietf-netlmm-pmip6-ipv4-support] 435 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 436 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-13 437 (work in progress), June 2009. 439 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 440 Requirement Levels", BCP 14, RFC 2119, March 1997. 442 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 443 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 445 7.2. Informative References 447 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 448 in IPv6", RFC 3775, June 2004. 450 Appendix A. Change Notes 452 Changes in version 01 454 o Added a note about [RFC5213]'s understanding of localized routing 455 and the difference to the use cases discussed in this problem 456 statement 458 o Added the need for the solution to support also termination of 459 localized routing 461 o Some editorial revision 463 o Added chapter about IPv4 support according to the discussed and 464 relevant issues 466 Authors' Addresses 468 Marco Liebsch 469 NEC Laboratories Europe 470 NEC Europe Ltd. 471 Kurfuersten-Anlage 36 472 69115 Heidelberg, 473 Germany 475 Phone: +49 6221 4342146 476 Email: liebsch@nw.neclab.eu 478 Sangjin Jeong 479 ETRI 480 138 Gajeongno, Yuseong 481 Daejeon, 305-700 482 Korea 484 Phone: +82 42 860 1877 485 Email: sjjeong@etri.re.kr 487 Qin Wu 488 Huawei Technologies,Co.,Ltd 489 12F, Huihong Mansion,No.91,Baixia Rd., 490 Nanjing, 210001 491 China 493 Phone: +86 21 84565892 494 Email: sunseawq@huawei.com