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