idnits 2.17.1 draft-jeong-netlmm-pmipv6-roreq-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 472. 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 282: '...zation solutions MUST NOT conflict wit...' RFC 2119 keyword, line 286: '...zation solutions SHOULD have no negati...' RFC 2119 keyword, line 290: '...zation solutions SHOULD be scalable in...' RFC 2119 keyword, line 293: '...zation solutions MAY use preconfigured...' RFC 2119 keyword, line 298: '...ssage for route optimization SHOULD be...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 19, 2007) is 5976 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-06 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-01 ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Jeong (Ed.) 3 Internet-Draft ETRI 4 Intended status: Informational C. Vogt (Ed.) 5 Expires: May 22, 2008 Ericsson 6 R. Wakikawa 7 Keio University 8 M. Liebsch 9 NEC Network Laboratories 10 S. Sugimoto 11 Ericsson 12 B. Sarikaya 13 Huawei Technologies USA 14 November 19, 2007 16 Problem Statement and Requirements for Route Optimization in PMIPv6 17 draft-jeong-netlmm-pmipv6-roreq-01.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 22, 2008. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2007). 48 Abstract 50 This document provides the problem statement for route optimization 51 in Proxy Mobile IPv6 (PMIPv6). It also investigates design goals and 52 requirements for route optimization considering the characteristics 53 of Proxy Mobile IPv6. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Application Scenarios for Route Optimization in Proxy 61 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Route Optimization in Proxy Mobile IPv6 Design Goals . . . . . 5 63 5.1. Low Protocol Complexity . . . . . . . . . . . . . . . . . 6 64 5.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 6 65 5.3. Security Aspect . . . . . . . . . . . . . . . . . . . . . 6 66 5.4. Common Solution for IPv4 and IPv6 . . . . . . . . . . . . 7 67 5.5. Policy Control and Charging . . . . . . . . . . . . . . . 7 68 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 Intellectual Property and Copyright Statements . . . . . . . . . . 12 76 1. Introduction 78 The Proxy Mobile IPv6 (PMIPv6) base protocol document specifies a 79 network-based local mobility management protocol [1]. The Proxy 80 Mobile IPv6 base protocol describes a mobility management solution 81 without a mobile node's participation in mobility management related 82 signaling process. The Proxy Mobile IPv6 base document considers 83 IPv6 home address mobility over IPv6 transport network. The IPv4 84 support document [2] extends the Proxy Mobile IPv6 base protocol in 85 order to support IPv4 home address mobility and IPv4 transport 86 network. 88 The Mobile IPv6 [3] and Enhanced Route Optimization [5] specify route 89 optimization procedures that allow a mobile node (MN) to register its 90 binding information to a corresponding node (CN). After the route 91 optimization procedures, the correspondent node can directly send and 92 receive packets from the mobile node's care-of address. 94 In Proxy Mobile IPv6, packets originated from or sent to a mobile 95 node are routed through bidirectional tunneling between Mobile Access 96 Gateway (MAG) and Local Mobility Anchor (LMA) by default, so packets 97 from/to the mobile can be delivered through longer path than the 98 optimized route, especially when the mobile node and a correspondent 99 node are in topologically close location and local mobility anchor is 100 away from the mobile node. Hence, route optimization is useful, when 101 Proxy Mobile IPv6 domain spans large area. 103 2. Terminology 105 Terminology used in this document is taken directly from [1]. 107 3. Problem Statement 109 Conventional route optimization mechanisms in Mobile IPv6 [3][5] 110 assume no prior configuration and no trust relationship between route 111 optimization process participants, i.e., mobile node and correspond 112 node [4]. However, Mobile IPv6 route optimization mechanisms may not 113 be directly applicable to Proxy Mobile IPv6 because of the following 114 Proxy Mobile IPv6 characteristics. 116 o Since a mobile node is kept completely agnostic on its topological 117 location (i.e., care-of address), basically it is not possible for 118 the mobile node to perform correspondent binding update. 120 o Unlike Mobile IPv6, a mobile node does not participate in binding 121 management procedures and signaling is contained within the 122 network entities in Proxy Mobile IPv6. Hence, the mobile node 123 cannot perform binding registration to a correspondent node and 124 intermediate nodes in the network should do route optimization 125 procedures on behalf of the mobile node. However, since network 126 entity, such as mobile access gateway, is intermediate entity of 127 MN-CN communication, it does not seem to be easy to trigger Mobile 128 IPv6 route optimization. 130 o In Mobile IPv6, a correspondent node validates whether a mobile 131 node is reachable through the mobile node's home address and 132 care-of address and sets up trust relationship between the two 133 nodes. However, the correspondent node cannot establish trust 134 relationship with a mobile node in Proxy Mobile IPv6 domain, 135 because the reachability test is not applicable. 137 4. Application Scenarios for Route Optimization in Proxy Mobile IPv6 139 Since route optimization requires support on the side of a 140 correspondent node, application scenarios for route optimization can 141 be separated into the following three: 143 (1) The correspondent node supports (host-based) Mobile IPv6 [3] and 144 handles route optimization itself. 146 (2) Route optimization support on the correspondent node side is 147 handled by Proxy Mobile IPv6 in the correspondent host's network. 149 (3) Route optimization in Proxy Mobile IPv6 domain supporting IPv4 150 and IPv6. 152 Application scenario (2) can furthermore be subdivided to reflect the 153 relative topological location of mobile and correspondent hosts: 155 (2a) On the same mobile access gateway 157 (2b) On different mobile access gateways, but the same local 158 mobility anchor 160 (2c) On different mobile access gateways and different local 161 mobility anchors from the same Proxy Mobile IPv6 domain 163 (2d) On different mobile access gateways and different local 164 mobility anchors from different Proxy Mobile IPv6 domains 166 Application scenario (3) can furthermore be subdivided based on IPv4 167 support cases: 169 (3a) The mobile node and the correspondent node support IPv4 home 170 address mobility 172 (3b) The mobile node and the correspondent node belong to different 173 mobile access gateways and both mobile access gateways support 174 IPv4 transport to the same local mobility anchor 176 (3c) The mobile node and the correspondent node belong to different 177 mobile access gateways and the mobile access gateways support 178 different IP version transport to the same local mobility 179 anchor 181 (3d) Two local mobility anchors have either IPv4 or IPv6 when the 182 mobile node and the correspondent node anchored to different 183 local mobility anchor 185 5. Route Optimization in Proxy Mobile IPv6 Design Goals 187 This section investigates the fundamental design goals which serve to 188 identify requirements for route optimization solutions in Proxy 189 Mobile IPv6. 191 The function of route optimization is to enable the mobile node and 192 the correspondent node to communicate through a path that is shorter 193 (in terms of hop count) than the path chosen by base Proxy Mobile 194 IPv6. The benefit of this is a reduction in packet propagation 195 delays, in bandwidth consumption and in congestion at local mobility 196 anchor. 198 The general design goals for route optimization solutions are to 199 reduce handover latency, to provide security, and to require low 200 signaling overhead [5]. Based on these fundamental route 201 optimization design goals, this section describes special features 202 and goals concerning route optimization design. Route optimization 203 in Proxy Mobile IPv6 have following unique properties to consider. 205 Route optimization solutions should be designed so that the following 206 design goals can be satisfied. 208 5.1. Low Protocol Complexity 210 In the case of Mobile IPv6 route optimization, if route optimization 211 is used, the mobile node and the correspondent node maintain the 212 binding cache about the mobile node's home address and care-of 213 address. However, since mobility related signaling is exchanged 214 between network entities in Proxy Mobile IPv6, it is expected that 215 route optimization is also performed by the network entities. Thus, 216 route optimization will create state on the network. Therefore, 217 route optimization solutions should be secure, lightweight, and 218 scalable. Also, since route optimization participants are network 219 entities, a mobile node and a correspondent node should not be aware 220 of route optimization procedures. 222 5.2. Trust Relationship 224 In Mobile IPv6 route optimization, it is assumed that the mobile node 225 and the correspondent node do not have any trust relationship [4], 226 whereas in Proxy Mobile IPv6, network entities that perform route 227 optimization are managed objects by the network and owned by the same 228 administrative domain. Thus, different approaches are possible to 229 establish trust relationship. 231 When route optimization support on the correspondent node side is 232 handled by Proxy Mobile IPv6, route optimization solutions need to 233 benefit from a trust relationship between network entities in Proxy 234 Mobile IPv6. However, we may not assume trust relationship between 235 network entities located in Proxy Mobile IPv6 domain. 237 When the correspondent node supports Mobile IPv6 and handles route 238 optimization itself, route optimization solutions cannot assume trust 239 relationship between network entities and the correspondent node. 241 5.3. Security Aspect 243 Security threats and limitations to route optimization in Mobile IPv6 244 are investigated in [4]. Return routability procedures [3] and 245 enhanced route optimization [5] address the threats without public- 246 key infrastructure or a preexisting relationship between the mobile 247 node and the correspondent node. Thus, route optimization solutions 248 in Proxy Mobile IPv6 also need to mitigate or to provide sufficient 249 defense against those security threats. When Proxy Mobile IPv6 route 250 optimization participants are administered within the same domain, 251 infrastructure-based authorization mechanisms, such as IPsec, also 252 may be usable. 254 5.4. Common Solution for IPv4 and IPv6 256 Proxy Mobile IPv6 base protocol specification and extension document 257 enable a Proxy Mobile IPv6 domain to support both IPv6 and IPv4. As 258 defined in the IPv4 extension document in Proxy Mobile IPv6 [2], the 259 mobile node and the correspondent node can be provided IPv4 home 260 address mobility in the Proxy Mobile IPv6 domain. Furthermore, the 261 transport network between mobile access gateway and local mobility 262 anchor can provide IPv4 transport and NAT may reside inside the 263 network. Thus, route optimization solutions should provide home 264 address mobility and transport support for both IPv6 and IPv4. Also, 265 in the case of IPv4 transport support, NAT traversal mechanism may 266 need to be in place. 268 5.5. Policy Control and Charging 270 In general, network operators that provide IP mobility service to the 271 mobile nodes want to monitor the user traffic for the purposes of 272 policy control and charging. Therefore, it is desirable to ensure 273 that route optimization solutions are designed so that network 274 operators can figure out where to place enforcement point of policy 275 control and charging. 277 6. Requirements 279 This section lists the requirements on route optimization for Proxy 280 Mobile IPv6. 282 R1: The route optimization solutions MUST NOT conflict with design 283 goals and requirements for network-based localized mobility 284 management as they are described in [6]. 286 R2: The route optimization solutions SHOULD have no negative impact 287 on the scalability of a network-based localized mobility 288 management domain. 290 R3: Route optimization solutions SHOULD be scalable in Proxy Mobile 291 IPv6 domains. 293 R4: Route optimization solutions MAY use preconfigured or pre- 294 established information for authenticating/authorizing route 295 optimization participants and any signaling message for route 296 optimization. 298 R5: Any signaling message for route optimization SHOULD be 299 exchanged securely during route optimization procedures. 301 R6: Route optimization solutions SHOULD mitigate or provide 302 sufficient defense against possible security threats 303 investigated in [4]. 305 R7: Route optimization solutions SHOULD maintain route optimization 306 states efficiently when mobile nodes handover in Proxy Mobile 307 IPv6 domain(s). 309 R8: Route optimization solutions SHOULD operate over IPv6 and IPv4 310 transport networks. 312 R9: Route optimization solutions MAY consider support both IPv6, 313 IPv4 and dual stack mobile nodes. 315 R10: Route optimization solutions MAY provide NAT traversal 316 mechanism for IPv4 private transport network. 318 R11: Route optimization solutions MUST NOT conflict with an 319 operator's policy to protect its network. 321 7. IANA Considerations 323 No action is required by IANA for this document. 325 8. Security Considerations 327 Security issues are handled in Section 5.3. 329 9. Contributors 331 This contribution is a joint effort of several people. The 332 contributors can be reached at (in alphabetical order): 334 Sangjin Jeong 335 sjjeong@etri.re.kr 337 Long Le 338 Long.Le@nw.neclab.eu 340 Jaehwoon Lee 341 jaehwoon@dongguk.edu 343 Marco Liebsch 344 liebsch@netlab.nec.de 346 Alice Qinxia 347 alice.Q@huawei.com 349 Behcet Sarikaya 350 bsarikaya@huawei.com 352 Shinta Sugimoto 353 shinta@sfc.wide.ad.jp 355 Christian Vogt 356 christian.vogt@ericsson.com 358 Ryuji Wakikawa 359 ryuji@sfc.wide.ad.jp 361 10. References 363 [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and 364 B. Patil, "Proxy Mobile IPv6, draft-ietf-netlmm-proxymip6-06 365 (work in progress)", September 2007. 367 [2] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile 368 IPv6, draft-ietf-netlmm-pmip6-ipv4-support-01 (work in 369 progress)", July 2007. 371 [3] Johnson, D., Perkins, C., and A. Arkko, "Mobility Support in 372 IPv6", RFC 3775, June 2004. 374 [4] Nikander, P., Aura, J., Montenegro, G., and E. Nordmark, "Mobile 375 IP Version 6 Route Optimization Security Design Background", 376 RFC 4225, December 2005. 378 [5] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization 379 for Mobile IPv6", RFC 4866, May 2007. 381 [6] Kempf, Ed., J., "Goals for Network-Based Localized Mobility 382 Management (NETLMM)", RFC 4831, April 2007. 384 Authors' Addresses 386 Sangjin Jeong 387 Electronics and Telecommunications Research Institute 388 138 Gajeongno, Yuseong 389 Daejeon, 305-700 390 Korea 392 Email: sjjeong@etri.re.kr 394 Christian Vogt 395 Ericsson Research, NomadicLab 396 Hirsalantie 11 397 02420 Jorvas, 398 Finland 400 Email: christian.vogt@ericsson.com 402 Ryuji Wakikawa 403 Keio University 404 5322 Endo 405 Fujisawa, Kanagawa 252-8520 406 Japan 408 Email: ryuji@sfc.wide.ad.jp 410 Marco Liebsch 411 NEC Network Laboratories 412 Kurfuersten-Anlage 36 413 69115 Heidelberg, 414 Germany 416 Email: liebsch@netlab.nec.de 418 Shinta Sugimoto 419 Nippon Ericsson K.K. 420 Koraku Mori Building 421 1-4-14, Koraku, Bunkyo-ku 422 Tokyo, 112-0004 423 Japan 425 Email: shinta.sugimoto@ericsson.com 426 Behcet Sarikaya 427 Huawei Technologies USA 428 1700 Alma Dr. Suite 500 429 Plano, TX 75075 430 USA 432 Email: sarikaya@ieee.org 434 Full Copyright Statement 436 Copyright (C) The IETF Trust (2007). 438 This document is subject to the rights, licenses and restrictions 439 contained in BCP 78, and except as set forth therein, the authors 440 retain all their rights. 442 This document and the information contained herein are provided on an 443 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 444 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 445 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 446 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 447 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 448 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 450 Intellectual Property 452 The IETF takes no position regarding the validity or scope of any 453 Intellectual Property Rights or other rights that might be claimed to 454 pertain to the implementation or use of the technology described in 455 this document or the extent to which any license under such rights 456 might or might not be available; nor does it represent that it has 457 made any independent effort to identify any such rights. Information 458 on the procedures with respect to rights in RFC documents can be 459 found in BCP 78 and BCP 79. 461 Copies of IPR disclosures made to the IETF Secretariat and any 462 assurances of licenses to be made available, or the result of an 463 attempt made to obtain a general license or permission for the use of 464 such proprietary rights by implementers or users of this 465 specification can be obtained from the IETF on-line IPR repository at 466 http://www.ietf.org/ipr. 468 The IETF invites any interested party to bring to its attention any 469 copyrights, patents or patent applications, or other proprietary 470 rights that may cover technology that may be required to implement 471 this standard. Please address the information to the IETF at 472 ietf-ipr@ietf.org. 474 Acknowledgment 476 Funding for the RFC Editor function is provided by the IETF 477 Administrative Support Activity (IASA).