idnits 2.17.00 (12 Aug 2021) /tmp/idnits22920/draft-acee-mip4-bulk-revocation-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 636. 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 (August 3, 2007) is 5405 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 (ref. 'MIP4') (Obsoleted by RFC 5944) -- Possible downref: Non-RFC (?) normative reference: ref. 'REG-EXPR' Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft A. Oswal 4 Intended status: Standards Track Redback Networks 5 Expires: February 4, 2008 August 3, 2007 7 Bulk Registration Revocation in Mobile IPv4 8 draft-acee-mip4-bulk-revocation-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 4, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes an extension to Mobile IPv4 Registration 42 Revocation (as described in RFC 3543) for a home or foreign agent to 43 revoke mobile IP services for multiple bindings or visitors with a 44 single registration revocation exchange. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 50 2. Registration Revocation Extensions and Messages . . . . . . . 4 51 2.1. Revocation Support Extension Changes . . . . . . . . . . . 4 52 2.2. Revocation Selection Extension . . . . . . . . . . . . . . 5 53 2.3. Registration Revocation Message Changes . . . . . . . . . 8 54 2.4. Registration Revocation Acknowledgment Message Changes . . 10 55 2.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 11 56 3. Bulk Registration Revocation Overview . . . . . . . . . . . . 12 57 3.1. Home Agent Responsibilities . . . . . . . . . . . . . . . 12 58 3.2. Foreign Agent Responsibilities . . . . . . . . . . . . . . 12 59 3.3. Direct Co-located Node Responsibilities . . . . . . . . . 13 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 62 6. Normative References . . . . . . . . . . . . . . . . . . . . . 16 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 65 Intellectual Property and Copyright Statements . . . . . . . . . . 19 67 1. Introduction 69 This document describes an extension to Mobile IPv4 Registration 70 Revocation (as described in [REVOCATION]) for a home or foreign agent 71 to revoke mobile IP services for multiple bindings or visitors with a 72 single registration revocation exchange. 74 1.1. Requirements notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC-KEYWORDS]. 80 2. Registration Revocation Extensions and Messages 82 The following changes are required for bulk revocation. 84 1. The revocation support extension will include a bit indicating 85 whether or not the agent supports bulk revocation. 87 2. The Registration Revocation and Registration Revocation 88 Acknowledgment will include a bit indicating whether or not the 89 registration is a bulk registration. If so, the Home Agent 90 Address will include a prefix rather than a specific mobile 91 node's home address. Additionally, a previously reserved field 92 will now include the prefix length. 94 3. A non-skippable revocation selection extension is added to 95 further qualify bulk Registration Revocation. 97 2.1. Revocation Support Extension Changes 99 The Mobile IP Revocation Support Extension indicates support of 100 registration revocation, and so MUST be attached to a Registration 101 Request or Registration Reply by any entity that wants to receive 102 revocation messages. The extension is fully described in 103 [REVOCATION]. This document includes an indication of whether or not 104 bulk revocation is supported for this registration. Alternately, 105 bulk revocation could be negotiated globally between the mobility 106 agents using a mechanism beyond the scope of this specification. 108 The format of the Revocation Support Extension is based on the Type- 109 Length-Value Extension Format given in [MIP4] and is defined in 110 [REVOCATION]. Changes are described below: 112 0 1 2 3 113 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 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Type | Length |I|B| Reserved | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Timestamp | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 Revocation Support Extension 122 Changes to the Revocation Support Extension are: 124 Type 125 137 - Unchanged from [REVOCATION] 127 Length 128 Unchanged from [REVOCATION] 130 Timestamp 131 Unchanged from [REVOCATION] 133 'I' Bit 134 Unchanged from [REVOCATION] 136 'B' Bit 137 This bit is set to '1' by a mobility agent to indicate that bulk 138 revocation (as specified herein) is applicable to this binding. 140 Reserved 141 Reserved for future use. MUST be set to 0 on sending, MUST be 142 ignored on receiving. 144 The Mobile IP Revocation Support Extension may appear in either a 145 Registration Request or Registration Reply. 'B' bit or bulk 146 revocation support will only be in force when negotiated by both 147 agents through either the setting of the 'B' bit or a global 148 mechanism beyond the scope of this specification. 150 2.2. Revocation Selection Extension 152 The Mobile IP Revocation Selection Extension is used to further 153 qualify bulk revocation (as described herein). It is only applicable 154 to the Registration Revocation and Registration Revocation 155 Acknowledgement messages. 157 The format of the Revocation Selection Extension is based on the 158 Type-Length-Sub-Type-Value Short Extension Format described in 159 [MIP4]. It further qualifies the selection of revoked registrations 160 specified herein. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Type | Length | Sub-Type | Data .... 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 o 168 Dependent on Sub-Type 169 o 171 Revocation Selection Extension 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+ 176 | Reserved | 177 +-+-+-+-+-+-+-+-+ 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Starting Home IP Address | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Ending Home IP Address | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Start/End Home IP Address Sub-Type Variable Format 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+ 189 | Regular ... 190 +-+-+-+-+-+-+-+-+ 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 ... Expression | 194 o 195 Variable Length Regular Expression 196 o 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 NAI Regular Expression Sub-Type Variable Format 202 0 1 2 3 203 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 204 Tunnel Encapsulation Sub-Type 205 +-+-+-+-+-+-+-+-+ 206 | Protocol ID | 207 +-+-+-+-+-+-+-+-+ 209 Tunnel Encapsulation Sub-Type Variable Format 211 Revocation Selection Extension fields include: 213 Type 214 Non-skippable = TBD 216 Length 217 Depends on the selection algorithm specified. 219 Sub-Type 220 Indicates the type of additional selection specified: 222 1 - Start/End Home IP Address 223 Indicates the TLV contains a starting and ending home IP 224 address used to further qualify registration selection. For 225 this sub-type, the length of the TLV will be 10 bytes. 227 2 - NAI Regular Expression 228 Indicates the TLV contains a regular expression applied to the 229 NAI (Network Access Identifier). This field is only limited by 230 the single byte length. Hence, it can be up to 254 octets in 231 length given that the sub-type takes 1 octet. 233 3 - Encapsulation 234 Indicates the TLV contains a tunnel encapsulation protocol 235 identifier. This indicates that the bulk revocation only 236 applies to registrations using the specified tunnel 237 encapsulation. For this sub-type, the length of the TLV will 238 be 2 bytes. 240 Reserved 241 Reserved for future use. MUST be set to 0 on sending, MUST be 242 ignored on receiving. 244 Starting Home IP Address 245 The starting address in a range of IP home addresses whose 246 registrations are to be revoked. 248 Ending Home IP Address 249 The ending address in a range of IP home addresses whose 250 registrations are to be revoked. 252 NAI Regular Expression 253 A regular expression to be matched against the Network Address 254 Identifier (NAI) for registration to determine which registrations 255 are to be revoked. Refer to [NAI] for information on Mobile IP 256 Network Access Identifiers. Refer to [REG-EXPR] for information 257 on regular expressions. 259 Protocol ID 260 The protocol ID corresponding to the tunnel encapsulation: 262 94 263 IP-in-IP encapsulation [IP-IN-IP] 265 47 266 Generic Routing Encapsulation (GRE) [GRE] 268 55 269 Minimal IP Encapsulation [MIN-IP] 271 The Mobile IP revocation selection extension may appear in either a 272 Registration Revocation or Registration Revocation Acknowledgement 273 message. 275 2.3. Registration Revocation Message Changes 277 The Registration Revocation Message is fully described in 278 [REVOCATION]. The UDP header is followed by the Mobile IP fields 279 which are repeated herein with the changes described below: 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type | Reserved |A|I|B| Reserved| Prefix Length | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Home Address/Prefix | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Home Domain Address | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Foreign Domain Address | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Revocation Identifier | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Extensions... 295 +-+-+-+-+-+-+-+-+-+-+-+-+- 296 | Authenticator... 297 +-+-+-+-+-+-+-+-+-+-+-+-+- 299 Registration Revocation Message Changes 301 Changes to the Registration Revocation message are: 303 Type 304 7 - Unchanged from [REVOCATION] 306 'I' Bit 307 Unchanged from [REVOCATION] 309 'A' Bit 310 Unchanged from [REVOCATION] 312 'B' Bit 313 This bit is set to '1' by a mobility agent to indicate that this 314 revocation message is a request for bulk revocation. Bulk 315 revocation may apply to one or many registrations. 317 Reserved 318 Reserved for future use. MUST be set to 0 on sending, MUST be 319 ignored on receiving. 321 Prefix Length 322 The prefix length which, when combined with the home prefix 323 specifies which registrations are to be revoked. If bulk 324 revocation is requested (as specified by the 'B' bit) and this 325 field is zero, the Registration Revocation applies to all 326 registrations for which bulk revocation was previously negotiated 327 using the Revocation Support Extension or a global mechanism 328 beyond the scope of this specification. 330 Reserved 331 Reserved for future use. MUST be set to 0 on sending, MUST be 332 ignored on receiving. 334 Home Address/Prefix 335 If bulk revocation is requested ('B' bit set to '1'), this field 336 is combined with the prefix length to select one or more 337 registrations to be revoked. If bulk revocation is not requested 338 ('B' bit set to '0'), this field specifies the home IP address of 339 the mobile node whose registration is being revoked. 341 Home Domain Address 342 Unchanged from [REVOCATION] 344 Foreign Domain Address 345 Unchanged from [REVOCATION] 347 Revocation ID 348 Unchanged from [REVOCATION] 350 The Registration Revocation message is processed as before only now 351 it can be applied to one or more active registrations between the 352 mobility agents. It must be authenticated as specified in 353 [REVOCATION]. 355 2.4. Registration Revocation Acknowledgment Message Changes 357 The Registration Revocation Acknowledgment Message is fully described 358 in [REVOCATION]. The UDP header is followed by the Mobile IP fields 359 which are repeated herein with the changes described below: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Type | Reserved |I|B| Reserved | Prefix Length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Home Address | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Revocation Identifier | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Extensions... 371 +-+-+-+-+-+-+-+-+-+-+-+-+- 372 | Authenticator... 373 +-+-+-+-+-+-+-+-+-+-+-+-+- 375 Registration Revocation Message Changes 377 Changes to the Registration Revocation Acknowledgement message are: 379 Type 380 15 - Unchanged from [REVOCATION] 382 'I' Bit 383 Unchanged from [REVOCATION] 385 'B' Bit 386 This bit is set to '1' by a mobility agent to indicate successful 387 revocation of at least one registration in response to the bulk 388 revocation request. 390 Reserved 391 Reserved for future use. MUST be set to 0 on sending, MUST be 392 ignored on receiving. 394 Prefix Length 395 The prefix length which, when combined with the home prefix 396 specifies which registrations were revoked. The prefix length 397 MUST match the length specified on the corresponding Registration 398 Revocation message. 400 Reserved 401 Reserved for future use. MUST be set to 0 on sending, MUST be 402 ignored on receiving. 404 Home Address/Prefix 405 If bulk revocation is requested ('B' bit set to '1'), this field 406 is combined with the prefix length to select one or more 407 registrations to be revoked. If bulk revocation is not requested 408 ('B' bit set to '0"), this field specifies the home IP address of 409 the mobile node whose registration is being revoked. It MUST 410 match the home address/prefix specified on the previous 411 Registration Revocation message. 413 Revocation ID 414 Unchanged from [REVOCATION] 416 A Registration Revocation Acknowledgment message MUST be sent in 417 response to a valid and authenticated registration revocation message 418 as specified in [REVOCATION]. 420 2.5. Replay Protection 422 Replay protection proceeds in much the same way as described in 423 [REVOCATION]. However, when assuring that the message is not a 424 replayed message, the mobility agent must check the timestamp to 425 assure it is greater than the timestamp received from the most 426 recently received Mobility Revocation Support extension from the 427 agent. One way to support this is to maintain the most recent per- 428 peer timestamp for peer mobility agents. For co-located mobile 429 nodes, there normally will be only one active registration 430 (situations where there are many are beyond the scope of this 431 document). 433 3. Bulk Registration Revocation Overview 435 Bulk Registration Revocation processing is identical to Registration 436 Revocation as described in [REVOCATION] except for following 437 differences: 439 1. When the Registration Request is received, bulk revocation 440 support is negotiated through the setting of the B-Bit in the 441 Revocation Support extension. This negotiation should not 442 preclude global bulk revocation negotiation between mobility 443 agents. However, such support is beyond the scope of this 444 document. 446 2. When a mobility agent processes a bulk Registration Revocation, 447 it may apply to multiple registrations. 449 3. The replay protection validation will now use the timestamp in 450 the most recent Revocation Support Extension from the sending 451 agent. This is described in Section 2.5. 453 3.1. Home Agent Responsibilities 455 Home Agent responsibilities are identical to [REVOCATION] except as 456 noted above. In situations where a single event may apply to 457 multiple registrations (or bindings on the Home Agent), a bulk 458 revocation may be sent in lieu of multiple revocations. A non- 459 exhaustive list of events that may benefit from bulk revocation 460 includes: 462 1. Graceful shutdown of the home agent (HA) instance 464 2. Policy changes that preclude communication with the Foreign Agent 465 (FA) 467 3. Withdrawn of the Home Agent local address from service 469 4. Home Address Pool deletion or change 471 5. Other policy change resulting in multiple registrations being 472 revoked 474 3.2. Foreign Agent Responsibilities 476 Foreign Agent responsibilities are identical to [REVOCATION] except 477 as noted above. In situations where a single event may apply to 478 multiple registrations (or visitors on the Foreign Agent), a bulk 479 revocation may be sent in lieu of multiple revocations. A non- 480 exhaustive list of events that may benefit from bulk revocation 481 includes: 483 1. Graceful shutdown of the foreign agent (FA) instance 485 2. Policy changes that preclude communication with the Home Agent 486 (HA) 488 3. Withdrawn of the Care-of-Address (CoA) from service 490 4. Other policy change resulting in multiple registrations being 491 revoked 493 3.3. Direct Co-located Node Responsibilities 495 In general, bulk revocation is not the useful to a direct co-located 496 node since it will usually only have single registration with a home 497 agent. Hence, there is really no reason for a direct co-located to 498 negotiate bulk revocation in the first place by setting the B-Bit in 499 the Revocation Support Extension appending to its initial 500 registration. However, this specification does not preclude support 501 and a direct co-located node negotiating bulk revocation must support 502 bulk revocation requests. 504 4. Security Considerations 506 Security is basically unchanged from [REVOCATION] with the exception 507 that replay protection will be based on the most recent registration 508 revocation received from the peer (as described in Section 2.5). As 509 with [REVOCATION], all message exchanges related to revocation MUST 510 be protected by either a valid authenticator as specified in [MIP4]. 511 For communications between mobility agents, FA-HA authentication or a 512 mechanism at least as secure, e.g. IPsec, is required. For 513 communication between a home agent and a direct co-located mobile 514 node, MN-HA authentication or a mechanism at least as secure is 515 required. In this context, all message exchanges relating to 516 revocation include Registration Revocations, Registration Revocation 517 Acknowledgments, Registration Requests including the Revocation 518 Support Extension, and Registration Replies including the Revocation 519 Support Extension. 521 5. IANA Considerations 523 A non-skippable extension value is needed for the Revocation 524 Selection Extension. This should be allocated from the "Extensions 525 appearing in Mobile IP messages" number space in the "Mobile IPv4 526 Numbers". Also, a new sub-registry is required for the sub-types for 527 this extension. Initially, it will have the following values: 529 1 - Start/End Home IP Address 530 Indicates the TLV contains a starting and ending home IP address 531 used to further qualify registration selection. 533 2 - NAI Regular Expression 534 Indicates the TLV contains a regular expression applied to the NAI 535 (Network Access Identifier). 537 3 - Encapsulation 538 Indicates the TLV contains a tunnel encapsulation protocol 539 identifier. 541 Refer to Section 2.2 for more information. 543 6. Normative References 545 [GRE] Farinacci, D., Li, T., Meyer, D., and P. Traina, "Generic 546 Routing Encapsulation", RFC 2784, March 2000. 548 [IP-IN-IP] 549 Perkins, C., "IP Encapsulation within IP", RFC 2003, 550 October 1996. 552 [MIN-IP] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 553 October 1996. 555 [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 556 August 2002. 558 [NAI] Johansson, F. and T. Johannsson, "Mobile IPv4 Extension 559 for Carrying Network Access Identifiers", RFC 3846, 560 June 2004. 562 [REG-EXPR] 563 Institute of Electrical and Electronix Engineers, 564 "Information Technology - Portable Operation System 565 Interface (POSIX) - Part 2: Shell and Variables (Vol. 566 1)", IEEE 1003.3, 1992. 568 [REVOCATION] 569 Chandra, M. and S. Glass, "Registration Revocation in 570 Mobile IPv4", RFC 3543, August 2003. 572 [RFC-KEYWORDS] 573 Bradner, S., "Key words for use in RFC's to Indicate 574 Requirement Levels", RFC 2119, March 1997. 576 Appendix A. Acknowledgments 578 The RFC text was produced using Marshall Rose's xml2rfc tool. 580 Authors' Addresses 582 Acee Lindem 583 Redback Networks 584 102 Carric Bend Court 585 Cary, NC 27519 586 USA 588 Email: acee@redback.com 590 Anand Oswal 591 Redback Networks 592 300 Holger 593 San Jose, CA 95134 594 USA 596 Email: aoswal@redback.com 598 Full Copyright Statement 600 Copyright (C) The IETF Trust (2007). 602 This document is subject to the rights, licenses and restrictions 603 contained in BCP 78, and except as set forth therein, the authors 604 retain all their rights. 606 This document and the information contained herein are provided on an 607 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 608 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 609 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 610 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 611 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 612 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 614 Intellectual Property 616 The IETF takes no position regarding the validity or scope of any 617 Intellectual Property Rights or other rights that might be claimed to 618 pertain to the implementation or use of the technology described in 619 this document or the extent to which any license under such rights 620 might or might not be available; nor does it represent that it has 621 made any independent effort to identify any such rights. Information 622 on the procedures with respect to rights in RFC documents can be 623 found in BCP 78 and BCP 79. 625 Copies of IPR disclosures made to the IETF Secretariat and any 626 assurances of licenses to be made available, or the result of an 627 attempt made to obtain a general license or permission for the use of 628 such proprietary rights by implementers or users of this 629 specification can be obtained from the IETF on-line IPR repository at 630 http://www.ietf.org/ipr. 632 The IETF invites any interested party to bring to its attention any 633 copyrights, patents or patent applications, or other proprietary 634 rights that may cover technology that may be required to implement 635 this standard. Please address the information to the IETF at 636 ietf-ipr@ietf.org. 638 Acknowledgment 640 Funding for the RFC Editor function is provided by the IETF 641 Administrative Support Activity (IASA).