idnits 2.17.1 draft-acee-mip4-bulk-revocation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 674. 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 (February 12, 2008) is 5910 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' == Outdated reference: A later version (-04) exists of draft-yegani-gre-key-extension-03 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: August 15, 2008 February 12, 2008 7 Bulk Registration Revocation in Mobile IPv4 8 draft-acee-mip4-bulk-revocation-01.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 August 15, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 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 2.6. GRE Key Applicability . . . . . . . . . . . . . . . . . . 11 57 3. Bulk Registration Revocation Overview . . . . . . . . . . . . 12 58 3.1. Home Agent Responsibilities . . . . . . . . . . . . . . . 12 59 3.2. Foreign Agent Responsibilities . . . . . . . . . . . . . . 12 60 3.3. Direct Co-located Node Responsibilities . . . . . . . . . 13 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 66 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 67 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18 68 B.1. Changes from 00 Version to 01 Version . . . . . . . . . . 18 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 70 Intellectual Property and Copyright Statements . . . . . . . . . . 20 72 1. Introduction 74 This document describes an extension to Mobile IPv4 Registration 75 Revocation (as described in [REVOCATION]) for a home or foreign agent 76 to revoke mobile IP services for multiple bindings or visitors with a 77 single registration revocation exchange. 79 1.1. Requirements notation 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC-KEYWORDS]. 85 2. Registration Revocation Extensions and Messages 87 The following changes are required for bulk revocation. 89 1. The revocation support extension will include a bit indicating 90 whether or not the agent supports bulk revocation. 92 2. The Registration Revocation and Registration Revocation 93 Acknowledgment will include a bit indicating whether or not the 94 registration is a bulk registration. If so, the Home Agent 95 Address will include a prefix rather than a specific mobile 96 node's home address. Additionally, a previously reserved field 97 will now include the prefix length. 99 3. A non-skippable revocation selection extension is added to 100 further qualify bulk Registration Revocation. 102 2.1. Revocation Support Extension Changes 104 The Mobile IP Revocation Support Extension indicates support of 105 registration revocation, and so MUST be attached to a Registration 106 Request or Registration Reply by any entity that wants to receive 107 revocation messages. The extension is fully described in 108 [REVOCATION]. This document includes an indication of whether or not 109 bulk revocation is supported for this registration. Alternately, 110 bulk revocation could be negotiated globally between the mobility 111 agents using a mechanism beyond the scope of this specification. 113 The format of the Revocation Support Extension is based on the Type- 114 Length-Value Extension Format given in [MIP4] and is defined in 115 [REVOCATION]. Changes are described below: 117 0 1 2 3 118 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 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Type | Length |I|B| Reserved | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Timestamp | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Revocation Support Extension 127 Changes to the Revocation Support Extension are: 129 Type 130 137 - Unchanged from [REVOCATION] 132 Length 133 Unchanged from [REVOCATION] 135 Timestamp 136 Unchanged from [REVOCATION] 138 'I' Bit 139 Unchanged from [REVOCATION] 141 'B' Bit 142 This bit is set to '1' by a mobility agent to indicate that bulk 143 revocation (as specified herein) is applicable to this binding. 145 Reserved 146 Reserved for future use. MUST be set to 0 on sending, MUST be 147 ignored on receiving. 149 The Mobile IP Revocation Support Extension may appear in either a 150 Registration Request or Registration Reply. 'B' bit or bulk 151 revocation support will only be in force when negotiated by both 152 agents through either the setting of the 'B' bit or a global 153 mechanism beyond the scope of this specification. 155 2.2. Revocation Selection Extension 157 The Mobile IP Revocation Selection Extension is used to further 158 qualify bulk revocation (as described herein). It is only applicable 159 to the Registration Revocation and Registration Revocation 160 Acknowledgement messages. 162 The format of the Revocation Selection Extension is based on the 163 Type-Length-Sub-Type-Value Short Extension Format described in 164 [MIP4]. It further qualifies the selection of revoked registrations 165 specified herein. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type | Length | Sub-Type | Data .... 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 o 173 Dependent on Sub-Type 174 o 176 Revocation Selection Extension 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+ 181 | Reserved | 182 +-+-+-+-+-+-+-+-+ 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Starting Home IP Address | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Ending Home IP Address | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Start/End Home IP Address Sub-Type Variable Format 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+ 194 | Regular ... 195 +-+-+-+-+-+-+-+-+ 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 ... Expression | 199 o 200 Variable Length Regular Expression 201 o 202 | | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 NAI Regular Expression Sub-Type Variable Format 207 0 1 2 3 208 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 209 Tunnel Encapsulation Sub-Type 210 +-+-+-+-+-+-+-+-+ 211 | Protocol ID | 212 +-+-+-+-+-+-+-+-+ 214 Tunnel Encapsulation Sub-Type Variable Format 216 Revocation Selection Extension fields include: 218 Type 219 Non-skippable = TBD 221 Length 222 Depends on the selection algorithm specified. 224 Sub-Type 225 Indicates the type of additional selection specified: 227 1 - Start/End Home IP Address 228 Indicates the TLV contains a starting and ending home IP 229 address used to further qualify registration selection. For 230 this sub-type, the length of the TLV will be 10 bytes. 232 2 - NAI Regular Expression 233 Indicates the TLV contains a regular expression applied to the 234 NAI (Network Access Identifier). This field is only limited by 235 the single byte length. Hence, it can be up to 254 octets in 236 length given that the sub-type takes 1 octet. 238 3 - Encapsulation 239 Indicates the TLV contains a tunnel encapsulation protocol 240 identifier. This indicates that the bulk revocation only 241 applies to registrations using the specified tunnel 242 encapsulation. For this sub-type, the length of the TLV will 243 be 2 bytes. 245 Reserved 246 Reserved for future use. MUST be set to 0 on sending, MUST be 247 ignored on receiving. 249 Starting Home IP Address 250 The starting address in a range of IP home addresses whose 251 registrations are to be revoked. 253 Ending Home IP Address 254 The ending address in a range of IP home addresses whose 255 registrations are to be revoked. 257 NAI Regular Expression 258 A regular expression to be matched against the Network Address 259 Identifier (NAI) for registration to determine which registrations 260 are to be revoked. Refer to [NAI] for information on Mobile IP 261 Network Access Identifiers. Refer to [REG-EXPR] for information 262 on regular expressions. 264 Protocol ID 265 The protocol ID corresponding to the tunnel encapsulation: 267 94 268 IP-in-IP encapsulation [IP-IN-IP] 270 47 271 Generic Routing Encapsulation (GRE) [GRE] 273 55 274 Minimal IP Encapsulation [MIN-IP] 276 The Mobile IP revocation selection extension may appear in either a 277 Registration Revocation or Registration Revocation Acknowledgement 278 message. 280 2.3. Registration Revocation Message Changes 282 The Registration Revocation Message is fully described in 283 [REVOCATION]. The UDP header is followed by the Mobile IP fields 284 which are repeated herein with the changes described below: 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Reserved |A|I|B| Reserved |Prefix Len | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Home Address/Prefix | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Home Domain Address | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Foreign Domain Address | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Revocation Identifier | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Extensions... 300 +-+-+-+-+-+-+-+-+-+-+-+-+- 301 | Authenticator... 302 +-+-+-+-+-+-+-+-+-+-+-+-+- 304 Registration Revocation Message Changes 306 Changes to the Registration Revocation message are: 308 Type 309 7 - Unchanged from [REVOCATION] 311 'I' Bit 312 Unchanged from [REVOCATION] 314 'A' Bit 315 Unchanged from [REVOCATION] 317 'B' Bit 318 This bit is set to '1' by a mobility agent to indicate that this 319 revocation message is a request for bulk revocation. Bulk 320 revocation may apply to one or many registrations. 322 Reserved 323 Reserved for future use. MUST be set to 0 on sending, MUST be 324 ignored on receiving. 326 Prefix Length 327 The prefix length which, when combined with the home prefix 328 specifies which registrations are to be revoked. If bulk 329 revocation is requested (as specified by the 'B' bit) and this 330 field is zero, the Registration Revocation applies to all 331 registrations for which bulk revocation was previously negotiated 332 using the Revocation Support Extension or a global mechanism 333 beyond the scope of this specification. 335 Reserved 336 Reserved for future use. MUST be set to 0 on sending, MUST be 337 ignored on receiving. 339 Home Address/Prefix 340 If bulk revocation is requested ('B' bit set to '1'), this field 341 is combined with the prefix length to select one or more 342 registrations to be revoked. If bulk revocation is not requested 343 ('B' bit set to '0'), this field specifies the home IP address of 344 the mobile node whose registration is being revoked. 346 Home Domain Address 347 Unchanged from [REVOCATION] 349 Foreign Domain Address 350 Unchanged from [REVOCATION] 352 Revocation ID 353 Unchanged from [REVOCATION] 355 The Registration Revocation message is processed as before only now 356 it can be applied to one or more active registrations between the 357 mobility agents. It must be authenticated as specified in 358 [REVOCATION]. 360 2.4. Registration Revocation Acknowledgment Message Changes 362 The Registration Revocation Acknowledgment Message is fully described 363 in [REVOCATION]. The UDP header is followed by the Mobile IP fields 364 which are repeated herein with the changes described below: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type | Reserved |I|B| Reserved | Prefix Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Home Address | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Revocation Identifier | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Extensions... 376 +-+-+-+-+-+-+-+-+-+-+-+-+- 377 | Authenticator... 378 +-+-+-+-+-+-+-+-+-+-+-+-+- 380 Registration Revocation Message Changes 382 Changes to the Registration Revocation Acknowledgement message are: 384 Type 385 15 - Unchanged from [REVOCATION] 387 'I' Bit 388 Unchanged from [REVOCATION] 390 'B' Bit 391 This bit is set to '1' by a mobility agent to indicate successful 392 revocation of at least one registration in response to the bulk 393 revocation request. 395 Reserved 396 Reserved for future use. MUST be set to 0 on sending, MUST be 397 ignored on receiving. 399 Prefix Length 400 The prefix length which, when combined with the home prefix 401 specifies which registrations were revoked. The prefix length 402 MUST match the length specified on the corresponding Registration 403 Revocation message. 405 Reserved 406 Reserved for future use. MUST be set to 0 on sending, MUST be 407 ignored on receiving. 409 Home Address/Prefix 410 If bulk revocation is requested ('B' bit set to '1'), this field 411 is combined with the prefix length to select one or more 412 registrations to be revoked. If bulk revocation is not requested 413 ('B' bit set to '0"), this field specifies the home IP address of 414 the mobile node whose registration is being revoked. It MUST 415 match the home address/prefix specified on the previous 416 Registration Revocation message. 418 Revocation ID 419 Unchanged from [REVOCATION] 421 A Registration Revocation Acknowledgment message MUST be sent in 422 response to a valid and authenticated registration revocation message 423 as specified in [REVOCATION]. 425 2.5. Replay Protection 427 Replay protection proceeds in much the same way as described in 428 [REVOCATION]. However, when assuring that the message is not a 429 replayed message, the mobility agent must check the timestamp to 430 assure it is greater than the timestamp received from the most 431 recently received Mobility Revocation Support extension from the 432 agent. One way to support this is to maintain the most recent per- 433 peer timestamp for peer mobility agents. For co-located mobile 434 nodes, there normally will be only one active registration 435 (situations where there are many are beyond the scope of this 436 document). 438 2.6. GRE Key Applicability 440 If GRE keys are being utilized as described in [MIP-GRE-KEY], then 441 the GRE Key Extension as described in the same document MUST be 442 included in bulk registration revocation messages. If a Home Agent 443 and Foreign Agent are using GRE tunnels with keys and a registration 444 revocation is exchanged without the GRE Key Extension, it should be 445 dropped by the recipient and the event should be logged. 447 3. Bulk Registration Revocation Overview 449 Bulk Registration Revocation processing is identical to Registration 450 Revocation as described in [REVOCATION] except for following 451 differences: 453 1. When the Registration Request is received, bulk revocation 454 support is negotiated through the setting of the B-Bit in the 455 Revocation Support extension. This negotiation should not 456 preclude global bulk revocation negotiation between mobility 457 agents. However, such support is beyond the scope of this 458 document. 460 2. When a mobility agent processes a bulk Registration Revocation, 461 it may apply to multiple registrations. 463 3. The replay protection validation will now use the timestamp in 464 the most recent Revocation Support Extension from the sending 465 agent. This is described in Section 2.5. 467 3.1. Home Agent Responsibilities 469 Home Agent responsibilities are identical to [REVOCATION] except as 470 noted above. In situations where a single event may apply to 471 multiple registrations (or bindings on the Home Agent), a bulk 472 revocation may be sent in lieu of multiple revocations. A non- 473 exhaustive list of events that may benefit from bulk revocation 474 includes: 476 1. Graceful shutdown of the home agent (HA) instance 478 2. Policy changes that preclude communication with the Foreign Agent 479 (FA) 481 3. Withdrawn of the Home Agent local address from service 483 4. Home Address Pool deletion or change 485 5. Other policy change resulting in multiple registrations being 486 revoked 488 3.2. Foreign Agent Responsibilities 490 Foreign Agent responsibilities are identical to [REVOCATION] except 491 as noted above. In situations where a single event may apply to 492 multiple registrations (or visitors on the Foreign Agent), a bulk 493 revocation may be sent in lieu of multiple revocations. A non- 494 exhaustive list of events that may benefit from bulk revocation 495 includes: 497 1. Graceful shutdown of the foreign agent (FA) instance 499 2. Policy changes that preclude communication with the Home Agent 500 (HA) 502 3. Withdrawn of the Care-of-Address (CoA) from service 504 4. Other policy change resulting in multiple registrations being 505 revoked 507 3.3. Direct Co-located Node Responsibilities 509 In general, bulk revocation is not the useful to a direct co-located 510 node since it will usually only have single registration with a home 511 agent. Hence, there is really no reason for a direct co-located to 512 negotiate bulk revocation in the first place by setting the B-Bit in 513 the Revocation Support Extension appending to its initial 514 registration. However, this specification does not preclude support 515 and a direct co-located node negotiating bulk revocation must support 516 bulk revocation requests. 518 4. Security Considerations 520 Security is basically unchanged from [REVOCATION] with the exception 521 that replay protection will be based on the most recent registration 522 revocation received from the peer (as described in Section 2.5). As 523 with [REVOCATION], all message exchanges related to revocation MUST 524 be protected by either a valid authenticator as specified in [MIP4]. 525 For communications between mobility agents, FA-HA authentication or a 526 mechanism at least as secure, e.g. IPsec, is required. For 527 communication between a home agent and a direct co-located mobile 528 node, MN-HA authentication or a mechanism at least as secure is 529 required. In this context, all message exchanges relating to 530 revocation include Registration Revocations, Registration Revocation 531 Acknowledgments, Registration Requests including the Revocation 532 Support Extension, and Registration Replies including the Revocation 533 Support Extension. 535 5. IANA Considerations 537 A non-skippable extension value is needed for the Revocation 538 Selection Extension. This should be allocated from the "Extensions 539 appearing in Mobile IP messages" number space in the "Mobile IPv4 540 Numbers". Also, a new sub-registry is required for the sub-types for 541 this extension. Initially, it will have the following values: 543 1 - Start/End Home IP Address 544 Indicates the TLV contains a starting and ending home IP address 545 used to further qualify registration selection. 547 2 - NAI Regular Expression 548 Indicates the TLV contains a regular expression applied to the NAI 549 (Network Access Identifier). 551 3 - Encapsulation 552 Indicates the TLV contains a tunnel encapsulation protocol 553 identifier. 555 Refer to Section 2.2 for more information. 557 6. References 559 6.1. Normative References 561 [GRE] Farinacci, D., Li, T., Meyer, D., and P. Traina, "Generic 562 Routing Encapsulation", RFC 2784, March 2000. 564 [IP-IN-IP] 565 Perkins, C., "IP Encapsulation within IP", RFC 2003, 566 October 1996. 568 [MIN-IP] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 569 October 1996. 571 [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 572 August 2002. 574 [NAI] Johansson, F. and T. Johannsson, "Mobile IPv4 Extension 575 for Carrying Network Access Identifiers", RFC 3846, 576 June 2004. 578 [REG-EXPR] 579 Institute of Electrical and Electronix Engineers, 580 "Information Technology - Portable Operation System 581 Interface (POSIX) - Part 2: Shell and Variables (Vol. 582 1)", IEEE 1003.3, 1992. 584 [REVOCATION] 585 Chandra, M. and S. Glass, "Registration Revocation in 586 Mobile IPv4", RFC 3543, August 2003. 588 [RFC-KEYWORDS] 589 Bradner, S., "Key words for use in RFC's to Indicate 590 Requirement Levels", RFC 2119, March 1997. 592 6.2. Informative References 594 [MIP-GRE-KEY] 595 Yegani, P., Dommety, G., Lior, A., Chowdhury, K., and J. 596 Navali, "GRE Key Extension for Mobile IPv4", 597 draft-yegani-gre-key-extension-03.txt (work in progress). 599 Appendix A. Acknowledgments 601 The RFC text was produced using Marshall Rose's xml2rfc tool. 603 Thanks to Hendrik Levkowetz and Sri Gundavelli for their comments on 604 the document. 606 Appendix B. Change Log 608 B.1. Changes from 00 Version to 01 Version 610 The section contains list of changes from version 00 to version 01: 612 o Change the prefix length field in the registration revocation 613 message from 8 bits to 6 bits. Refer to Section 2.3. 615 o Add reference to GRE key draft and a section documenting the 616 applicability to this document. Refer to Section 2.6. 618 Authors' Addresses 620 Acee Lindem 621 Redback Networks 622 102 Carric Bend Court 623 Cary, NC 27519 624 USA 626 Email: acee@redback.com 628 Anand Oswal 629 Redback Networks 630 300 Holger 631 San Jose, CA 95134 632 USA 634 Email: aoswal@redback.com 636 Full Copyright Statement 638 Copyright (C) The IETF Trust (2008). 640 This document is subject to the rights, licenses and restrictions 641 contained in BCP 78, and except as set forth therein, the authors 642 retain all their rights. 644 This document and the information contained herein are provided on an 645 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 646 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 647 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 648 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 649 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 650 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 652 Intellectual Property 654 The IETF takes no position regarding the validity or scope of any 655 Intellectual Property Rights or other rights that might be claimed to 656 pertain to the implementation or use of the technology described in 657 this document or the extent to which any license under such rights 658 might or might not be available; nor does it represent that it has 659 made any independent effort to identify any such rights. Information 660 on the procedures with respect to rights in RFC documents can be 661 found in BCP 78 and BCP 79. 663 Copies of IPR disclosures made to the IETF Secretariat and any 664 assurances of licenses to be made available, or the result of an 665 attempt made to obtain a general license or permission for the use of 666 such proprietary rights by implementers or users of this 667 specification can be obtained from the IETF on-line IPR repository at 668 http://www.ietf.org/ipr. 670 The IETF invites any interested party to bring to its attention any 671 copyrights, patents or patent applications, or other proprietary 672 rights that may cover technology that may be required to implement 673 this standard. Please address the information to the IETF at 674 ietf-ipr@ietf.org. 676 Acknowledgment 678 Funding for the RFC Editor function is provided by the IETF 679 Administrative Support Activity (IASA).