idnits 2.17.1 draft-ietf-mip4-nemo-v4-base-08.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1084. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1095. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1102. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1108. 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 (January 21, 2008) is 5939 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) == Outdated reference: A later version (-03) exists of draft-ietf-mip4-nemov4-fa-01 == Outdated reference: A later version (-10) exists of draft-ietf-mip4-rfc3344bis-05 == Outdated reference: A later version (-09) exists of draft-narten-iana-considerations-rfc2434bis-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 K. Leung 3 Internet-Draft G. Dommety 4 Intended status: Standards Track Cisco Systems 5 Expires: July 24, 2008 V. Narayanan 6 Qualcomm, Inc. 7 A. Petrescu 8 Motorola 9 January 21, 2008 11 Network Mobility (NEMO) Extensions for Mobile IPv4 12 draft-ietf-mip4-nemo-v4-base-08.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 24, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document describes a protocol for supporting Mobile Networks 46 between a Mobile Router and a Home Agent by extending the Mobile IPv4 47 protocol. A Mobile Router is responsible for the mobility of one or 48 more network segments or subnets moving together. The Mobile Router 49 hides its mobility from the nodes on the mobile network. The nodes 50 on the Mobile Network may be fixed in relationship to the Mobile 51 Router and may not have any mobility function. 53 Extensions to Mobile IPv4 are introduced to support Mobile Networks. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Mobile Network Extensions . . . . . . . . . . . . . . . . . . 5 61 4.1. Mobile Network Request Extension . . . . . . . . . . . . . 5 62 4.2. Mobile Network Acknowledgement Extension . . . . . . . . . 6 63 5. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 8 64 5.1. Error Processing . . . . . . . . . . . . . . . . . . . . . 9 65 6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 9 66 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 10 68 6.2.1. Registration Table . . . . . . . . . . . . . . . . . . 10 69 6.2.2. Prefix Table . . . . . . . . . . . . . . . . . . . . . 11 70 6.3. Mobile Network Prefix Registration . . . . . . . . . . . . 11 71 6.4. Advertising Mobile Network Reachability . . . . . . . . . 12 72 6.5. Establishment of Bi-directional Tunnel . . . . . . . . . . 13 73 6.6. Sending Registration Replies . . . . . . . . . . . . . . . 13 74 6.7. Mobile Network Prefix De-registration . . . . . . . . . . 13 75 7. Data Forwarding Operation . . . . . . . . . . . . . . . . . . 14 76 8. Nested Mobile Networks . . . . . . . . . . . . . . . . . . . . 14 77 9. Routing Protocol between Mobile Router and Home Agent . . . . 15 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 10.1. Security when Dynamic Routing Protocol is Used . . . . . . 17 80 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 82 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 84 13.2. Informative References . . . . . . . . . . . . . . . . . . 19 85 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 87 Intellectual Property and Copyright Statements . . . . . . . . . . 25 89 1. Introduction 91 This document describes protocol extensions to Mobile IPv4 as per 92 RFC 3344 [RFC3344] and its update [I-D.ietf-mip4-rfc3344bis], to 93 enable support for Mobile Networks. This draft addresses mainly the 94 co-located Care-of Address mode. Foreign Agent Care-of Address mode 95 (with 'legacy' Foreign Agents, RFC 3344 [RFC3344]) are supported but 96 without optimization, double encapsulation being used. For an 97 optimization of this mode, the gentle reader is directed to an 98 extension document [I-D.ietf-mip4-nemov4-fa]. 100 A Mobile Network is defined as a network segment or subnet that can 101 change its point of attachment to the routing infrastructure. Such 102 movement is performed by a Mobile Router, which is the mobility 103 entity that provides connectivity and reachability as well as session 104 continuity for all the nodes in the Mobile Network. The Mobile 105 Router typically serves as the default gateway for the hosts on the 106 Mobile Network. 108 Mobility for the Mobile Network is supported by the Mobile Router 109 registering the point of attachment to its Home Agent. This 110 signaling sets up the tunnel between the two entities. 112 The Mobile Networks (either implicitly configured on the Home Agent 113 or explicitly identified by the Mobile Router) are advertised by the 114 Home Agent for route propagation. Traffic to and from nodes in the 115 Mobile Network are tunneled by the Home Agent to the Mobile Router, 116 and vice versa. Though packets from the Mobile Network can be 117 forwarded directly without tunneling (if reverse tunneling is not 118 used) packets will be dropped if ingress filtering is turned on. 120 This document specifies an additional tunnel between a Mobile 121 Router's Home Address and the Home Agent. This tunnel is 122 encapsulated within the normal tunnel between the Care-of Address 123 (CoA) and Home Agent. In Foreign Agent CoA mode, the tunnel between 124 the Mobile Router and Home Agent is needed to allow the Foreign Agent 125 to direct the decapsulated packet to the proper visiting Mobile 126 Router. However, in Collocated CoA mode, the additional tunnel is 127 not essential and could be eliminated because the Mobile Router is 128 the recipient of the encapsulated packets for the Mobile Network; a 129 proposal for this feature is in an extension document 130 [I-D.ietf-mip4-nemov4-fa]. 132 All traffic between the nodes in the Mobile Network and Correspondent 133 Nodes passes through the Home Agent. This document does not cover 134 route optimization of this traffic. 136 A similar protocol has been documented in RFC 3963 [RFC3963] for 137 supporting IPv6 mobile networks with Mobile IPv6 extensions. 139 Multihoming for Mobile Routers is outside the scope of this document. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 Terminology for network mobility support is defined in RFC 3344 148 [RFC3344] and its update [I-D.ietf-mip4-rfc3344bis]. In addition, 149 this document defines the following terms. 151 Mobile Network Prefix 153 The network prefix of the subnet delegated to a Mobile Router 154 as the Mobile Network. 156 Prefix Table 158 A list of Mobile Network Prefixes indexed by the Home Address 159 of a Mobile Router. The Home Agent manages and uses Prefix 160 Table to determine which Mobile Network Prefixes belong to a 161 particular Mobile Router. 163 3. Requirements 165 Although the original Mobile IPv4 specifications stated that Mobile 166 Networks can be supported by the Mobile Router and Home Agent using 167 static configuration or running a routing protocol (see Section 4.5 168 of RFC 3344 [RFC3344]), there is no solution for explicit 169 registration of the Mobile Networks served by the Mobile Router. A 170 solution needs to provide the Home Agent a means to ensure that a 171 Mobile Router claiming a certain Mobile Network Prefix is authorized 172 to do so. A solution would also expose the Mobile Network Prefixes 173 (and potentially other subnet-relevant information) in the exchanged 174 messages, to aid in network debugging. 176 The following requirements for Mobile Network support are enumerated: 178 o A Mobile Router should be able to operate in explicit or implicit 179 mode. A Mobile Router may explicitly inform the Home Agent which 180 Mobile Network(s) need to be propagated via a routing protocol. A 181 Mobile Router may also function in implicit mode, where the Home 182 Agent may learn the mobile networks through other means, such as 183 from the AAA server, via pre-configuration, or via a dynamic 184 routing protocol. 186 o The Mobile Network should be supported using Foreign Agents that 187 are compliant to RFC 3344 [RFC3344] without any changes ('legacy' 188 Foreign Agents). 190 o The mobile network should allow Fixed Nodes, Mobile Nodes, or 191 Mobile Routers to be on it. 193 4. Mobile Network Extensions 195 4.1. Mobile Network Request Extension 197 For Explicit Mode, the Mobile Router informs the Home Agent about the 198 Mobile Network Prefixes during registration. The Registration 199 Request contains zero, one or several Mobile Network Request 200 extensions in addition to any other extensions defined by or in the 201 context of RFC 3344 [RFC3344]. When several Mobile Networks are 202 needed to be registered, each is included in a separate Mobile 203 Network Request extension, with its own Type, Length, Sub-Type, 204 Prefix Length and Prefix fields. A Mobile Network Request extension 205 is encoded in Type-Length-Value (TLV) format and respects the 206 following format: 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | Sub-Type | Prefix Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Prefix | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Type: 218 Mobile Network Extension (skippable type range to be assigned 219 by IANA). 221 Length: 223 6 225 Sub-Type: 227 TBA (Mobile Network Request) 229 Prefix Length: 231 8-bit unsigned integer indicating the number of bits covering 232 the network part of the address contained in the Prefix 233 field. 235 Prefix: 237 32-bit unsigned integer in network byte-order containing an 238 IPv4 address whose first Prefix Length bits make up the 239 Mobile Network Prefix. 241 4.2. Mobile Network Acknowledgement Extension 243 The Registration Reply contains zero, one or several Mobile Network 244 Acknowledgement extensions in addition to any other extensions 245 defined by or in the context of RFC 3344 [RFC3344] and its update 246 [I-D.ietf-mip4-rfc3344bis]. For Implicit Mode, the Mobile Network 247 Acknowledgement informs the Mobile Router the prefixes for which the 248 Home Agent sets up forwarding with respect to this Mobile Router. 249 Policies such as permitting only traffic from these Mobile Networks 250 to be tunneled to the Home Agent may be applied by the Mobile Router. 251 For Explicit Mode, when several Mobile Networks are needed to be 252 acknowledged explicitly, each is included in a separate Mobile 253 Network Acknowledgement extension, with its own Type, Sub-Type, 254 Length and Prefix Length fields. At least one Mobile Network 255 Acknowledgement extension MUST be in a successful Registration Reply 256 to indicate to the Mobile Router that the Mobile Network Request 257 extension was processed, thereby not skipped by the Home Agent. 259 A Registration Reply may contain any non-zero number of Explicit Mode 260 and Implicit Mode Acknowledgements sub-types. Both sub-types can be 261 present in a single Registration Reply. A Mobile Network 262 Acknowledgement extension is encoded in Type-Length-Value (TLV) 263 format. When the registration is denied with code HA_MOBNET_ERROR, 264 the Code field in the extension provides the reason for the failure. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type | Length | Sub-Type | Code | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Prefix Length | Reserved | Prefix 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Type: 278 TBA Mobile Network Extension (skippable type range to be 279 assigned by IANA). 281 Length: 283 8 285 Sub-Type: 287 TBA (Explicit Mode Acknowledgement) 289 TBA (Implicit Mode Acknowledgement) 291 Code: 293 Value indicating success or failure: 295 TBA Success 297 TBA Invalid prefix (MOBNET_INVALID_PREFIX_LEN) 299 TBA Mobile Router is not authorized for prefix 300 (MOBNET_UNAUTHORIZED) 302 TBA Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) 304 Prefix Length: 306 8-bit unsigned integer indicating the number of bits covering 307 the network part of the address contained in the Prefix 308 field. 310 Reserved: 312 Sent as zero; ignored on reception. 314 Prefix: 316 32-bit unsigned integer in network byte-order containing an 317 IPv4 address whose first Prefix Length bits make up the 318 Mobile Network Prefix. 320 5. Mobile Router Operation 322 A Mobile Router's operation is generally derived from the behavior of 323 a Mobile Node, as set in RFC 3344 [RFC3344] and its update 324 [I-D.ietf-mip4-rfc3344bis]. In addition to maintaining mobility 325 bindings for its Home Address, the Mobile Router, together with the 326 Home Agent, maintains forwarding information for the Mobile Network 327 Prefix(es) assigned to the Mobile Router. 329 A Mobile Router SHOULD set the 'T' bit to 1 in all Registration 330 Request messages it sends to indicate the need for reverse tunnels 331 for all traffic. Without reverse tunnels, all the traffic from the 332 mobile network will be subject to ingress filtering in the visited 333 networks. Upon reception of a successful Registration Reply, the 334 Mobile Router processes the registration in accordance to RFC 3344 335 [RFC3344]. In addition, the following steps are taken: 337 o Check for Mobile Network Acknowledgement extension(s) in 338 Registration Reply 340 o Create tunnel to the Home Agent if registered in reverse tunneling 341 mode 343 o Set up default route via this tunnel or egress interface when 344 registered with or without reverse tunneling, respectively 346 In accordance with this specification, a Mobile Router may operate in 347 one of the following two modes: explicit and implicit. In explicit 348 mode, the Mobile Router includes Mobile Network Prefix information in 349 all Registration Requests (as Mobile Network Request extensions), 350 while in implicit mode it does not include this information in any 351 Registration Request. In this latter case, the Home Agent obtains 352 the Mobile Network Prefixes by other means than Mobile IP. One 353 example of obtaining the Mobile Network Prefix is through static 354 configuration on the Home Agent. 356 A Mobile Router can obtain a Collocated or Foreign Agent Care-of 357 Address while operating in explicit or implicit modes. 359 For de-registration, the Mobile Router sends a registration request 360 with lifetime set to zero without any Mobile Network Request 361 extensions. 363 5.1. Error Processing 365 A Mobile Router interprets the values of the Code field in the Mobile 366 Network Acknowledgement Extension of the Registration Reply in order 367 to identify any error related to managing the Mobile Network Prefixes 368 by the Home Agent. 370 If the value of the Code field in the Registration Reply is set to 371 HA_MOBNET_DISALLOWED, then the Mobile Router MUST stop sending 372 Registration Requests with any Mobile Network Prefix extensions to 373 that Home Agent. 375 If the value of the Code field in the Registration Reply is set to 376 HA_MOBNET_ERROR then the Mobile Router MUST stop sending Registration 377 Requests that contain any of the Mobile Network Prefixes that are 378 defined by the values of the fields Prefix and Prefix Length in the 379 Mobile Network Acknowledgement extension. Note that the registration 380 is denied in this case and no forwarding for any Mobile Network 381 Prefixes would be set up by the Home Agent for the Mobile Router. 383 It is possible that the Mobile Router receives a Registration Reply 384 with no mobile network extensions if the registration was processed 385 by a Mobile IPv4 home agent that does not support this specification 386 at all. In that case, the absence of mobile network extensions must 387 be interpreted by the Mobile Router as the case where the Home Agent 388 does not support mobile networks. 390 All the error code values are TBA (To Be Assigned) subject to IANA 391 allocation. 393 6. Home Agent Operation 395 6.1. Summary 397 A Home Agent MUST support all the operations specified in RFC 3344 398 [RFC3344] and its update [I-D.ietf-mip4-rfc3344bis] for Mobile Node 399 support. The Home Agent MUST support both implicit and explicit 400 modes of operation for a Mobile Router. 402 The Home Agent processes the registration in accordance to RFC 3344 404 [RFC3344], which includes route set up to the Mobile Router's Home 405 Address via the tunnel to the Care-of Address. In addition, for a 406 Mobile Router registering in explicit mode, the following steps are 407 taken: 409 1. Check that the Mobile Network Prefix information is valid 411 2. Ensure the Mobile Network Prefix(es) is or are authorized to be 412 on the Mobile Router 414 3. Create tunnel to the Mobile Router if it does not already exist 416 4. Set up route for the Mobile Network Prefix via this tunnel 418 5. Propagate Mobile Network Prefix routes via routing protocol if 419 necessary 421 6. Send the Registration Reply with the Mobile Network 422 Acknowledgement extension(s) 424 If there are any subnet routes via the tunnel to the Mobile Router 425 that are not specified in the Mobile Network extensions, these routes 426 are removed. 428 In the case where the Mobile Node is not permitted to act as a Mobile 429 Router, the Home Agent sends a registration denied message with error 430 code HA_MOBNET_DISALLOWED. 432 For a Mobile Router registering in implicit mode, the Home Agent 433 performs steps 3-6 above, once the registration request is processed 434 successfully. 436 For deregistration, the Home Agent removes the tunnel to the Mobile 437 Router and all routes using this tunnel. The Mobile Network 438 extensions are ignored. 440 6.2. Data Structures 442 6.2.1. Registration Table 444 The Registration Table in the Home Agent, in accordance with RFC 3344 445 [RFC3344] and its update [I-D.ietf-mip4-rfc3344bis], contains binding 446 information for every Mobile Node registered with it. RFC 3344 447 [RFC3344] and its update [I-D.ietf-mip4-rfc3344bis] define the format 448 of a Registration Table. In addition to all the parameters specified 449 by RFC 3344 [RFC3344] and its update [I-D.ietf-mip4-rfc3344bis], the 450 Home Agent MUST store the Mobile Network Prefixes associated with the 451 Mobile Router in the corresponding registration entry, when the 452 corresponding registration was performed in explicit mode. When the 453 Home Agent is advertising reachability to Mobile Network Prefixes 454 served by a Mobile Router, the information stored in the Registration 455 Table can be used. 457 6.2.2. Prefix Table 459 The Home Agent must be able to authorize a Mobile Router for use of 460 Mobile Network Prefixes when the Mobile Router is operating in 461 explicit mode. Also, when the Mobile Router operates in implicit 462 mode, the Home Agent must be able to locate the Mobile Network 463 Prefixes associated with that Mobile Router. The Home Agent may 464 store the Home Address of the Mobile Router along with the mobile 465 network prefixes associated with that Mobile Router. If the Mobile 466 Router does not have a Home Address assigned, this table may store 467 the NAI RFC 2794 [RFC2794] of the Mobile Router that will be used in 468 dynamic Home Address assignment. 470 6.3. Mobile Network Prefix Registration 472 The Home Agent must process registration requests coming from Mobile 473 Routers in accordance with this section. The document RFC 3344 474 [RFC3344] and its update [I-D.ietf-mip4-rfc3344bis] specify that the 475 Home Address of a mobile node registering with a Home Agent must 476 belong to a prefix advertised on the home network. In accordance 477 with this specification, however, the Home Address must be configured 478 from a prefix that is served by the Home Agent, not necessarily the 479 one on the home network. 481 If the registration request is valid, the Home Agent checks to see if 482 there are any Mobile Network Prefix extensions included in the 483 Registration Request. 485 If so, the Mobile Network Prefix information is obtained from the 486 included extensions, and the Home Address from the Home Address field 487 of the Registration Request. For every Mobile Network Prefix 488 extension included in the registration request, the Home Agent MUST 489 perform a check against the Prefix Table. If the Prefix Table does 490 not contain at least one entry pairing that Home Address to that 491 Mobile Network Prefix then the check fails, otherwise it succeeds. 493 Following this check against the Prefix Table, the Home Agent MUST 494 construct a Registration Reply containing Mobile Network 495 Acknowledgement extensions. For a Mobile Network Prefix for which 496 the check was unsuccessfull the Code field in the corresponding 497 Mobile Network Acknowledgement extension should be set to 498 MOBNET_UNAUTHORIZED. 500 For a Mobile Network Prefix for which the check was successfull the 501 Code field in the respective Mobile Network Acknowledgement 502 extensions should be set to 0. 504 The Home Agent MUST attempt to set up forwarding for each Mobile 505 Network Prefix extension for which the Prefix Table check was 506 successfull. If the forwarding setup fails for a particular Mobile 507 Network Prefix (for reasons like not enough memory available, or not 508 enough devices available, or other similar) the Code field in the 509 respective Mobile Network Acknowledgement extension should be set to 510 MOBNET_FWDING_SETUP_FAILED. 512 If forwarding and setup was successful for at least one Mobile 513 Network Prefix then the Code field of the Registration Reply message 514 should be set to 0. Otherwise that Code should be HA_MOBNET_ERROR. 516 If the registration request is sent in implicit mode, i.e., without 517 any Mobile Network Request extension, the Home Agent may use pre- 518 configured mobile network prefix information for the Mobile Router to 519 set up forwarding. 521 If the Home Agent is updating an existing binding entry for the 522 Mobile Router, it MUST check all the prefixes in the registration 523 table against the prefixes included in the registration request. If 524 one or more mobile network prefix is missing from the included 525 information in the registration request, it MUST delete those 526 prefixes from the registration table. Also, the Home Agent MUST 527 disable forwarding for those prefixes. 529 If all checks are successful, the Home Agent either creates a new 530 entry for the Mobile Router or updates an existing binding entry for 531 it and returns a successful registration reply back to the Mobile 532 Router or the Foreign Agent (if the registration request was received 533 from a Foreign Agent). 535 In accordance with RFC 3344 [RFC3344], the Home Agent does proxy ARP 536 for the Mobile Router Home Address, when the Mobile Router Home 537 Address is derived from the home network. 539 If the 'T' bit is set, the Home Agent creates a bi-directional tunnel 540 for the corresponding mobile network prefixes or updates the existing 541 bi-directional tunnel. This tunnel is maintained independent of the 542 reverse tunnel for the Mobile Router home address itself. 544 6.4. Advertising Mobile Network Reachability 546 If the mobile network prefixes served by the Home Agent are 547 aggregated with the home network prefix and if the Home Agent is the 548 default router on the home network, the Home Agent does not have to 549 advertise the Mobile Network Prefixes. The routes for the Mobile 550 Network Prefix are automatically aggregated into the home network 551 prefix (it is assumed that the Mobile Network Prefixes are 552 automatically aggregated into the home network prefix). If the 553 Mobile Router updates the mobile network prefix routes via a dynamic 554 routing protocol, the Home Agent SHOULD propagate the routes on the 555 appropriate networks. 557 6.5. Establishment of Bi-directional Tunnel 559 The Home Agent creates and maintains a bi-directional tunnel for the 560 mobile network prefixes of a Mobile Router registered with it. A 561 home agent supporting IPv4 Mobile Router operation MUST be able to 562 forward packets destined to the mobile network prefixes served by the 563 Mobile Router to its Care-of Address. Also, the Home Agent MUST be 564 able to accept packets tunneled by the Mobile Router with the source 565 address of the outer header set to the Care-of Address of the Mobile 566 Router and that of the inner header set to the Mobile Router's Home 567 Address or an address from one of the registered mobile network 568 prefixes. 570 6.6. Sending Registration Replies 572 The Home Agent MUST set the status code in the registration reply to 573 0 to indicate successful processing of the registration request and 574 successful set up of forwarding for all the mobile network prefixes 575 served by the Mobile Router. The registration reply MUST contain at 576 least one Mobile Network Acknowledgement extension. 578 If the Home Agent is unable to set up forwarding for one of more 579 mobile network prefixes served by the Mobile Router, it MUST set the 580 Mobile Network Acknowledgement Extension status code in the 581 registration reply to MOBNET_FWDING_SETUP_FAILED. When the prefix 582 length is zero or greater than 32, the status code MUST be set to 583 MOBNET_INVALID_PREFIX_LEN. 585 If the Mobile Router is not authorized to forward packets to one or 586 mobile network prefixes included in the request, the Home Agent MUST 587 set the code to MOBNET_UNAUTHORIZED_MR. 589 6.7. Mobile Network Prefix De-registration 591 If the received registration request is for de-registration of the 592 Care-of Address, the Home Agent, upon successful processing of it, 593 MUST delete the entry(ies) from its registration table. The home 594 agent tears down the bi-directional tunnel and stops forwarding any 595 packets to/from the Mobile Router. The Home Agent MUST ignore any 596 included Mobile Network Request extension in a de-registration 597 request. 599 7. Data Forwarding Operation 601 For traffic to the nodes in the Mobile Network, the Home Agent MUST 602 perform double tunneling of the packet, if the Mobile Router had 603 registered with a Foreign Agent Care-of Address. In this case, the 604 Home Agent MUST encapsulate the packet with tunnel header (source IP 605 address set to Home Agent and destination IP address set to Mobile 606 Router's Home Address) and then encapsulate one more time with tunnel 607 header (source IP address set to Home Agent and destination IP 608 address set to CoA). 610 For optimization, the Home Agent SHOULD only encapsulate the packet 611 with the tunnel header (source IP address set to Home Agent and 612 destination IP address set to CoA) for Collocated CoA mode. 614 When a Home Agent receives a packet from the mobile network prefix in 615 the bi-directional tunnel, it MUST de-encapsulate the packet and 616 route it as a normal IP packet. It MUST verify that the incoming 617 packet has the source IP address set to the Care-of Address of the 618 Mobile Router. The packet MUST be dropped if the source address is 619 not set to the Care-of Address of the Mobile Router. 621 For traffic from the nodes in the Mobile Network, the Mobile Router 622 encapsulates the packet with a tunnel header (source IP address set 623 to Mobile Router's Home Address and destination IP address set to 624 Home Agent) if reverse tunnel is enabled. Otherwise, the packet is 625 routed directly to the Foreign Agent or access router. 627 In Collocated CoA mode, the Mobile Router MAY encapsulate one more 628 times with a tunnel header (source IP address set to the CoA and 629 destination IP address set to Home Agent). 631 8. Nested Mobile Networks 633 Nested Network Mobility is a scenario where a Mobile Router allows 634 another Mobile Router to attach to its Mobile Network. There could 635 be arbitrary levels of nested mobility. The operation of each Mobile 636 Router remains the same whether the Mobile Router attaches to another 637 Mobile Router or to a fixed Access Router on the Internet. The 638 solution described here does not place any restriction on the number 639 of levels for nested mobility. Two issues should be noted though. 640 First, whenever physical loops occur in a nested aggregation of 641 mobile networks this protocol does neither detect nor solve them - 642 datagram forwarding may be blocked. Second, Mobile Routers in a deep 643 nested aggregation of mobile networks might introduce significant 644 overhead on the data packets as each level of nesting introduces 645 another tunnel header encapsulation. 647 9. Routing Protocol between Mobile Router and Home Agent 649 There are several benefits of running a dynamic routing protocol 650 between the Mobile Router and the Home Agent. If the mobile network 651 is relatively large, including several wireless subnets, then the 652 topology changes within the moving network can be exposed from the 653 Mobile Router to the Home Agent by using a dynamic routing protocol. 654 The purpose of the NEMOv4 protocol extensions to Mobile IPv4, as 655 defined in previous sections, is not to inform the Home Agent about 656 these topology changes, but to manage the mobility of the Mobile 657 Router. 659 Similarly, topology changes in the home network can be exposed to the 660 Mobile Router by using a dynamic routing protocol. This may be 661 necessary when new fixed networks are added in the home network. 662 Here too, the purpose of NEMOv4 extensions is not to inform the 663 Mobile Router about topology changes at home. 665 Examples of dynamic routing protocol include but are not limited to 666 OSPF Version 2 RFC 2328 [RFC2328], BGP RFC 4271 [RFC4271] and RIP 667 RFC 2453 [RFC2453]. 669 The recommendations are related to how the routing protocol and the 670 Mobile IPv4 implementation work in tandem on the Mobile Router and on 671 the Home Agent (1) without creating incoherent states in the 672 forwarding information bases at home and on the Mobile Router, (2) 673 without introducing topologically incorrect addressing information in 674 the visited domain and (3) efficiently avoid duplication of sent data 675 or over-provisioning of security. 677 The information exchanged between the Mobile Router and the Home 678 Agent is sent over the bi-directional tunnel established by the 679 Mobile IPv4 exchange Registration Request - Registration Reply (see 680 Section 6.5). If a network address and prefix about a subnet in the 681 moving network is sent by the Mobile Router within a routing protocol 682 message then they SHOULD NOT be sent in the Mobile IPv4 Registration 683 Request too, in order to avoid incoherencies in the forwarding 684 information bases. The Mobile Router SHOULD use NEMOv4 implicit mode 685 in this case (see Section 3). 687 The Mobile Router SHOULD NOT send routing protocol information 688 updates in the foreign network. The subnet addresses and prefixes 689 valid in the moving network are topologically incorrect in the 690 visited network. 692 If the Mobile Router and the Home Agent use a dynamic routing 693 protocol over the tunnel interface, and if that protocol offers 694 security mechanisms to protect that protocol's messages, then the 695 security recommendations in Section 10.1 apply. 697 10. Security Considerations 699 The Mobile Network extension is protected by the same rules for 700 Mobile IP extensions in registration messages. See the Security 701 Considerations section in RFC 3344 [RFC3344]. 703 The Home Agent MUST be able to verify that the Mobile Router is 704 authorized to provide mobility service for the Mobile Networks in the 705 registration request, before anchoring these Mobile Network Prefixes 706 on behalf of the Mobile Router. Forwarding for prefixes MUST NOT be 707 set up without successful authorization of the Mobile Router for 708 those prefixes. A registration failure MUST be notified to the 709 mobile router when it cannot be successfully authorized for prefixes 710 requested by it. 712 All registration requests and replies MUST be authenticated by the 713 MN-HA Authentication Extension as specified in RFC 3344 [RFC3344] and 714 its update [I-D.ietf-mip4-rfc3344bis]. When the registration request 715 is sent in explicit mode, i.e., with one or more Mobile Network 716 Prefix extensions, all the Mobile Network Prefix extensions MUST be 717 included before the MN-HA Authentication extension. Also, these 718 extensions MUST be included in the calculation of the MN-HA 719 authenticator value. 721 The Mobile Router should perform ingress filtering on all the packets 722 received on the mobile network prior to reverse tunneling them to the 723 Home Agent. The Mobile Router MUST drop any packets that do not have 724 a source address belonging to the mobile network. 726 The Mobile Router MUST also ensure that the source address of packets 727 arriving on the mobile network is not the same as the Mobile Router's 728 IP address on any interface. These checks will protect against nodes 729 attempting to launch IP spoofing attacks through the bi-directional 730 tunnel. 732 The Home Agent, upon receiving packets through the bi-directional 733 tunnel, MUST verify that the source addresses of the outer IP header 734 of the packets are set to the Mobile Router's care-of-address. Also, 735 it MUST ensure that the source address of the inner IP header is a 736 topologically correct address on the mobile network. This will 737 prevent nodes from using the Home Agent to launch attacks inside the 738 protected network. 740 10.1. Security when Dynamic Routing Protocol is Used 742 If a dynamic routing protocol is used between the Mobile Router and 743 the Home Agent to propagate the mobile network information into the 744 home network, the routing updates SHOULD be protected with IPsec ESP 745 confidentiality between the Mobile Router and Home Agent, to prevent 746 information about home network topology from being visible to 747 eavesdroppers. 749 11. IANA Considerations 751 IANA to modify rules for the existing registry "Mobile IPv4 numbers - 752 per RFC 3344". The numbering space for Extensions that may appear in 753 Mobile IP control messages (those sent to and from UDP port number 754 434) should be modified. 756 The new Values and Names for the Type for Extensions appearing in 757 Mobile IP control messages are the following: 759 +-------+---------------------------------------------------+ 760 | Value | Name | 761 +-------+---------------------------------------------------+ 762 | TBA | Mobile Network Extension (To Be Assigned by IANA) | 763 +-------+---------------------------------------------------+ 765 Table 1: New Values and Names for Extensions in Mobile IP Control 766 Messages 768 A new number space should be created for the Values and Names for the 769 Sub-Type for Mobile Network Extensions. This number space is 770 initially defined to hold the following entries, allocated by this 771 document: 773 +-------+-----------------------------------------+ 774 | Value | Name | 775 +-------+-----------------------------------------+ 776 | TBA | Mobile Network Request Extension | 777 | TBA | Explicit Mode Acknowledgement Extension | 778 | TBA | Implicit Mode Acknowledgement Extension | 779 +-------+-----------------------------------------+ 781 Table 2: New Values and Names for the Sub-Type for Mobile Network 782 Extensions 784 The policy of future assignments to this number space should be 785 following Standards Action or IESG Approval (see 786 [I-D.narten-iana-considerations-rfc2434bis]). 788 The new Code Values for Mobile IP Registration Reply messages are the 789 following (for a registration denied by the Home Agent): 791 +-------+-----------------------------------------------------------+ 792 | Value | Name | 793 +-------+-----------------------------------------------------------+ 794 | TBA | Mobile Network Prefix operation error (HA_MOBNET_ERROR) | 795 | TBA | Mobile Router operation is not permitted | 796 | | (HA_MOBNET_DISALLOWED) | 797 +-------+-----------------------------------------------------------+ 799 Table 3: New Code Values for Mobile IP Registration Reply 801 A new number space should be created for the Code Values for the 802 Mobile Network Acknowledgement Extension. This number space is 803 initially defined to hold the following entries, allocated by this 804 document (result of registration, as sent by the Home Agent): 806 +-----+-------------------------------------------------------------+ 807 | TBA | Success | 808 | TBA | Invalid prefix length (MOBNET_INVALID_PREFIX_LEN) | 809 | TBA | Mobile Router is not authorized for prefix | 810 | | (MOBNET_UNAUTHORIZED) | 811 | TBA | Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) | 812 +-----+-------------------------------------------------------------+ 814 Table 4: New Code Values for Mobile Network Acknowledgement Extension 816 The policy of future assignments to this number space should be 817 following Standards Action or IESG Approval (see 818 [I-D.narten-iana-considerations-rfc2434bis]). 820 The current non-modified numbering spaces could be consulted at the 821 URL http://www.iana.org/assignments/mobileip-numbers (contents last 822 updated 2007-12-20 and last browsed 2008-01-04). 824 12. Acknowledgements 826 The authors would like to thank Christophe Janneteau, George 827 Popovich, Ty Bekiares, Ganesh Srinivasan, Alpesh Patel, Ryuji 828 Wakikawa, George Tsirtsis, and Henrik Levkowetz for their helpful 829 discussions, reviews and comments. Vijay Devarapalli extensively 830 reviewed one of the later versions of the draft. Hans Sjostrand 831 (Hans Sj\"ostrand) identified the last clarifications with respect to 832 Foreign Agent mode treatment. Pete McCann contributed necessary 833 refinements of many statements. 835 Mobile IPv4 versions as early as 1996 (RFC 2002) described Mobile 836 Networks and Mobile Routers support. Charles Perkins. 838 13. References 840 13.1. Normative References 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, March 1997. 845 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 847 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 848 November 1998. 850 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 851 Identifier Extension for IPv4", RFC 2794, March 2000. 853 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 854 August 2002. 856 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 857 Protocol 4 (BGP-4)", RFC 4271, January 2006. 859 13.2. Informative References 861 [I-D.ietf-mip4-nemov4-fa] 862 Tsirtsis, G., Park, V., Narayanan, V., and K. Leung, "FA 863 extensions to NEMOv4 Base", draft-ietf-mip4-nemov4-fa-01 864 (work in progress), November 2007. 866 [I-D.ietf-mip4-rfc3344bis] 867 Perkins, C., "IP Mobility Support for IPv4, revised", 868 draft-ietf-mip4-rfc3344bis-05 (work in progress), 869 July 2007. 871 [I-D.narten-iana-considerations-rfc2434bis] 872 Narten, T. and H. Alvestrand, "Guidelines for Writing an 873 IANA Considerations Section in RFCs", 874 draft-narten-iana-considerations-rfc2434bis-08 (work in 875 progress), October 2007. 877 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 878 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 879 RFC 3963, January 2005. 881 Appendix A. ChangeLog 883 The changes are listed in reverse chronological order, most recent 884 changes appearing at the top of the list. 886 From draft-ietf-mip4-nemo-v4-base-07.txt to 887 draft-ietf-mip4-nemo-v4-base-08.txt, following AD Review (Jari 888 Arkko): 890 o HA propagates Mobile Network Prefix only if necessary (previously 891 it was always doing it). 893 o emphasized that within nested mobile networks looping may occur 894 and this document doesn't do anything to address this. 896 o dropped a phrase which said that Mobile-Home auth extension 897 shouldn't be used when ESP protects the routing protocol message, 898 because that extension is only applied to Registration messages 899 (not tunneled data, which usually contains routing protocol 900 exchange). 902 o recommending "Standards Action or IESG Review" instead of "Expert 903 Review" for this numbering space, and added reference to a draft 904 for 2434bis. 906 o editorial: re-phrased about how Mobile IPv4 claimed mobile 907 networks support. 909 o editorial: added a necessary paragraph in the Acknowledgements 910 section. 912 From draft-ietf-mip4-nemo-v4-base-06.txt to 913 draft-ietf-mip4-nemo-v4-base-07.txt 914 o encoded the draft into xml. Compiled with xml2rfc version 915 1.33pre4. 917 o checked against 'idnits' script version 2.05.03. 919 o substituted 'Care-of Address' for 'CoA'. 921 From draft-ietf-mip4-nemo-v4-base-05.txt to 922 draft-ietf-mip4-nemo-v4-base-06.txt 924 o substituted "TBA" for "1" in Sub-type of Mobile Network Request 925 Extension. 927 o substituted "TBA" for "0" in Code of Mobile Network 928 Acknowledgement Extension and in the IANA Section. 930 o modified the IANA section to request definition two new spaces 931 (instead of just defining new values) for Sub-Type of Mobile 932 Network Extensions and for Code Values for Mobile Network 933 Acknowledgement Extension, and to suggest "Expert Review" as 934 method of new assignments in these two spaces (and not necessarily 935 "IETF Consensus"). 937 From draft-ietf-mip4-nemo-v4-base-04.txt to 938 draft-ietf-mip4-nemo-v4-base-05.txt 940 o updated the Acknowledgements section. 942 o capitalized all occurences of "Home Address", "Mobile Router" and 943 "Care-of Address". 945 o refined many statements. 947 o checked against 'idnits' script version 2.04.16. 949 From draft-ietf-mip4-nemo-v4-base-03.txt to 950 draft-ietf-mip4-nemo-v4-base-04.txt 952 o more changes in Introduction to say that with FA mode only the 953 non-optimized double-encapsulation operation is supported and 954 [I-D.ietf-mip4-nemov4-fa] proposes a optimization. 956 From draft-ietf-mip4-nemo-v4-base-02.txt to 957 draft-ietf-mip4-nemo-v4-base-03.txt 959 o changed a sentence in the Introduction to say that FA mode _is_ 960 supported but unoptimized, and that a reference 961 [I-D.ietf-mip4-nemov4-fa] optimizes that mode. 963 o added reference [I-D.ietf-mip4-rfc3344bis] to the rfc3344bis 964 draft. 966 From draft-ietf-mip4-nemo-v4-base-01.txt to 967 draft-ietf-mip4-nemo-v4-base-02.txt 969 o changed title from "IPv4 Network Mobility (NEMO) Protocol" to 970 "Network Mobility (NEMO) Extensions for Mobile IPv4". 972 From draft-ietf-mip4-nemo-v4-base-00.txt to 973 draft-ietf-mip4-nemo-v4-base-01.txt 975 o added a section on Routing Protocol between Mobile Router and Home 976 Agent. 978 o added a security subsection about running simultaneously a secure 979 routing protocol with secure Mobile IPv4. 981 o added a date tag on the IANA URL for Mobile IP numbering spaces. 983 o substituted 'Mobile Router' for 'MR' everywhere. 985 o updated reference to NEMOv4 FA draft. 987 From draft-ietf-nemo-v4-base-01.txt to 988 draft-ietf-mip4-nemo-v4-base-00.txt: 990 o changed draft name, headers and footers. 992 o changed title. 994 o a more coherent use of terms 'subnet', 'prefix' and 'mobile 995 network'. 997 o clarified only co-located CoA mode is supported (not FA CoA) for 998 Mobile Routers in this specification. And added reference to the 999 FA NEMO optimizations draft. 1001 o changed 'devices' to 'hosts'. 1003 o changed 'moving networks' to 'mobile networks'. 1005 o clarified what 'reachability' in a certain context is: packets may 1006 be dropped if ingress filtering is turned on. 1008 o removed the MR-FA-CoA tunnel overhead optimization. There is 1009 still an issue with text at HA doing optimization. 1011 This document was first presented as an individual contribution to 1012 the NEMO Working Group, then adopted as a WG item to that group. The 1013 01 version in the NEMO WG has been Last Called on the INFORMATIONAL 1014 track. The evolution was: 1016 From version draft-ietf-nemo-v4-base-00 to 1017 draft-ietf-nemo-v4-base-01: 1019 o removed error code HA_MOBNET_UNSUPPORTED. 1021 o changed all values to be assigned by IANA, from specific numbers 1022 to "TBA" (To Be Assigned). 1024 o substituted "egress interface" for "roaming interface". 1026 o changed HA behaviour upon reception of MNPs. In 00 the HA replied 1027 positively only if all MNPs in RegReq were valid, in 01 a reply is 1028 constructed specifying which MNP was valid and which not. 1030 o clarified a 3-line paragraph saying that RegRep may contain both 1031 implicit and explicit acknowledgements. 1033 Authors' Addresses 1035 Kent Leung 1036 Cisco Systems 1037 170 W. Tasman Drive 1038 San Jose, CA 95134 1039 USA 1041 Phone: +1 408-526-5030 1042 Email: kleung@cisco.com 1044 Gopal Dommety 1045 Cisco Systems 1046 170 W. Tasman Drive 1047 San Jose, CA 95134 1048 USA 1050 Phone: +1 408-525-1404 1051 Email: gdommety@cisco.com 1052 Vidya Narayanan 1053 QUALCOMM, Inc. 1054 5775 Morehouse Dr 1055 San Diego, CA 1056 USA 1058 Phone: +1 858-845-2483 1059 Email: vidyan@qualcomm.com 1061 Alexandru Petrescu 1062 Motorola 1063 Parc les Algorithmes Saint Aubin 1064 Gif-sur-Yvette, Essonne 91140 1065 France 1067 Phone: +33 169354827 1068 Email: alexandru.petrescu@motorola.com 1070 Full Copyright Statement 1072 Copyright (C) The IETF Trust (2008). 1074 This document is subject to the rights, licenses and restrictions 1075 contained in BCP 78, and except as set forth therein, the authors 1076 retain all their rights. 1078 This document and the information contained herein are provided on an 1079 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1080 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1081 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1082 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1083 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1084 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1086 Intellectual Property 1088 The IETF takes no position regarding the validity or scope of any 1089 Intellectual Property Rights or other rights that might be claimed to 1090 pertain to the implementation or use of the technology described in 1091 this document or the extent to which any license under such rights 1092 might or might not be available; nor does it represent that it has 1093 made any independent effort to identify any such rights. Information 1094 on the procedures with respect to rights in RFC documents can be 1095 found in BCP 78 and BCP 79. 1097 Copies of IPR disclosures made to the IETF Secretariat and any 1098 assurances of licenses to be made available, or the result of an 1099 attempt made to obtain a general license or permission for the use of 1100 such proprietary rights by implementers or users of this 1101 specification can be obtained from the IETF on-line IPR repository at 1102 http://www.ietf.org/ipr. 1104 The IETF invites any interested party to bring to its attention any 1105 copyrights, patents or patent applications, or other proprietary 1106 rights that may cover technology that may be required to implement 1107 this standard. Please address the information to the IETF at 1108 ietf-ipr@ietf.org. 1110 Acknowledgment 1112 Funding for the RFC Editor function is provided by the IETF 1113 Administrative Support Activity (IASA).