idnits 2.17.1 draft-ietf-netext-pmip6-lr-ps-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 14, 2011) is 4789 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NetExt Working Group M. Liebsch, Ed. 3 Internet-Draft NEC 4 Intended status: Informational S. Jeong 5 Expires: September 15, 2011 ETRI 6 Q. Wu 7 Huawei 8 March 14, 2011 10 PMIPv6 Localized Routing Problem Statement 11 draft-ietf-netext-pmip6-lr-ps-06.txt 13 Abstract 15 Proxy Mobile IPv6 is the IETF standard for network-based mobility 16 management. In Proxy Mobile IPv6, mobile nodes are topologically 17 anchored at a Local Mobility Anchor, which forwards all data for 18 registered mobile nodes. The setup and maintenance of localized 19 routing, which allows forwarding of data packets between mobile nodes 20 and correspondent nodes directly without involvement of the Local 21 Mobility Anchor in forwarding, is not considered. This document 22 describes the problem space of localized routing in Proxy Mobile 23 IPv6. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 15, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 61 3. Problem Statement for Localized Routing in PMIPv6 . . . . . . 5 62 3.1. General Observation . . . . . . . . . . . . . . . . . . . 5 63 3.2. Use Cases Analysis . . . . . . . . . . . . . . . . . . . . 6 64 3.3. IPv4 Considerations . . . . . . . . . . . . . . . . . . . 8 65 3.3.1. Localized Routing for Communication between IPv4 66 Home Addresses . . . . . . . . . . . . . . . . . . . . 8 67 3.3.2. IPv4 Transport Network Considerations . . . . . . . . 9 68 4. Functional Requirements for Localized Routing . . . . . . . . 10 69 5. Roaming Considerations . . . . . . . . . . . . . . . . . . . . 11 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 76 Appendix A. Change Notes . . . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 79 1. Introduction 81 The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the 82 base protocol for network-based localized mobility management 83 (NetLMM). The scope of the base protocol covers the set up and 84 maintenance of a tunnel between an MN's Mobile Access Gateway (MAG) 85 and its selected Local Mobility Anchor (LMA). Data packets will 86 always traverse the MN's MAG and its LMA, irrespective of the 87 location of the MN's remote communication endpoint. Even though an 88 MN may be attached to the same or a different MAG as its 89 Correspondent Node (CN) within the same provider domain, packets 90 being associated with their communication will traverse the MN's and 91 the CN's LMA. [RFC5213] addresses the need to enable local routing 92 of traffic between two nodes being attached to the same MAG, but does 93 not specify the complete procedure to establish such localized 94 routing state on the shared MAG. 96 The NetLMM Extensions (NetExt) Working Group has an objective to 97 design a solution for localized routing in PMIPv6. This includes the 98 specification of protocol messages and associated protocol operation 99 between PMIPv6 components to support the setup of a direct routing 100 path for data packets between the MN's and the CN's MAG. As a result 101 of localized routing, these packets will be forwarded between the two 102 associated MAGs without traversing the MN's and the CN's LMA(s). In 103 case one or both nodes hand over to a different MAG, the localized 104 routing protocol maintains the localized routing path. Relevant 105 protocol interfaces may include the interface between associated 106 MAGs, between a MAG and an LMA as well as between LMAs. 108 This document analyzes and discusses the problem space of using 109 always the default route through two communicating mobile nodes' 110 local mobility anchors. Furthermore, the problem space of enabling 111 localized routing in PMIPv6 is analyzed and described, while 112 different communication and mobility scenarios are taken into 113 account. 115 2. Conventions and Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 This document uses the terminology of [RFC5213]. The following terms 122 are used in the context of this problem statement: 124 o Mobile Node (MN): Mobile Node without IP mobility support, which 125 is attached to a Mobile Access Gateway (MAG) and registered with a 126 Local Mobility Anchor (LMA) according to the PMIPv6 specification 127 [RFC5213]. 129 o Correspondent Node (CN): Correspondent Node according to its 130 definition in [RFC3775] with or without IP mobility support. The 131 CN represents the communication peer of an MN, which is attached 132 to a MAG and registered with an LMA according to the PMIPv6 133 specification. 135 o Localized Routing: Result of signaling to set up routing states on 136 relevant network entities to allow forwarding of data packets 137 between an MN and a CN, which are attached to MAGs sharing the 138 same provider domain, without intervention of the MN's LMA and the 139 CN's LMA in data forwarding. 141 o Localized Routing States: Information for localized routing on 142 relevant forwarding entities on the optimized data path between an 143 MN and a CN. Such information includes route entries and tunnel 144 endpoints and may include further information about the MN and the 145 CN, such as the communicating nodes' Mobile Node Identifier and 146 their assigned Home Network Prefix. 148 o Provider Domain: A network domain in which network components are 149 administered by a single authority, e.g. the mobile operator. 151 3. Problem Statement for Localized Routing in PMIPv6 153 3.1. General Observation 155 The Mobile IPv6 (MIPv6) protocol [RFC3775] has built-in mechanisms 156 for direct communication between an MN and a CN. Mechanisms for 157 route optimization in MIPv6 cannot be directly applied in PMIPv6. 158 Following the paradigm of PMIPv6, MNs are not involved in mobility 159 signaling, hence cannot perform signaling to set up localized routes. 160 Instead, the solution for localized routing must consider functions 161 in the network to find out whether or not a localized route is to be 162 used and then control the setup and maintenance of localized routing 163 states accordingly without any assistance from the MN and the CN. In 164 case of communication between two nodes, which are attached to the 165 PMIPv6 network infrastructure and each node is registered with an 166 LMA, data packets between these two nodes will always traverse the 167 responsible LMA(s). At least some deployment would benefit from 168 having such communication localized, rather than traverse the core 169 network to the LMA(s). In the context of this document, such 170 localized communication comprises offloading traffic from LMAs and 171 establish an optimized forwarding path between the two communication 172 endpoints. 174 Localized routing is understood in [RFC5213] as optimization of 175 traffic between an MN and a CN that are attached to an access link 176 connected to a same MAG. In such case, the MAG forwards traffic 177 directly between the MN and the CN, assuming the MAG is enabled to 178 support this feature (setting of the EnableMAGLocalRouting flag on 179 the MAG) and the MN's LMA enforces this optimization. [RFC5213] does 180 not specify how an LMA can enforce optimization for such local 181 communication. Maintaining local forwarding between the MN and the 182 regular IPv6 CN gets more complex in case the MN performs a handover 183 to a different MAG. Such use case is not considered in the 184 specification and out of scope of this problem statement. This 185 document focuses on use cases, where both nodes, the MN and the CN, 186 are within a PMIPv6 network and served by an LMA in a domain of LMAs. 188 Localized routing is relevant at least for the following two reasons: 189 First, by limiting the communication to the access nodes, the data 190 traffic traversing the MAG - LMA path (network) can be reduced. This 191 is significant considering that the transport network between the 192 access and the core is often the bottleneck in terms of costs and 193 performance. Second, there may be performance benefits for data 194 flows between the MN and the CN in terms of delay and packet loss, 195 especially when the MN and the CN are attached to the same MAG and 196 the LMA is topologically far away from that MAG. Even when the MN 197 and the CN are attached to different MAGs, there could be benefit in 198 limiting the communication to the access network only, rather than 199 traversing the transport network to the LMA. Furthermore, offloading 200 traffic from the LMA by means of localized routing can improve 201 scalability of the LMA, as it represents a bottleneck for traffic 202 being forwarded by many MAGs. Hence, providing the necessary 203 protocol specification to enable localized routing in PMIPv6 is 204 strongly recommended. 206 3.2. Use Cases Analysis 208 This problem statement focuses on local communication between PMIPv6 209 managed nodes, which attach to MAGs sharing the same provider domain. 210 The following list analyzes different use cases, which consider the 211 existence of multiple LMAs. Figure 1 depicts a PMIPv6-based network 212 with two mobility anchors. According to [RFC5213], the MN moves in 213 the PMIPv6 domain being built by its LMA and MAG. The same applies 214 to the CN, which moves in the PMIPv6 domain built by the CN's LMA and 215 MAG. The analysis takes no assumption on whether the MN and the CN 216 share the same PMIPv6 domain or not. 218 Internet Backbone 219 : : 220 +------------------+ 221 | | 222 +----+ +----+ 223 |LMA1| |LMA2| 224 +----+ +----+ 225 | | 226 | | 227 +----+------------------+----+ 228 | | 229 +----+ +----+ 230 |MAG1| |MAG2| 231 +----+ +----+ 232 : : : 233 +---+ +---+ +---+ 234 |MN | |CN1| |CN2| 235 +---+ +---+ +---+ 237 Figure 1: Reference architecture for localized routing in PMIPv6 239 All use cases A assume that both the MN and the CN are registered 240 with an LMA according to the PMIPv6 protocol. Whereas MAG1 is always 241 considered as the MN's current Proxy Care-of Address, the CN can be 242 either connected to the same or a different MAG or LMA as the MN. 243 Accordingly, these topological differences are denoted as follows: 245 A[number of MAGs][number of LMAs] 247 A11: MN and CN (CN1) connect to the same MAG (MAG1) and are 248 registered with the same LMA (LMA). The common MAG may forward 249 data packets between the MN and the CN directly without forwarding 250 any packet to the LMA. [RFC5213] addresses this use case, but 251 does not specify the complete procedure to establish such 252 localized routing state on the shared MAG. 254 A12: MN and CN (CN1) connect to the same MAG (MAG1) and are 255 registered with different LMAs (LMA1 and LMA2). The common MAG 256 may forward data packets between the MN and the CN directly 257 without forwarding any packet to the LMAs. Following the policy 258 of [RFC5213] and enforcement of the setup of a localized 259 forwarding path, potential problems exist in case LMA1 and LMA2 260 differ in their policy to control the MAG. 262 A21: The CN (CN2) connects to a different MAG (MAG2) as the MN 263 (MAG1), but MN and CN are registered with the same LMA (LMA1). 264 The result of localized routing should be the existence of routing 265 information at MAG1 and MAG2, which allows direct forwarding of 266 packets between the MN's MAG1 and the CN's MAG2. As LMA1 is the 267 common anchor for MN and CN and maintains location information for 268 both nodes, no major race condition and instability in updating 269 the states for localized routing is expected. 271 A22: The CN (CN2) connects to a different MAG (MAG2) and a different 272 LMA (LMA2) as the MN (MAG1, LMA1). The result of localized 273 routing should be the existence of routing information at MAG1 and 274 MAG2, which allows direct forwarding of packets between the MN's 275 MAG1 and the CN's MAG2. As the location information of the CN and 276 the MN is maintained at different LMAs, both LMAs need to be 277 involved in the procedure to set up localized routing. In case of 278 a handover of the MN and/or the CN to a different MAG, not 279 synchronized control of updating the states for localized routing 280 may result in race conditions, superfluous signaling and packet 281 loss. 283 The following list summarizes general problems with setting up and 284 maintaining localized routing between an MN and a CN. In the context 285 of this problem statement, the MN and the CN are always assumed to be 286 registered at an LMA according to the PMIPv6 protocol [RFC5213]. 288 o MNs do not participate in mobility management, hence cannot 289 perform binding registration at a CN on their own. Rather 290 entities in the network infrastructure must take over the role of 291 MNs to set up and maintain a direct route. Accordingly, a 292 solution for localized routing in PMIPv6 must specify protocol 293 operation between relevant network components, such as between a 294 MAG and an LMA, to enable localized routing for data traffic 295 without traversing the MNs' LMA(s). 297 o In case the MN and the CN are both registered with different LMAs 298 according to the PMIPv6 protocol, relevant information for the set 299 up of a localized routing path, such as the current MAG of the MN 300 and the CN, is distributed between these LMAs. This may 301 complicate the setup and stable maintenance of states enabling 302 localized routing. 304 o In case localized routing between an MN and a CN has been 305 successfully set up and both nodes move and attach to a new access 306 router simultaneously, signaling the new location and maintenance 307 of states for localized routing at relevant routers may run into a 308 race condition situation. This can happen in case coordination of 309 signaling for localized routing and provisioning of relevant state 310 information is distributed between different network entities, 311 e.g. different LMAs. In such case, as a result of MN's handover, 312 updated information about the MN's location may arrive at the CN's 313 previous MAG while CN moved already to a new MAG. The same 314 applies to the other direction, where the system may update MN's 315 previous MAG about CN's new location while the MN has moved to a 316 new MAG in the meantime. The protocol solution must deal with 317 such exceptional handover cases efficiently to avoid or resolve 318 such problem. 320 3.3. IPv4 Considerations 322 According to [RFC5844], the basic configuration requirements for 323 supporting IPv4 in PMIPv6 are that LMAs and MAGs are both IPv4 and 324 IPv6 enabled. Also, LMAs and MAGs must have a globally unique IPv6 325 address configured, irrespective of enabled support for IPv6 routing 326 between these components. This requirement should also apply to 327 configuration requirements of localized routing. 329 Additional issues emerge when localized routing is considered for 330 PMIPv6 with IPv4 support. These can be classified into two general 331 groups, which are issues with localized routing between an MN's and a 332 CN's IPv4 Home Addresses or transport plane issues. The following 333 subsections analyze these two groups. 335 3.3.1. Localized Routing for Communication between IPv4 Home Addresses 337 In case an LMA and a MAG hold a registration to support IPv4 Home 338 Address mobility for an MN, the MAG and the LMA must support 339 appropriate encapsulation of IPv4 packets. To enable localized 340 routing, the MN's MAG must encapsulate and forward routing path 341 optimized packets to the CN's MAG and needs to ensure, that the 342 chosen encapsulation mode is supported by the correspondent MAG. 343 Incompatibility in a selected encapsulation mode causes failure in 344 setting up a localized route. 346 When localized routing is used for IPv4 traffic, the conceptual data 347 structures on associated MAGs must be augmented with appropriate 348 parameters for forwarding localized traffic. MAGs may need to 349 maintain a routing state for each MN-CN-pair and make routing 350 decisions for uplink traffic based on the packets' complete IPv4 351 source and destination address. Hence, conceptual data structures to 352 handle states for localized routes need to comprise this address 353 tuple for unique identification. 355 As a known constraint, IPv4 addresses of two nodes, which hold 356 addresses from a private address space, may overlap. To uniquely 357 identify both nodes, the IPv4 address of the MN and the CN must not 358 overlap. To cope with overlapping address spaces, the localized 359 routing solution could use additional mechanisms to tag and uniquely 360 identify the MN and the CN. 362 3.3.2. IPv4 Transport Network Considerations 364 The transport network between LMA and MAG may be based on IPv6 or 365 IPv4. Deployments may ensure that the same transport mechanism 366 (i.e., IPv6 or IPv4) is used for operational consistency. Similar to 367 the encapsulation requirement stated in the previous section, the IP 368 version used for localized routing is also assumed, by configuration, 369 to be consistent across all MAGs within the associated provider 370 domain. The design of optional mechanisms for negotiating the IP 371 version to use as well as the encapsulation mode to use are outside 372 the scope of the NetExt WG's solution for localized routing. 374 4. Functional Requirements for Localized Routing 376 Several tasks need to be performed by the network infrastructure 377 components before relevant information for such direct communication 378 is discovered and associated states for localized routing can be set 379 up. The following list summarizes some key functions, which need to 380 be performed by the PMIPv6 enabled network infrastructure to 381 substitute mobile nodes in setting up a direct route. 383 o Detection of the possibility to perform localized routing. This 384 function includes looking at data packets' source and destination 385 address. 387 o Initiation of a procedure, which sets up a localized routing path. 389 o Discovery of stateful entities (i.e. the LMA(s) and/or the 390 MAG(s)), which maintain and can provide relevant information 391 needed to set up a localized routing path. Such information may 392 include the routable address of an LMA or MAG, where one or both 393 mobile nodes are connected to and registered with. 395 o Control in setting up and maintaining (e.g. during handover) the 396 localized routing path. Control is also needed to terminate the 397 use of a localized routing path and to delete associated states, 398 whereas a trigger for the termination may come from a non-PMIPv6 399 related component. 401 o Enforcement of administrative policy rules to localized routing. 402 Such policies allow operators to have further control on the set 403 up of a localized route and enable the possibility to disallow 404 localized routing, for example to ensure that traffic traverses 405 charging related functions on the LMA. 407 5. Roaming Considerations 409 Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., 410 LMAs, MAGs) tied by MN and CN may be distributed between different 411 provider domains (i.e., domain A, B, C) and MN and/or CN moves from 412 one provider domain to another one. In order to support localized 413 routing when roaming occurs, it is required that MAGs to which MN and 414 CN connect are within the same provider domain and each MAG has a 415 security relationship with the corresponding LMA which maintains the 416 registration of the MN or the CN, respectively. 418 According to the roaming model as depicted in Figure 2, MN's PMIPv6 419 domain is characterized by its MAG (MAG1/MAG1') and its LMA (LMA1), 420 whereas CN's PMIPv6 domain is characterized by CN's MAG (MAG2/MAG2') 421 and its LMA (LMA2/LMA2'). A solution for localized routing cannot 422 take any assumption about whether or not MN and CN share the same 423 PMIPv6 domain, hence MAG1/MAG1' may not share a security association 424 with LMA2/LMA2' and MAG2/MAG2' may not share a security association 425 with LMA1 respectively. 427 It is not required that LMAs, which hold the registration for the MN 428 and the CN respectively, are part of the same provider domain as the 429 MAGs where MN and CN attach. When MN's MAG and MN's LMA belong to 430 different provider domains (A and C), localized routing is subject to 431 policy governing the service level agreements between these domains. 432 The same applies to the provider domains which provide CN's MAG and 433 LMA. Based on the above requirements, four PMIPv6 roaming and non- 434 roaming cases can be taken into account. 436 o Case 1: MN's MAG (MAG1), CN's MAG (MAG2), MN's LMA (LMA1), CN's 437 LMA (LMA2) are located in the same provider domain A. 439 o Case 2: MN's MAG (MAG1), CN's MAG (MAG2), MN's LMA (LMA1) are 440 located in the same domain A while CN's LMA (LMA2') is located in 441 provider domain B. 443 o Case 3: MN's MAG (MAG1'), CN's MAG (MAG2') are located in domain C 444 while MN's LMA (LMA1) and CN's LMA (LMA2) are located in provider 445 domain A. 447 o Case 4: MN's MAG (MAG1'), CN's MAG (MAG2') are located in provider 448 domain C while MN's LMA (LMA1) is located in provider domain A, 449 and CN's LMA (LMA2) is located in provider domain B. 451 In these roaming cases, MN can be allowed to roam within its domain 452 (e.g, MN's home domain in which MN's LMA is located) or over 453 different domains (e.g., MN moves from its home domain to a visited 454 domain). During mobility, CN and MN should remain attached to MAGs 455 of the same provider domain to maintain efficient routing of traffic 456 between their MAGs. 458 | 459 +-----+ +-----+ | +-----+ 460 |LMA1 | |LMA2 | | |LMA2'| 461 +-----+ +-----+ | +-----+ 462 | 463 | 464 | 465 | 466 +-----+ +-----+ | 467 |MAG1 | |MAG2 | | 468 +-----+ +-----+ | 469 | 470 | 471 Provider Domain A | Provider Domain B 472 ------------------------------+------------------------------- 473 Provider Domain C 475 +-----+ +-----+ 476 |MAG1'| |MAG2'| 477 +-----+ +-----+ 479 Figure 2: PMIPv6 roaming cases considered for Localized Routing 481 6. Security Considerations 483 A protocol solution for localized routing in a PMIPv6 network must 484 counter unauthorized change of a routing path. In particular, the 485 control plane for localized routing must preclude blocking or 486 hijacking of mobile nodes' traffic by malicious or compromised 487 network components. A security solution must support suitable 488 mechanisms for authentication of control plane components of the 489 localized routing functional architecture for both scenarios, roaming 490 and non-roaming. Any possibility for Internet hosts to interfere 491 with the localized routing procedure in a malicious manner must be 492 precluded. 494 Since network entities rather than MNs and CNs perform signaling to 495 set up localized routing, the MIPv6 return routability test [RFC3775] 496 is not suitable to authenticate associated signaling messages in 497 PMIPv6. Solutions for localized routing in PMIPv6 need to mitigate 498 or to provide sufficient defense against possible security threats. 499 When PMIPv6 participants are administered within the same domain, 500 infrastructure-based authorization mechanisms, such as IPsec, may be 501 usable to protect signaling for localized routing. 503 Existing security associations according to [RFC5213] can be re-used 504 to protect signaling for localized routing on the interface between a 505 MAG and an LMA. In case a protocol solution for localized routing in 506 PMIPv6 relies on protocol operation between MAGs, means for 507 protection of signaling between these MAGs must be provided. The 508 same applies for signaling on a possible protocol interface between 509 two LMAs of the same domain. 511 7. IANA Considerations 513 This document does not require any action from IANA. 515 8. Acknowledgments 517 Many aspects of the problem space for route optimization in PMIPv6 518 have been discussed in the context of a PMIPv6 Route Optimization 519 Design Goals document, which has been submitted to the NetLMM WG in 520 November 2007. This group of contributors includes Sangjin Jeong, 521 Christian Vogt, Ryuji Wakikawa, Marco Liebsch, Behcet Sarikaya, 522 Shinta Sugimoto, Long Le, Alice Qinxia and Jaehwoon Lee. Many thanks 523 to Rajeev Koodli for his comments about the structure and scope of 524 this problem statement for the NetExt WG. 526 This problem statement reflects the results of the discussion in the 527 NetExt group. Many thanks to Hidetoshi Yokota, Carlos Bernardos, 528 Ashutosh Dutta, Sri Gundavelli, Mohana Jeyatharan, Jouni Korhonen, 529 Glen Zorn, Dirk von Hugo, Frank Xia, Xiangsong Cui and Basavaraj 530 Patil for their comments and support to improve the quality of the 531 problem statement. 533 9. References 535 9.1. Normative References 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, March 1997. 540 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 541 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 543 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 544 Mobile IPv6", RFC 5844, May 2010. 546 9.2. Informative References 548 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 549 in IPv6", RFC 3775, June 2004. 551 Appendix A. Change Notes 553 Changes in version 01: 555 o Removed text about potential issues with IPv4 address conflict 556 from Section 3.3.1 (out of NetExt scope) 558 o Removed NAT issues from Section 3.3.2 (out of NetExt scope) 560 o Removed text about IP version and encapsulation mode negotiation 561 from 3.3.2 (out of NetExt scope) 563 Changes in version 02: 565 o Consistently refer to communication between MN and CN, not between 566 two MNs 568 o Adopt text to the result of the roaming model discussion and refer 569 to provider domain, not PMIPv6 domain 571 o Revision of Terms section according to comments 573 o Revision of text in Section 3.1 about network entities, which 574 perform signaling for localized routing (clarification) 576 o Revision of text in Section 3.1 to clarify about localized routing 577 benefits 579 o Revision of text in Section 3.2 to clarify about signaling race 580 condition in multi-LMA case 582 o Add more text to Section 5 about the roaming model for localized 583 routing, relevance of the PMIPv6 domain concept and associated 584 issues with localized routing in roaming case 586 o Modified heading of Section 3.3.1 to avoid confusion with 587 localized routing between IPv4 Proxy-CoAs 589 Changes in version 03: 591 o Editorial revision according to received comments 593 o IPv4 support reference updated from draft to RFC status 595 Changes in version 04: 597 o Editorial revision according to received and agreed comments 599 Changes in version 05: 601 o Editorial revision and clarification according to remaining 602 comments received during WG last call 604 Changes in version 06: 606 o Address AD comment to clarify 2nd paragraph of Section 3.1 608 o Include functional requirement about policy enforcement for 609 localized routing in Section 4 611 o Refer to localized routing specific security threats in the first 612 paragraph of Section 6 614 Authors' Addresses 616 Marco Liebsch (editor) 617 NEC Laboratories Europe 618 NEC Europe Ltd. 619 Kurfuersten-Anlage 36 620 69115 Heidelberg, 621 Germany 623 Phone: +49 6221 4342146 624 Email: liebsch@neclab.eu 626 Sangjin Jeong 627 ETRI 628 138 Gajeongno, Yuseong 629 Daejeon, 305-700 630 Korea 632 Phone: +82 42 860 1877 633 Email: sjjeong@etri.re.kr 635 Qin Wu 636 Huawei Technologies,Co.,Ltd 637 12F, Huihong Mansion,No.91,Baixia Rd., 638 Nanjing, 210001 639 China 641 Phone: +86 21 84565892 642 Email: sunseawq@huawei.com