idnits 2.17.1 draft-ietf-mip4-nemov4-fa-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 405. 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 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 (April 25, 2008) is 5816 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Tsirtsis 3 Internet-Draft V. Park 4 Intended status: Standards Track V. Narayanan 5 Expires: October 27, 2008 Qualcomm 6 K. Leung 7 Cisco 8 April 25, 2008 10 FA extensions to NEMOv4 Base 11 draft-ietf-mip4-nemov4-fa-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 27, 2008. 38 Abstract 40 The base NEMOv4 specification defines extensions to Mobile IPv4 for 41 mobile networks. NEMOv4 extensions are defined for use only by the 42 mobile node and the home agent. This specification introduces 43 extensions for NEMO support on the foreign agent. 45 Table of Contents 47 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 48 2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 51 4. Extension Formats . . . . . . . . . . . . . . . . . . . . . . 3 52 4.1. NEMOv4 Tunneling Extension . . . . . . . . . . . . . . . . 4 53 5. Mobile IP registrations . . . . . . . . . . . . . . . . . . . 4 54 5.1. Registration Requests . . . . . . . . . . . . . . . . . . 4 55 5.2. Registration Reply . . . . . . . . . . . . . . . . . . . . 5 56 5.3. Home Agent Considerations . . . . . . . . . . . . . . . . 5 57 5.4. Foreign Agent Considerations . . . . . . . . . . . . . . . 6 58 5.5. Mobile Client Considerations . . . . . . . . . . . . . . . 7 59 5.6. Disparate Address Space Support . . . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 64 Intellectual Property and Copyright Statements . . . . . . . . . . 10 66 1. Requirements notation 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 2. Acknowledgments 74 Alexandru Petrescu co-authored with Vidya an older document which 75 included some of the mechanisms described herein. 77 3. Introduction 79 3.1. Background 81 The base NEMOv4 specification [RFC5177] defines extensions to MIPv4 82 [RFC3344] for mobile networks. NEMOv4 extensions are defined for use 83 only by the mobile node and the home agent so there are no extensions 84 defined for NEMOv4 support by foreign agent. 86 NEMOv4 [RFC5177] solution defines: 88 - When the co-located care-of address model is used, traffic to/ 89 from the mobile network prefixes can be sent over a bidirectional 90 between the mobile node's care-of address and the home agent 91 address. 93 - When the care-of address model is used, traffic to/from the 94 mobile network prefixes must be sent over a bidirectional between 95 the mobile's home address and the home agent address. This 96 results in double tunneling since traffic to the mobile's home 97 address is encapsulated inside the between the mobile node's 98 care-of address and home agent address. 100 Extensions defined in this document allow the mobile node and/or a 101 foreign agent to indicate to the home agent what address should be 102 used for tunneling traffic to the mobile network prefixes during 103 registration. Thus, this specification removes the need for double 104 encapsulation when a foreign agent is used. 106 4. Extension Formats 108 The following extension is defined according to this specification. 110 4.1. NEMOv4 Tunneling Extension 112 A new skippable extension to the Mobile IPv4 header in accordance to 113 the short extension format of MIPv4 [RFC3344] is defined here. 115 The presence of this extension indicates that the sender supports the 116 NEMOv4 and the selection extensions defined in this specification. 118 0 1 2 3 119 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Type | Length | Sub-Type | Reserved | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Type 126 148 Mobile Network Extension [RFC5177] 128 Length 130 4 132 Sub-Type 134 TBA by IANA (NEMOv4 Tunneling Extension) 136 Reserved 138 Set to 0 by the sender and ignored by the receiver. 140 5. Mobile IP registrations 142 5.1. Registration Requests 144 A mobile node that supports NEMOv4 [RFC5177] and this specification 145 MAY include exactly one NEMOv4 Tunneling Extension when it uses the 146 co-located care-of address mode. 148 When the NEMOv4 Tunneling Extension is used by the mobile node, it 149 MUST be placed after the registration request header and before the 150 mobile - home authentication extension so, it MUST be included in the 151 computation of any authentication extension. 153 A foreign agent that supports this specification MAY include a NEMOv4 154 Tunneling Extension defined in the specification in a registration 155 request when the care-of address mode of operation is used. 157 When the NEMOv4 Tunneling Extension is used by a foreign agent it 158 MUST be placed after the mobile - home authentication extensions and 159 before the foreign - home authentication extension so it MUST be 160 included in the computation of the foreign - home authentication 161 extension when one exists. 163 5.2. Registration Reply 165 A foreign agent that supports this specification MAY include a NEMOv4 166 Tunneling Extension defined in the specification in a registration 167 reply message 169 When a NEMOv4 Tunneling Extension is used by a home agent it MUST be 170 placed after the registration reply header and before the mobile - 171 home authentication extension so, it must be included in the 172 calculation of any authentication extension. 174 5.3. Home Agent Considerations 176 A home agent that supports the extensions in this specification MUST 177 act as in NEMOv4 [RFC5177] with the addition to the tunneling mode 178 selection defined below. 180 Tunneling mode selection, for mobile network traffic, depends on the 181 following parameters in a valid registration request: 183 1) Registration request is received with one or more Mobile Network 184 Request Extensions [RFC5177]. A NEMOv4 Tunneling Extension is NOT 185 included. 187 All mobile network traffic MUST be tunneled by the home agent to 188 the registered home address of the mobile. The home agent MUST 189 NOT include a NEMOv4 Tunneling Extension in the registration reply 190 and it MUST be prepared to accept reverse tunneled packets from 191 the IPv4 home address of the mobile encapsulating packets sent by 192 the mobile node. 194 2) Registration request is received with one or more Mobile Network 195 Request Extensions NEMOv4 [RFC5177]. A NEMOv4 Tunneling Extension is 196 included. 198 All mobile network traffic SHOULD be tunneled by the home agent to 199 the registered care-of address of the mobile. In that case, the 200 home agent SHOULD include the NEMOv4 Tunneling Extension in the 201 registration reply message and it MUST be prepared to accept 202 reverse tunneled packets from the care-of address of the mobile 203 encapsulating packets sent by the mobile network. Alternatively, 204 the home agent MAY ignore the presence of the NEMOv4 Tunneling 205 Extension and act as in case (1) above. 207 As defined in NEMOv4 [RFC5177], for each mobile network extension 208 included in a valid registration request, a home agent that supports 209 this specification includes a corresponding mobile network 210 acknowledgement extension. 212 5.4. Foreign Agent Considerations 214 When a foreign agent receives a registration request with NEMOv4 215 [RFC5177] extensions it has the following options: 217 Ignore the NEMOv4 [RFC5177] extension(s). The registration 218 request is forwarded as is with no NEMOv4 Tunneling Extension to 219 the home agent. 221 Attach a NEMOv4 Tunneling Extension to the registration request 222 sent to the home agent. 224 If the foreign agent sets the R flag included in the mobility agent 225 advertisement MIPv4 [RFC3344] and a mobile client uses the co-located 226 address model, the foreign agent MUST NOT include a NEMOv4 Tunneling 227 Extension in the registration request messages sent from that mobile 228 client. 230 When a successful Registration Reply is received the foreign agent 231 MUST act as defined by MIPv4 [RFC3344]. In addition to that and 232 according to this specification the foreign agent SHOULD check for a 233 NEMOv4 Tunneling Extension. 235 If the NEMOv4 Tunneling Extension is included then the foreign 236 agent MUST establish a bidirectional tunnel. The endpoints are 237 the care-of address of the foreign agent and the address of the 238 home agent. In addition to setting up a bi-directional with the 239 home agent, the foreign agent locally establishes forwarding 240 information such that all packets originated by the clients in the 241 mobile network, or originated by the mobile router itself (i.e., 242 packets with source address any address under the registered 243 prefixes for that mobile router) and destined to any correspondent 244 node whose address is topologically correct outside the mobile 245 network are encapsulated through the bi-directional tunnel. Note 246 that registered prefixes are only the prefixes accepted by Mobile 247 Network Acknowledgement Extensions [RFC5177], with Code field set 248 to "0", included in the Registration Reply message. 250 If the NEMOv4 Tunneling Extension is not included then the foreign 251 agent SHOULD operate as defined in MIPv4 [RFC3344] and NEMOv4 252 [RFC5177]. 254 5.5. Mobile Client Considerations 256 A mobile router that supports the NEMOv4 extensions may use these 257 extensions to register its mobile networks as defined in [RFC5177]. 259 The mobile client MAY include exactly one NEMOv4 Tunneling Extension, 260 if it uses the co-located care-of address model and if it wants to 261 specifically request that packets to the mobile network are tunneled 262 to its co-located care-of address. Note that if the mobile client 263 uses the co-located care-of address model but it does not include the 264 NEMOv4 Tunneling Extension, according to NEMOv4 [RFC5177], the home 265 agent MAY mobile network packets to the mobile client's home address. 267 NEMOv4 [RFC5177] also defines the mobile client processing when a 268 registration reply is received. In addition that what is defined in 269 [RFC5177], the following processing MUST be done by the mobile client 270 according to this specification. 272 If NEMOv4 Tunneling Extension is not included, the mobile client 273 MUST act as defined by [RFC5177] 275 If NEMOv4 Tunneling Extension is included then the mobile client 276 MUST act as follows: 278 If the care-of address mode is used, the mobile client MUST be 279 prepared to send/receive traffic from/to the mobile network on 280 its interface natively, unless reverse has been negotiated in 281 which case all traffic MUST be reverse tunneled according to 282 REVTUN [RFC3024]. 284 If the co-located care-of address mode is used, the mobile 285 client MUST be prepared to send/receive packets from/to the 286 mobile network over the bidirectional tunnel between the home 287 agent address and its co-located care-of address. 289 5.6. Disparate Address Space Support 291 MIPv4 [RFC3344] assumes that all the entities involved have addresses 292 within the same globally unique space. In many deployment scenarios 293 this is not the case, either because of the use of private address 294 space or because of the use of public address space that is only 295 advertised in not advertised globally. The analysis and suggestions 296 on how to deal with such deployments included in Appendix A of REVTUN 297 [RFC3024]] apply in this specification if the prefixes that a mobile 298 node successfully registers according to NEMOv4 [RFC5177] and this 299 specification are treated in the same way REVTUN [RFC3024] treats the 300 home address of the mobile node. 302 6. Security Considerations 304 This specification operates in the security constraints and 305 requirements of MIPv4 [RFC3344] and NEMOv4 [RFC5177]. 307 A foreign agent that supports this specification SHOULD perform 308 ingress filtering on all the packets received from the mobile router 309 prior to reverse tunneling them to the Home Agent. The foreign agent 310 SHOULD drop any packets that do not have a source address belonging 311 to one of the registered prefixes. For traffic coming from the home 312 agent and if the foreign agent has included a NEMOv4 Tunneling 313 Extension in the registration request, the foreign agent MUST be 314 prepared to accept encapsulated packets to the home address of a 315 registered mobile router as well as to any address belonging to any 316 of the registered prefixes for the same mobile router. 318 7. IANA Considerations 320 This document has the following action for IANA. 322 A new value needs to be allocated for the NEMOv4 Tunneling Extension 323 defined in this document, from the number space of the Sub-Type for 324 Mobile Network Extensions defined in NEMOv4 [RFC5177]. 326 8. Normative References 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, March 1997. 331 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 332 revised", RFC 3024, January 2001. 334 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 335 August 2002. 337 [RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, 338 "Network Mobility (NEMO) Extensions for Mobile IPv4", 339 RFC 5177, April 2008. 341 Authors' Addresses 343 George Tsirtsis 344 Qualcomm 346 Phone: +908-443-8174 347 Email: tsirtsis@googlemail.com 349 Vincent Park 350 Qualcomm 352 Phone: +908-947-7084 353 Email: vpark@qualcomm.com 355 Vidya Narayana 356 Qualcomm 358 Phone: +858-845-2483 359 Email: vidyan@qualcomm.com 361 Kent Leung 362 Cisco 364 Phone: +408-526-5030 365 Email: kleung@cisco.com 367 Full Copyright Statement 369 Copyright (C) The IETF Trust (2008). 371 This document is subject to the rights, licenses and restrictions 372 contained in BCP 78, and except as set forth therein, the authors 373 retain all their rights. 375 This document and the information contained herein are provided on an 376 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 377 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 378 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 379 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 380 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 381 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 383 Intellectual Property 385 The IETF takes no position regarding the validity or scope of any 386 Intellectual Property Rights or other rights that might be claimed to 387 pertain to the implementation or use of the technology described in 388 this document or the extent to which any license under such rights 389 might or might not be available; nor does it represent that it has 390 made any independent effort to identify any such rights. Information 391 on the procedures with respect to rights in RFC documents can be 392 found in BCP 78 and BCP 79. 394 Copies of IPR disclosures made to the IETF Secretariat and any 395 assurances of licenses to be made available, or the result of an 396 attempt made to obtain a general license or permission for the use of 397 such proprietary rights by implementers or users of this 398 specification can be obtained from the IETF on-line IPR repository at 399 http://www.ietf.org/ipr. 401 The IETF invites any interested party to bring to its attention any 402 copyrights, patents or patent applications, or other proprietary 403 rights that may cover technology that may be required to implement 404 this standard. Please address the information to the IETF at 405 ietf-ipr@ietf.org.