idnits 2.17.1 draft-ietf-mext-generic-signaling-message-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 586. 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 14, 2008) is 5705 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 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group Brian Haley 3 Internet Draft Hewlett-Packard 4 Intended status: Standards Track Sri Gundavelli 5 Expires: January, 2009 Cisco Systems 6 August 14, 2008 8 Mobile IPv6 Generic Signaling Message 9 draft-ietf-mext-generic-signaling-message-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document specifies two new Mobility Header message types that 37 allow Mobile IPv6 entities to send and receive generic signaling 38 messages. 40 Table of Contents 42 1. Introduction...................................................2 43 2. Terminology....................................................3 44 3. Generic Signaling Messages.....................................3 45 3.1 Generic Signaling Message..................................4 46 4. Generic Signaling Sub-types....................................5 47 4.1 Generic Signaling Option Sub-type..........................5 48 4.2 Generic Signaling Request Sub-type.........................6 49 4.3 Generic Signaling Acknowledgement Sub-type.................7 50 5. Sending Generic Signaling Messages.............................8 51 5.1 Sending Generic Signaling Option Messages..................8 52 5.2 Sending Generic Signaling Request Messages.................8 53 5.3 Sending Generic Signaling Acknowledgement Messages.........9 54 6. Receiving Generic Signaling Messages...........................9 55 6.1 Receiving Generic Signaling Option Messages...............10 56 6.2 Receiving Generic Signaling Request Messages..............10 57 6.2.1 Mobile Node Operation...................................10 58 6.2.2 Home Agent Operation....................................10 59 6.2.3 Retransmissions.........................................11 60 7. Protocol Constants............................................11 61 8. IANA Considerations...........................................11 62 9. Security Considerations.......................................12 63 10. References...................................................12 64 10.1 Normative Reference......................................12 65 10.2 Informative references...................................12 66 Acknowledgments..................................................12 67 Author's Addresses...............................................12 69 1. Introduction 71 RFC 3775 [RFC3775] contains no provision for Mobile IPv6 entities, 72 such as a home agent or mobile node, to send and receive signaling 73 messages during a mobility session. 75 This document describes a generic signaling message protocol that can 76 be used by Mobile IPv6 entities for sending and receiving signaling 77 events. Two messages are defined - one that does not employ IPsec 78 protection, and one that does. 80 It also provides common semantics and a framework that can be used 81 for defining new event types, and carrying them using the protocol 82 defined in this document. 84 The document does not define any specific events, or the 85 corresponding actions that the receiver is required to do upon 86 receiving an event. The receiver actions specified in this document 87 are within the scope of the message delivery and acknowledgment that 88 are common to all events carried using this messaging protocol. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC-2119 [RFC2119]. 96 3. Generic Signaling Messages 98 The messages described below follow the Mobility Header format 99 specified in Section 6.1 of [RFC3775]: 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Payload Proto | Header Len | MH Type | Reserved | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Checksum | | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 106 | | 107 . . 108 . Message Data . 109 . . 110 | | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 3.1 Generic Signaling Messages 115 The Generic Signaling messages are used by the home agent to notify 116 the mobile node, or vice-versa, that there is an event that requires 117 attention. This packet is sent as described in Section 5. 119 The Generic Signaling messages use the MH Type value (TBD1) or 120 (TBD2). When either value is indicated in the MH Type field, the 121 format of the Message Data field in the Mobility Header is as 122 follows: 124 0 1 2 3 125 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Sub-Type | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | | 130 . . 131 . Sub-Type specific data . 132 . . 133 | | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | | 136 . . 137 . Mobility options . 138 . . 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Sub-Type 144 A 16-bit unsigned integer. This field describes the particular 145 type of notification which is carried in the Generic Signaling 146 message. 148 This specification defines three Sub-types valid for the Generic 149 Signaling messages. 151 Sub-Type specific data 153 Variable-length field containing data specific to the Sub-Type. 154 This could be zero bytes in length. 156 This specification defines three Sub-type data layouts valid for 157 the Generic Signaling messages. 159 Mobility options 160 Variable-length field of such length that the complete Mobility 161 Header is an integer multiple of 8 octets long. This field 162 contains zero of more TLV-encoded mobility options. The encoding 163 and format of defined options MUST follow the format specified in 164 Section 6.2 of [RFC3775]. The receiver MUST ignore and skip any 165 options with it does not understand. 167 This specification does not define any options valid for the 168 Generic Signaling messages. 170 4. Generic Signaling Sub-types 172 4.1 Generic Signaling Option Sub-type 174 The Generic Signaling Option sub-type specifies an un-bounded 175 signaling message. This packet is sent as described in Section 5. 177 The Generic Signaling Option uses the sub-type value 0 (zero). When 178 this value is indicated in the Sub-Type field, there is no data 179 contained in the Sub-Type Specific Data field in the Generic 180 Signaling message, there are only Mobility Options, and the format is 181 as follows: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 . . 188 . Mobility options . 189 . . 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Mobility options 195 Variable-length field of such length that the complete Mobility 196 Header is an integer multiple of 8 octets long. This field 197 contains zero of more TLV-encoded mobility options. The encoding 198 and format of defined options MUST follow the format specified in 199 Section 6.2 of [RFC3775]. The receiver MUST ignore and skip any 200 options which it does not understand. 202 This specification does not define any options valid for the 203 Generic Signaling Option message. 205 If no options are present in this message, no padding is necessary 206 and the Header Len field in the Mobility Header will be set to 0. 208 4.2 Generic Signaling Request Sub-type 210 The Generic Signaling Request sub-type specifies a sequenced type of 211 signaling message. This packet is sent as described in Section 5. 213 The Generic Signaling Request uses the sub-type value 1. When this 214 value is indicated in the Sub-Type field, the format of the Sub-Type 215 Specific Data field in the Generic Signaling message is as follows: 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Sequence Number |A| Reserved | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | | 223 . . 224 . Mobility options . 225 . . 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Sequence Number 231 A 16-bit unsigned integer used by the receiving node to sequence 232 Signaling Requests and by the sending node to match a returned 233 Signaling Acknowledgement with this Signaling Request. 235 Acknowledge (A) 237 The Acknowledge (A) bit is set by the sender to request a Signaling 238 Acknowledgement (Section 4.3) be returned upon receipt of a 239 Signaling Request. 241 Reserved 243 These fields are unused. They MUST be initialized to zero by the 244 sender, and MUST be ignored by the receiver. 246 Mobility options 248 Variable-length field of such length that the complete Mobility 249 Header is an integer multiple of 8 octets long. This field 250 contains zero of more TLV-encoded mobility options. The encoding 251 and format of defined options MUST follow the format specified in 252 Section 6.2 of [RFC3775]. The receiver MUST ignore and skip any 253 options with it does not understand. 255 This specification does not define any options valid for the 256 Signaling Request message. 258 If no options are present in this message, no padding is necessary 259 and the Header Len field in the Mobility Header will be set to 0. 261 4.3 Generic Signaling Acknowledgement Sub-type 263 The Generic Signaling Acknowledgement sub-type is used to acknowledge 264 receipt of a Generic Signaling Request (Section 4.2). This packet is 265 sent as described in Section 5. 267 The Generic Signaling Acknowledgement uses the Sub-Type value 2. 268 When this value is indicated in the Sub-Type field, the format of the 269 Sub-type Specific Data field in the Generic Signaling message is as 270 follows: 272 0 1 2 3 273 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Sequence Number | Status | Reserved | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | | 279 . . 280 . Mobility options . 281 . . 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Sequence Number 287 The sequence number in the Signaling Acknowledgement is copied from 288 the sequence number field in the Signaling Request. It is used by 289 the receiving node in matching this Signaling Acknowledgement with 290 an outstanding Signaling Request. 292 Status 294 8-bit unsigned integer indicating the disposition of the Signaling 295 Request. Values of the Status field less than 128 indicate that 296 the Signaling Request was accepted by the receiving node. Values 297 greater than or equal to 128 indicate that the Signaling Request 298 was rejected by the receiving node. The following Status values 299 are currently defined: 301 0 Signaling Request accepted 303 128 Reason unspecified 305 129 Administratively prohibited 307 130 Insufficient resources 309 131 Unsupported mobility option 311 132 Not home agent for this mobile node 313 Mobility options 315 Variable-length field of such length that the complete Mobility 316 Header is an integer multiple of 8 octets long. This field 317 contains zero of more TLV-encoded mobility options. The encoding 318 and format of defined options MUST follow the format specified in 319 Section 6.2 of [RFC3775]. The receiver MUST ignore and skip any 320 options with it does not understand. 322 This specification does not define any options valid for the 323 Signaling Request sub-type. 325 If no options are present in this message, no padding is necessary 326 and the Header Len field in the Mobility Header will be set to 0. 328 5. Sending Generic Signaling Messages 330 When sending a Generic Signaling message, the sending node constructs 331 the packet as it would any other Mobility Header, except: 333 o The MH Type field MUST be set to (TBD1) if IPsec protection of 334 the message is not required. 336 o The MH Type field MUST be set to (TBD2) if IPsec protection of 337 the message is required. In this case, the Generic Signaling 338 Request message MUST use the home agent to mobile node IPsec ESP 339 authentication SA for integrity protection 341 5.1 Sending Generic Signaling Option Messages 343 When sending a Generic Signaling Option, the sending node just adds 344 mobility options to the message. 346 5.2 Sending Generic Signaling Request Messages 348 When sending a Generic Signaling Request message, the sending node 349 constructs the packet as specified in Section 5, except: 351 o The Acknowledge (A) bit MAY be set to indicate the receiver must 352 send a Generic Signaling Acknowledgement in response to this 353 Generic Signaling Request. 355 5.3 Sending Generic Signaling Acknowledgement Messages 357 A Generic Signaling Acknowledgement message should be sent to 358 indicate receipt of a Generic Signaling Request as follows: 360 o If the Generic Signaling Request was discarded because it does 361 not meet the requirements as specified in [RFC3775] described in 362 Section 6, a Generic Signaling Acknowledgement MUST NOT be sent. 363 Otherwise, the treatment depends on the below rule. 365 o If the Acknowledgement (A) bit is set in the Generic Signaling 366 Request, a Generic Signaling Acknowledgement MUST be sent. 367 Otherwise, the treatment depends on the below rule. 369 o If the Generic Signaling Request was discarded for any other 370 reason, a Generic Signaling Acknowledgement SHOULD be sent. 372 If the Source Address field of the IPv6 header that carried the 373 Generic Signaling Request does not contain a unicast address, the 374 Generic Signaling Acknowledgement MUST NOT be sent, and the Generic 375 Signaling Request packet MUST be silently discarded. Otherwise, the 376 acknowledgement MUST be sent to the Source Address. 378 6. Receiving Generic Signaling Messages 380 Upon receiving a Generic Signaling message, the Mobility Header MUST 381 be verified as specified in [RFC3775], specifically: 383 o The Checksum, MH type, Payload Proto and Header Len fields MUST 384 meet the requirements of Section 9.2 of [RFC3775]. 386 o If the MH Type field is set to (TBD2) (IPsec protection of the 387 message is required), then the packet MUST be covered by the 388 home agent to mobile node IPsec ESP authentication SA for 389 integrity protection. 391 If the packet is dropped due to the above tests, the receiving node 392 MUST follow the processing rules as Section 9.2 of [RFC3775]. For 393 example, it MUST send a Binding Error message with the Status field 394 set to 2 (unrecognized MH Type value) if it does not support the 395 message type. 397 o If the Generic Signaling message is valid according to the tests 398 above, then it is processed according to the rules specific to 399 the Sub-Type specified in the header. 401 Subsequent checks depend on the current mode of operation of the 402 node. 404 6.1 Receiving Generic Signaling Option Messages 406 If the Generic Signaling Option message is valid according to the 407 tests in Section 6, then it is processed further as follows: 409 o If the receiving node does not allow Generic Signaling Option 410 messages, or does not support the type of Mobility Option in the 411 message, it MUST reject the request and SHOULD silently discard 412 the message. 414 Subsequent checks depend on the current mode of operation of the 415 node. 417 6.2 Receiving Generic Signaling Request Messages 419 If the Generic Signaling Request message is valid according to the 420 tests in Section 6, then it is processed further as follows: 422 o If the receiving node does not allow Generic Signaling Request 423 messages, it MUST reject the request and SHOULD return a Generic 424 Signaling Acknowledgement to the sender in which the Status 425 field is set to 129 (administratively prohibited). 427 o If the receiving node does not support the type of Mobility 428 Option in the Generic Signaling Request message, it MUST reject 429 the request and SHOULD return a Generic Signaling 430 Acknowledgement to the sender in which the Status field is set 431 to 131 (unsupported mobility option). 433 Subsequent checks depend on the current mode of operation of the 434 node. 436 6.2.1 Mobile Node Operation 438 If the mobile node rejects the Generic Signaling Request message for 439 any other reason than specified in Section 6, it SHOULD return a 440 Generic Signaling Acknowledgement to the home agent in which the 441 Status field is set to 128 (reason unspecified). 443 6.2.2 Home Agent Operation 445 If the receiving node is a home agent, it MUST perform these 446 additional checks: 448 o If the home agent has no entry marked as a home registration in 449 its Binding Cache for this mobile node, then this node MUST 450 reject the request and SHOULD return a Generic Signaling 451 Acknowledgement to the mobile node in which the Status field is 452 set to 132 (not home agent for this mobile node). 454 o If the home agent cannot process the Generic Signaling Request 455 message because it is over-utilized, it MUST reject the request 456 and SHOULD return a Generic Signaling Acknowledgement to the 457 mobile node in which the Status field is set to 130 458 (insufficient resources). 460 If the home agent rejects the Generic Signaling Request message for 461 any other reason, it SHOULD return a Generic Signaling 462 Acknowledgement to the mobile node in which the Status field is set 463 to 128 (reason unspecified). 465 6.2.3 Retransmissions 467 If the sender has set the Acknowledge (A) bit in the Generic 468 Signaling Request, but does not receive a Generic Signaling 469 Acknowledgement, then it MAY retransmit the message, until a response 470 is received. The initial value for the retransmission timer is 471 INITIAL_MH_SIGNALING_TIMEOUT. The retransmissions by the sender MUST 472 use an exponential back-off mechanism, in which the timeout period is 473 doubled upon each retransmission, until either the sender gets a 474 response from the target node, or the timeout period reaches the 475 value MAX_MH_SIGNALING_TIMEOUT. 477 7. Protocol Constants 479 INITIAL_MH_SIGNALING_TIMEOUT 5 seconds 480 MAX_MH_SIGNALING_TIMEOUT 20 seconds 482 8. IANA Considerations 484 Two new Mobility Header types are required for the following new 485 message described in Section 2: 487 (TBD1) Generic Signaling Message with 488 (TBD2) Secure Generic Signaling Message 490 New Generic Signaling Message Sub-Types are required for the 491 following described in Section 4: 493 0 Generic Signaling Option 494 1 Generic Signaling Request 495 2 Generic Signaling Acknowledgement 497 9. Security Considerations 499 Considerations have been made to support an unprotected Generic 500 Signaling Message type, MH type (TBD1). This message does not use 501 any IPsec protection. 503 In addition, a secure message, called the Secure Generic Signaling 504 message, MH type (TBD2), is specified. This message MUST use the 505 home agent to mobile node IPsec ESP encryption SA for confidentiality 506 protection, and MUST use the home agent to mobile node IPsec ESP 507 authentication SA for integrity protection. This message type SHOULD 508 be used for signaling messages that update binding cache state on 509 either system. 511 The Secure Generic Signaling message MAY use the IPsec ESP SA in 512 place for Binding Updates and Acknowledgements as specified in 513 Section 5.1 of [RFC3775], in order to reduce the number of configured 514 security associations. This also gives the message authenticity 515 protection. 517 10. References 519 10.1 Normative Reference 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC3775] Johnson, D. Perkins, C., and Arkko, J., "Mobility Support 525 in IPv6", RFC 3775, June, 2004. 527 10.2 Informative references 529 Acknowledgments 531 Thanks to Hui Deng, James Kempf and Vijay Devarapalli for their 532 initial review of the draft. 534 Author's Addresses 536 Brian Haley 537 Hewlett-Packard Company 538 110 Spitbrook Road 539 Nashua, NH 03062, USA 540 Email: brian.haley@hp.com 542 Sri Gundavelli 543 Cisco Systems 544 170 W.Tasman Drive 545 San Jose, CA 95134, USA 546 Email: sgundave@cisco.com 548 Full Copyright Statement 550 Copyright (C) The IETF Trust (2008). 552 This document is subject to the rights, licenses and restrictions 553 contained in BCP 78, and except as set forth therein, the authors 554 retain all their rights. 556 This document and the information contained herein are provided on an 557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 559 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 560 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 561 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 564 Intellectual Property 566 The IETF takes no position regarding the validity or scope of any 567 Intellectual Property Rights or other rights that might be claimed to 568 pertain to the implementation or use of the technology described in 569 this document or the extent to which any license under such rights 570 might or might not be available; nor does it represent that it has 571 made any independent effort to identify any such rights. Information 572 on the procedures with respect to rights in RFC documents can be 573 found in BCP 78 and BCP 79. 575 Copies of IPR disclosures made to the IETF Secretariat and any 576 assurances of licenses to be made available, or the result of an 577 attempt made to obtain a general license or permission for the use of 578 such proprietary rights by implementers or users of this 579 specification can be obtained from the IETF on-line IPR repository at 580 http://www.ietf.org/ipr. 582 The IETF invites any interested party to bring to its attention any 583 copyrights, patents or patent applications, or other proprietary 584 rights that may cover technology that may be required to implement 585 this standard. Please address the information to the IETF at 586 ietf-ipr@ietf.org. 588 Acknowledgement 590 Funding for the RFC Editor function is provided by the IETF 591 Administrative Support Activity (IASA).