idnits 2.17.1 draft-ietf-mip4-nemov4-fa-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 413. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 (November 9, 2007) is 6006 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) == Outdated reference: A later version (-11) exists of draft-ietf-mip4-nemo-v4-base-06 ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 2 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 G. Tsirtsis 3 Internet-Draft V. Park 4 Intended status: Standards Track V. Narayanan 5 Expires: May 12, 2008 Qualcomm 6 K. Leung 7 Cisco 8 November 9, 2007 10 FA extensions to NEMOv4 Base 11 draft-ietf-mip4-nemov4-fa-01.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 May 12, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The base NEMOv4 specification defines extensions to Mobile IPv4 for 45 mobile networks. NEMOv4 extensions are defined for use only by the 46 mobile node and the home agent. This specification introduces 47 extensions for NEMO support on the foreign agent. 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Extension Formats . . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. NEMOv4 Tunneling Extension . . . . . . . . . . . . . . . . 6 57 5. Mobile IP registrations . . . . . . . . . . . . . . . . . . . 7 58 5.1. Registration Requests . . . . . . . . . . . . . . . . . . 7 59 5.2. Registration Reply . . . . . . . . . . . . . . . . . . . . 7 60 5.3. Home Agent Considerations . . . . . . . . . . . . . . . . 7 61 5.4. Foreign Agent Considerations . . . . . . . . . . . . . . . 8 62 5.5. Mobile Client Considerations . . . . . . . . . . . . . . . 9 63 5.6. Disparate Address Space Support . . . . . . . . . . . . . 10 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 68 Intellectual Property and Copyright Statements . . . . . . . . . . 15 70 1. Requirements notation 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 2. Acknowledgments 78 Alexandru Petrescu co-authored with Vidya (one of the co-authors of 79 this I-D) an older document which included some of the mechanisms 80 described herein. 82 3. Introduction 84 3.1. Background 86 The base NEMOv4 specification [I-D.ietf-mip4-nemo-v4-base] defines 87 extensions to MIPv4 [RFC3344] for mobile networks. NEMOv4 extensions 88 are defined for use only by the mobile node and the home agent so 89 there are no extensions defined for NEMOv4 support by foreign agent. 91 NEMOv4 solution [I-D.ietf-mip4-nemo-v4-base] defines: 93 - When the co-located care-of address model is used, traffic to/ 94 from the mobile network prefixes can be sent over a bidirectional 95 tunnel between the mobile node's care-of address and the home 96 agent address. 98 - When the care-of address model is used, traffic to/from the 99 mobile network prefixes must be sent over a bidirectional tunnel 100 between the mobile's home address and the home agent address. 101 This results in double tunneling since traffic to the mobile's 102 home address is encapsulated inside the tunnel between the mobile 103 node's care-of address and home agent address. 105 Extensions defined in this document allow the mobile node and/or a 106 foreign agent to indicate to the home agent what address should be 107 used for tunneling traffic to the mobile network prefixes during 108 registration. Thus, this specification removes the need for double 109 encapsulation when a foreign agent is used. 111 4. Extension Formats 113 The following extension is defined according to this specification. 115 4.1. NEMOv4 Tunneling Extension 117 A new skippable extension to the Mobile IPv4 header in accordance to 118 the short extension format of MIPv4 [RFC3344] is defined here. 120 The presence of this extension indicates that the sender supports the 121 NEMOv4 and the tunnel selection extensions defined in this 122 specification. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Type | Length | Sub-Type | Reserved | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Type 132 Mobile Network Extension (skippable type range to be assigned by 133 IANA) [I-D.ietf-mip4-nemo-v4-base] 135 Length 137 4 139 Sub-Type 141 TBA (NEMOv4 Tunneling Extension) 143 Reserved 145 Set to 0 by the sender and ignored by the receiver. 147 5. Mobile IP registrations 149 5.1. Registration Requests 151 A mobile node that supports [I-D.ietf-mip4-nemo-v4-base] and this 152 specification MAY include exactly one NEMOv4 tunneling extension when 153 it uses the co-located care-of address mode. 155 When the NEMOv4 tunneling extension is used by the mobile node, it 156 MUST be placed after the registration request header and before the 157 mobile - home authentication extension so, it MUST be included in the 158 computation of any authentication extension. 160 A foreign agent that supports this specification MAY include a NEMOv4 161 tunneling extension defined in the specification in a registration 162 request when the care-of address mode of operation is used. 164 When the NEMOv4 tunneling extension is used by a foreign agent it 165 MUST be placed after the mobile - home authentication extensions and 166 before the foreign - home authentication extension so it MUST be 167 included in the computation of the foreign - home authentication 168 extension when one exists. 170 5.2. Registration Reply 172 A foreign agent that supports this specification MAY include a NEMOv4 173 tunneling extension defined in the specification in a registration 174 reply message 176 When a NEMOv4 tunneling extension is used by a home agent it MUST be 177 placed after the registration reply header and before the mobile - 178 home authentication extension so, it must be included in the 179 calculation of any authentication extension. 181 5.3. Home Agent Considerations 183 A home agent that supports the extensions in this specification MUST 184 act as in [I-D.ietf-mip4-nemo-v4-base] with the addition to the 185 tunneling mode selection defined below. 187 Tunneling mode selection, for mobile network traffic, depends on the 188 following parameters in a valid registration request: 190 1) Registration request is received with one or more Mobile Network 191 Extensions [I-D.ietf-mip4-nemo-v4-base]. A NEMOv4 tunneling 192 extension is NOT included. 194 All mobile network traffic MUST be tunneled by the home agent to 195 the registered home address of the mobile. The home agent MUST 196 NOT include a NEMOv4 tunneling extension in the registration reply 197 and it MUST be prepared to accept reverse tunneled packets from 198 the IPv4 home address of the mobile encapsulating packets sent by 199 the mobile node. 201 2) Registration request is received with one or more Mobile Network 202 Extensions [I-D.ietf-mip4-nemo-v4-base]. A NEMOv4 tunneling 203 extension is included. 205 All mobile network traffic SHOULD be tunneled by the home agent to 206 the registered care-of address of the mobile. In that case, the 207 home agent SHOULD include the NEMOv4 Tunneling extension in the 208 registration reply message and it MUST be prepared to accept 209 reverse tunneled packets from the care-of address of the mobile 210 encapsulating packets sent by the mobile network. Alternatively, 211 the home agent MAY ignore the presence of the NEMOv4 Tunneling 212 extension and act as in case (1) above. 214 As defined in [I-D.ietf-mip4-nemo-v4-base], for each mobile network 215 extension included in a valid registration request, a home agent that 216 supports this specification includes a corresponding mobile network 217 acknowledgement extension. 219 5.4. Foreign Agent Considerations 221 When a foreign agent receives a registration request with 222 [I-D.ietf-mip4-nemo-v4-base] extensions it has the following options: 224 Ignore the [I-D.ietf-mip4-nemo-v4-base] extension(s). The 225 registration request is forwarded as is with no NEMOv4 Tunneling 226 extension to the home agent. 228 Attach a NEMOv4 tunneling extension to the registration request 229 sent to the home agent. 231 If the foreign agent sets the R flag included in the mobility agent 232 advertisement MIPv4 [RFC3344] and a mobile client uses the co-located 233 address model, the foreign agent MUST NOT include a NEMOv4 tunneling 234 extension in the registration request messages sent from that mobile 235 client. 237 When a successful Registration Reply is received the foreign agent 238 MUST act as defined by MIPv4 [RFC3344]. In addition to that and 239 according to this specification the foreign agent SHOULD check for a 240 NEMOv4 Tunnel extension. 242 If the NEMOv4 Tunnel extension is included then the foreign agent 243 MUST establish a bidirectional tunnel. The tunnel endpoints are 244 the care-of address of the foreign agent and the address of the 245 home agent. In addition to setting up a bi-directional tunnel 246 with the home agent, the foreign agent locally establishes 247 forwarding information such that all packets originated by the 248 clients in the mobile network, or originated by the mobile router 249 itself (i.e., packets with source address any address under the 250 registered prefixes for that mobile router) and destined to any 251 correspondent node whose address is topologically correct outside 252 the mobile network are encapsulated through the bi-directional 253 tunnel. Note that registered prefixes are only the prefixes 254 accepted by Mobile Network Acknowledgement Extensions, with Code 255 field set to "0", included in the Registration Reply message. 257 If the NEMOv4 Tunnel extension is not included then the foreign 258 agent SHOULD operate as defined in MIPv4 [RFC3344] and 259 [I-D.ietf-mip4-nemo-v4-base]. 261 5.5. Mobile Client Considerations 263 A mobile router that supports the [I-D.ietf-mip4-nemo-v4-base] 264 extensions may use these extensions to register its mobile networks 265 as defined in [I-D.ietf-mip4-nemo-v4-base]. 267 The mobile client MAY include exactly one NEMOv4 tunneling extension 268 if it uses the co-located care-of address model, if it wants to 269 specifically request that packets to the mobile network are tunneled 270 to its co-located care-of address. Note that if the mobile client 271 uses the co-located care-of address model but it does not include the 272 NEMOv4 tunneling extension, according to 273 [I-D.ietf-mip4-nemo-v4-base], the home agent MAY tunnel mobile 274 network packets to the mobile client's home address. 276 [I-D.ietf-mip4-nemo-v4-base] also defines the mobile client 277 processing when a registration reply is received. In addition that 278 what is defined in [I-D.ietf-mip4-nemo-v4-base], the following 279 processing MUST be done by the mobile client according to this 280 specification. 282 If NEMOv4 Tunnel extension is not included, the mobile client MUST 283 act as defined by [I-D.ietf-mip4-nemo-v4-base] 285 If NEMOv4 Tunnel extension is included then the mobile client MUST 286 act as follows: 288 If the care-of address mode is used, the mobile client MUST be 289 prepared to send/receive traffic from/to the mobile network on 290 its interface natively, unless reverse tunnel has been 291 negotiated in which case all traffic MUST be reverse tunneled 292 according to REVTUN [RFC3024]. 294 If the co-located care-of address mode is used, the mobile 295 client MUST be prepared to send/receive packets from/to the 296 mobile network over the bidirectional tunnel between the home 297 agent address and its co-located care-of address. 299 5.6. Disparate Address Space Support 301 MIPv4 [RFC3344] assumes that all the entities involved have addresses 302 within the same globally unique space. In many deployment scenarios 303 this is not the case, either because of the use of private address 304 space or because of the use of public address space that is only 305 advertised in not advertised globally. The analysis and suggestions 306 on how to deal with such deployments included in Appendix A of REVTUN 307 [RFC3024]] apply in this specification if the prefixes that a mobile 308 node successfully registers according to [I-D.ietf-mip4-nemo-v4-base] 309 and this specification are treated in the same way REVTUN [RFC3024] 310 treats the home address of the mobile node. 312 6. Security Considerations 314 This specification operates in the security constraints and 315 requirements of MIPv4 [RFC3344] and [I-D.ietf-mip4-nemo-v4-base]. 317 A foreign agent that supports this specification SHOULD perform 318 ingress filtering on all the packets received from the mobile router 319 prior to reverse tunneling them to the Home Agent. The foreign agent 320 SHOULD drop any packets that do not have a source address belonging 321 to one of the registered prefixes. For traffic coming from the home 322 agent and if the foreign agent has included a NEMOv4 Tunneling 323 extension in the registration request, the foreign agent MUST be 324 prepared to accept encapsulated packets to the home address of the a 325 registered mobile router as well as to any address under any of the 326 registered prefixes for the same mobile router. 328 7. IANA Considerations 330 This document has no actions for IANA 332 8. Normative References 334 [I-D.ietf-mip4-nemo-v4-base] 335 Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, 336 "Network Mobility (NEMO) Extensions for Mobile IPv4", 337 draft-ietf-mip4-nemo-v4-base-06 (work in progress), 338 October 2007. 340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 341 Requirement Levels", BCP 14, RFC 2119, March 1997. 343 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 344 revised", RFC 3024, January 2001. 346 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 347 August 2002. 349 Authors' Addresses 351 George Tsirtsis 352 Qualcomm 354 Phone: +908-443-8174 355 Email: tsirtsis@qualcomm.com 357 Vincent Park 358 Qualcomm 360 Phone: +908-947-7084 361 Email: vpark@qualcomm.com 363 Vidya Narayana 364 Qualcomm 366 Phone: +858-845-2483 367 Email: vidyan@qualcomm.com 369 Kent Leung 370 Cisco 372 Phone: +408-526-5030 373 Email: kleung@cisco.com 375 Full Copyright Statement 377 Copyright (C) The IETF Trust (2007). 379 This document is subject to the rights, licenses and restrictions 380 contained in BCP 78, and except as set forth therein, the authors 381 retain all their rights. 383 This document and the information contained herein are provided on an 384 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 385 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 386 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 387 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 388 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 389 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 391 Intellectual Property 393 The IETF takes no position regarding the validity or scope of any 394 Intellectual Property Rights or other rights that might be claimed to 395 pertain to the implementation or use of the technology described in 396 this document or the extent to which any license under such rights 397 might or might not be available; nor does it represent that it has 398 made any independent effort to identify any such rights. Information 399 on the procedures with respect to rights in RFC documents can be 400 found in BCP 78 and BCP 79. 402 Copies of IPR disclosures made to the IETF Secretariat and any 403 assurances of licenses to be made available, or the result of an 404 attempt made to obtain a general license or permission for the use of 405 such proprietary rights by implementers or users of this 406 specification can be obtained from the IETF on-line IPR repository at 407 http://www.ietf.org/ipr. 409 The IETF invites any interested party to bring to its attention any 410 copyrights, patents or patent applications, or other proprietary 411 rights that may cover technology that may be required to implement 412 this standard. Please address the information to the IETF at 413 ietf-ipr@ietf.org. 415 Acknowledgment 417 Funding for the RFC Editor function is provided by the IETF 418 Administrative Support Activity (IASA).