idnits 2.17.1 draft-ietf-l2tpext-radius-ext-nas-port-02.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 584. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (Dec 2007) is 5976 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 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Please publish to l2tpext@ietf.org 3 Network Working Group N. McGill 4 Internet-Draft cisco Systems 5 Expires: June 3, 2008 T. Mistretta 6 Juniper Networks 7 I. Goyret 8 Alcatel-Lucent 9 M. Townsley 10 G. Weber 11 cisco Systems 12 Dec 2007 14 RADIUS & L2TP Extended NAS-Port AVPs 15 draft-ietf-l2tpext-radius-ext-nas-port-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on June 3, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This document defines additional Layer 2 Tunneling Protocol (L2TP) 49 and Remote Authentication Dial In User Service (RADIUS) Attribute- 50 Value Pairs (AVPs) to communicate Network Access Server (NAS) 51 informational UTF-8 text and port usage information between L2TP 52 peers during call establishment to facilitate authorization, 53 accounting and logging. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 59 2. L2TP Extended NAS-Port AVPs . . . . . . . . . . . . . . . . . 4 60 3. RADIUS Extended NAS-Port AVP . . . . . . . . . . . . . . . . . 7 61 3.1. Table of Attributes . . . . . . . . . . . . . . . . . . . 10 62 3.2. Interactions with other RADIUS attributes . . . . . . . . 10 63 3.3. Diameter Compatibility . . . . . . . . . . . . . . . . . . 10 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 71 Intellectual Property and Copyright Statements . . . . . . . . . . 14 73 1. Introduction 75 It is often desirable to send adjunct and port usage information from 76 the L2TP Access Concentrator (LAC) to the L2TP Network Server (LNS) 77 during call setup. Such information MAY be used for: 79 Logging 80 to describe system and port related information in a human- 81 readable, vendor-specific form. 82 Authorization 83 to restrict users to particular given access types or 84 interfaces. 85 Accounting 86 to determine port usage on a per-user basis, for example, via 87 RADIUS accounting [RFC2866]. 88 Auditing 89 to ensure that the LNS vendor is being allocated the proper 90 contractual resources by the LAC vendor. 92 L2TPv2 [RFC2661] and L2TPv3 [RFC3931] already have a Physical Channel 93 ID AVP that may be used to provide port usage information. However, 94 its usefulness is limited in multi-vendor LAC/LNS environments where 95 the vendor- specific bit encoding used for this AVP will often not be 96 understood by L2TP peers from differing vendors. 98 This makes the task of de-constructing the Physical Channel ID AVP 99 contents at the LNS for (RADIUS) authorization/accounting server 100 extremely difficult. 102 Additionally, it is length limited to 4 octets of information which 103 is inadequate in access servers supporting multiple access types and 104 large numbers of ports. 106 This document defines extensions whereby such port usage information 107 may be transferred in a vendor-independent fashion between mixed- 108 vendor LAC and LNSs, thus facilitating detailed and matching logging 109 and accounting at each end of the tunnel. 111 The following diagram depicts a typical dialin scenario for L2TP with 112 RADIUS accounting servers at the LNS: 114 Authen/Accounting 115 RADIUS server 116 | 117 | 118 | 119 | 120 intranet - - - - LNS - - - - - internet - - - -LAC - - - -client 121 <-----------------------------> 122 L2TP tunnel 124 1.1. Specification of Requirements 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 2. L2TP Extended NAS-Port AVPs 132 The following collection of Extended NAS-Port AVPs, attribute types 133 TBD, allow detailed logging and port usage information to be 134 transmitted between L2TP peers. This format is common to all 135 Extended NAS-Port AVPs; only the Attribute Type is different for 136 each: 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 |M|H| rsvd | Length | Vendor ID (IETF) | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Attribute Type | Attribute Value... 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 [until Length is reached]... | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 NOTES: 150 o Each Extended NAS-Port AVP is encoded as the IETF Vendor ID 0 152 o Each AVP has defined behaviour associated with it, namely: 154 RELAYED AVP: See [I-D.ietf-l2tpext-tunnel-switching], section 3. 155 AVP Behavior, for definition. In summary, if this AVP is 156 received by a node participating in a multi-hop scenario, then 157 the AVP MUST be copied as-is to the next hop. 159 STACKED AVP: See [I-D.ietf-l2tpext-tunnel-switching], section 3. 160 AVP Behavior, for definition. In summary, if this AVP is 161 received by a node participating in a multi-hop scenario, then 162 the AVP MUST be copied as-is to the next hop. A locally 163 generated AVP MUST be generated and appended in the outbound 164 message to the next hop. If no value is appropriate then an 165 AVP of Length 6 (minimum AVP length) MUST be appended. This 166 null attibute value may be used for all AVPs where no value is 167 appropriate. 169 o The value of all bits MUST be preserved in any AVPs copied. 171 The following are valid values for the Attribute Type field in 172 control channel related messages: 174 L2TP-AVP-TBD-1 - Platform Information 176 This AVP, value length 0-253, allows a UTF-8 [RFC3629] string 177 to be sent with a human-readable description of the platform. 179 Examples: "Model 457", or "TPX-1700". 181 This information MUST NOT be parsed and as such termination 182 action MUST NOT be based on the contents of this attribute. 184 The M-bit MUST be set to 0. The H-bit MAY be set based on the 185 current L2TP node's policy. This AVP is a stackable AVP. 187 L2TP-AVP-TBD-2 - System Identification Information 189 This AVP, value length 0-253, allows a UTF-8 [RFC3629] string 190 to be sent with a human-readable description of the router's 191 identification within the provider's network. 193 Examples: "CommCo LAC", or "SuperProvider AS". 195 This information MUST NOT be parsed and as such termination 196 action MUST NOT be based on the contents of this attribute. 198 The M-bit MUST be set to 0. The H-bit MAY be set based on the 199 current L2TP node's policy. This AVP is a stackable AVP. 201 L2TP-AVP-TBD-4 - Software Information 203 This AVP, value length 0-253, allows a UTF-8 [RFC3629] string 204 to be sent with a human-readable description of the software 205 running on the platform. 207 Examples: "Version 4-0.12(c)-2", or "Rev 10.4.2-beta". 209 This information MUST NOT be parsed and as such termination 210 action MUST NOT be based on the contents of this attribute. 212 The M-bit MUST be set to 0. The H-bit MAY be set based on the 213 current L2TP node's policy. This AVP is a stackable AVP. 215 For tunnels, these AVPs are valid either on SCCRQ or SCCCN. If 216 sent on both, the SCCCN AVP MUST override the SCCRP value. 218 The following are valid values for the Attribute Type field in 219 session related messages: 221 L2TP-AVP-TBD-3 - Call Information 223 This AVP, value length 0-253, allows a UTF-8 [RFC3629] string 224 to be sent with a human-readable description of the call. 226 Examples could include "Atlanta POP", or "Neptune-304x using 227 frame2 module". 229 This information MUST NOT be parsed and as such termination 230 action MUST NOT be based on the contents of this attribute. 232 The M-bit MUST be set to 0. The H-bit MAY be set based on the 233 current L2TP node's policy. This AVP is a stackable AVP. 235 L2TP-AVP-TBD-6 - Shelf 236 L2TP-AVP-TBD-7 - Slot 237 L2TP-AVP-TBD-8 - Module 238 L2TP-AVP-TBD-9 - Adapter 239 L2TP-AVP-TBD-10 - Interface 240 L2TP-AVP-TBD-11 - Line 241 L2TP-AVP-TBD-12 - Port 242 L2TP-AVP-TBD-13 - Channel 243 L2TP-AVP-TBD-14 - Physical Interface 244 L2TP-AVP-TBD-15 - Physical Sub-interface 245 L2TP-AVP-TBD-16 - Virtual Path 246 L2TP-AVP-TBD-17 - Virtual Circuit 247 L2TP-AVP-TBD-18 - Virtual Lan 248 L2TP-AVP-TBD-18 - Virtual Interface 249 L2TP-AVP-TBD-20 - Virtual Sub-interface 251 These AVPs, length 0 or 4, are unsigned octet integers value, 252 representing a specific Extended NAS-Port AVP value at this 253 L2TP node. 255 The M-bit MUST be set to 0. The H-bit MAY be set based on the 256 current L2TP node's policy. These AVPs are relayed AVPs. 258 All Extended NAS-Port AVPs SHOULD be used in conjunction with the 259 port type values defined in [RFC2865] and [RFC2866]. 261 For incoming calls, these AVPs are valid either on ICRQ or ICCN. 262 If sent on both, the ICCN AVP MUST override the ICRQ value. For 263 outgoing calls, the AVPs are valid on OCRP and OCCN, with similar 264 override behavior. 266 3. RADIUS Extended NAS-Port AVP 268 The RADIUS Extended NAS-Port AVP closely resembles its L2TP counter- 269 part and allows detailed port-usage/accounting information to be 270 provided in multi-vendor environments. 272 The key distinction is that for RADIUS we have a single new attribute 273 (due to lack of available RADIUS type attributes) with multiple 274 Extensions, encoded as string attribute-value pairs of the form 275 "=". These Extensions exist in a one-to- one 276 mapping with the previously defined L2TP AVPs. 278 The following format is common to all Extended NAS-Port AVPs; only 279 the Extension string name is different for each: 281 0 1 2 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 284 |Extnd. NAS-Port| Length | "extension=value"... 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 287 Type 289 RADIUS-AVP-TBD-1 for Extended NAS-Port 291 Length 292 >= 3 294 Value 296 This attribute is of string format, with the following definition: 298 "=" 300 Where "" is one of the following case-sensitive 301 strings: 303 "platform" - Platform Information 305 This AVP extension, length 3-255, allows a UTF-8 [RFC3629] 306 string to be sent with a human-readable description of the 307 platform. 309 Examples: "platform=Model 457", or "platform=TPX-1700". 311 This information MUST NOT be parsed and as such termination 312 action MUST NOT be based on the contents of this attribute. 314 "system-id" - System Identification Information 316 This AVP extension, length 3-255, allows a UTF-8 [RFC3629] 317 string to be sent with a human-readable description of the 318 routers identification within the provider's network. 320 Examples: "system-id=CommCo LAC", or "system- 321 id=SuperProvider AS". 323 This information MUST NOT be parsed and as such termination 324 action MUST NOT be based on the contents of this attribute. 326 "call" - Call Information 328 This AVP extension, length 3-255, allows a UTF-8 [RFC3629] 329 string to be sent with a human-readable description of the 330 call. 332 Examples could include "call=Atlanta POP", or "call=Neptune- 333 304x using frame2 module". 335 This information MUST NOT be parsed and as such termination 336 action MUST NOT be based on the contents of this attribute. 338 "software" - Software Information 340 This AVP extension, length 3-255, allows a UTF-8 [RFC3629] 341 string to be sent with a human-readable description of the 342 software running on the platform. 344 Examples: "software=Version 4-0.12(c)-2", or "software=Rev 345 10.4.2-beta". 347 This information MUST NOT be parsed and as such termination 348 action MUST NOT be based on the contents of this attribute. 350 "shelf" - Shelf 351 "slot" - Slot 352 "module" - Module 353 "adapter" - Adapter 354 "intf" - Interface 355 "line" - Line 356 "port" - Port 357 "channel" - Channel 358 "phys-intf" - Physical Interface 359 "phys-subintf" - Physical Sub-interface 360 "vpi" - Virtual Path 361 "vci" - Virtual Circuit 362 "vlan" - Virtual Lan 363 "vintf" - Virtual Interface 364 "vsubintf" - Virtual Sub-interface 366 These AVPs, length 3-255, allow a UTF-8 [RFC3629] string to 367 be sent with the integer value of the relevant Extended NAS- 368 Port AVP. 370 Examples: "vpi=3", "vci=0", "vlan=4094" 372 For L2TP tunnels, these attributes MUST be used, if available, to log 373 information obtained via the corresponding L2TP Extended NAS-Port 374 AVPs. See section 2. 376 To cater for L2TP multi-hop environments, if an L2TP Extended NAS- 377 Port AVP is available, but without a corresponding value, then the 378 associated RADIUS AVP MUST be encoded as "" 380 The sequence of RADIUS Extended NAS-Port AVPs MUST follow that of any 381 L2TP Extended NAS-Port AVPs received. 383 For scenarios without L2TP, these attributes MAY also be used in 384 preference over the RADIUS NAS-Port attribute to provide finer 385 granularity during accounting. 387 Where an attribute was not received from L2TP it is considered 388 optional to send. 390 For non L2TP environments, all Extensions are optional. 392 All strings are NOT null terminated. 394 Any numbers encoded as the value part of the Extension MUST be as 395 strings with a minimum value of "0". Only unsigned values MUST be 396 sent. 398 The use of the character '"' in this document is included purely as a 399 visual aid in identifying the beginning and end of strings. It MUST 400 NOT be included as part of the end format, unless specifically 401 encoded as data within the AVP Value section. 403 3.1. Table of Attributes 405 The following table provides a guide to which attributes may be found 406 in which kinds of packets, and in what quantity. 408 For Authentication: 410 Request Accept Reject Challenge Attribute 411 0+ 0 0 0 Extended NAS-Port 413 For Accounting: 415 Request Response Attribute 416 0+ 0 Extended NAS-Port 418 3.2. Interactions with other RADIUS attributes 420 Extended NAS-Port overlaps in functionality with NAS-Port. However, 421 whereas the encoding of NAS-Port is limited to 32 bits and often 422 vendor specific, Extended NAS-Port is not. NAS-Port may still 423 continue to be used but preference SHOULD be given to information 424 received in Extended NAS-Port. 426 If a RADIUS vendor detects conflicting values between NAS-Port and 427 Extended NAS-Port, Extended NAS-Port SHOULD be taken as the more 428 accurate value. 430 3.3. Diameter Compatibility 432 The RADIUS Extended NAS-Port attribute defined in this section may be 433 translated for transmission via Diameter [RFC3588] by AAA Translation 434 Agents as described by Section 9 of [RFC4005]. 436 Such a translation might represent the extended NAS-Port information 437 as a single Diameter attribute of type Grouped. Each RADIUS 438 valued defined in section 3 would map to a new Diameter 439 attribute, all of which would be encapsulated in a single Grouped 440 Extended-NAS-Port attribute. The ABNF for such an attribute might 441 look like: 443 Extended-NAS-Port ::= < AVP Header: DIAMETER-AVP-TBD-1 > 444 [ NAS-Port-Platform ] 445 [ NAS-Port-System-Id ] 446 [ NAS-Port-Call ] 447 [ NAS-Port-Software ] 448 [ NAS-Port-Vendor ] 449 [ NAS-Port-Shelf ] 450 [ NAS-Port-Slot ] 451 ... 453 4. Security Considerations 455 This document describes mechanisms where port termination-related 456 information can be sent between L2TP peers. Users of these AVPs 457 should have the understanding that any information sent could be used 458 for malicious purposes. If this is a concern, any of the L2TP 459 Extended NAS-Port List AVPs MAY be hidden. 461 5. IANA Considerations 463 All values referenced with AVP-TBP need to be assigned an IETF 464 "Attribute Type" from the "Control Message Attribute Value Pairs" 465 maintained by IANA for L2TP. 467 6. Acknowledgements 469 The authors wish to thank Carlos Pignato for comments received. 471 7. References 473 7.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 479 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 481 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 482 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 483 RFC 2661, August 1999. 485 7.2. Informative References 487 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 489 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 490 "Remote Authentication Dial In User Service (RADIUS)", 491 RFC 2865, June 2000. 493 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 494 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 496 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 497 10646", STD 63, RFC 3629, November 2003. 499 [I-D.ietf-l2tpext-tunnel-switching] 500 Jain, V., "PPP over L2TP Tunnel Switching", 501 draft-ietf-l2tpext-tunnel-switching-08 (work in progress), 502 March 2007. 504 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 505 "Diameter Network Access Server Application", RFC 4005, 506 August 2005. 508 Authors' Addresses 510 Neil McGill 511 cisco Systems 512 3rd Floor 513 96 Commercial Street 514 Edinburgh, EH6 6LX 515 UK 517 Email: nmcgill@cisco.com 519 Tom Mistretta 520 Juniper Networks 521 10 Technology Park Drive 522 Westford, MA 01886 523 US 525 Email: thomas.mistretta@verizon.net 526 Ignacio Goyret 527 Alcatel-Lucent 528 1801 Harbor Bay Parkway 529 Alameda, CA 94502 531 Email: igoyret@alcatel-lucent.com 533 W. Mark Townsley 534 cisco Systems 536 Email: mark@townsley.net 538 Greg Weber 539 cisco Systems 540 10850 Murdock Road 541 Knoxville, TN 37932 542 US 544 Email: gdweber@cisco.com 546 Full Copyright Statement 548 Copyright (C) The IETF Trust (2007). 550 This document is subject to the rights, licenses and restrictions 551 contained in BCP 78, and except as set forth therein, the authors 552 retain all their rights. 554 This document and the information contained herein are provided on an 555 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 556 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 557 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 558 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 559 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 560 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 562 Intellectual Property 564 The IETF takes no position regarding the validity or scope of any 565 Intellectual Property Rights or other rights that might be claimed to 566 pertain to the implementation or use of the technology described in 567 this document or the extent to which any license under such rights 568 might or might not be available; nor does it represent that it has 569 made any independent effort to identify any such rights. Information 570 on the procedures with respect to rights in RFC documents can be 571 found in BCP 78 and BCP 79. 573 Copies of IPR disclosures made to the IETF Secretariat and any 574 assurances of licenses to be made available, or the result of an 575 attempt made to obtain a general license or permission for the use of 576 such proprietary rights by implementers or users of this 577 specification can be obtained from the IETF on-line IPR repository at 578 http://www.ietf.org/ipr. 580 The IETF invites any interested party to bring to its attention any 581 copyrights, patents or patent applications, or other proprietary 582 rights that may cover technology that may be required to implement 583 this standard. Please address the information to the IETF at 584 ietf-ipr@ietf.org. 586 Acknowledgment 588 Funding for the RFC Editor function is provided by the IETF 589 Administrative Support Activity (IASA).