idnits 2.17.1 draft-ietf-radext-vlan-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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 525. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 531. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE-8021.Q' is mentioned on line 223, but not defined == Missing Reference: 'IEEE-8021.D' is mentioned on line 325, but not defined == Unused Reference: 'RFC3575' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.11' is defined on line 457, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2674 (Obsoleted by RFC 4363) ** Downref: Normative reference to an Informational RFC: RFC 2607 (ref. 'RFC3629') -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1D' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1Q' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1X' -- Duplicate reference: RFC2607, mentioned in 'RFC2607', was also mentioned in 'RFC3629'. -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Paul Congdon 3 INTERNET-DRAFT Mauricio Sanchez 4 Category: Proposed Standard Hewlett-Packard Company 5 Bernard Aboba 6 20 February 2006 Microsoft Corporation 8 RADIUS VLAN and Priority Attributes 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 10, 2006. 33 Copyright Notice 35 Copyright (C) The Internet Society 2006. 37 Abstract 39 This document proposes additional attributes for dynamic VLAN 40 assignment and prioritization, for use by IEEE 802.1X authenticators. 41 These attributes are usable within either RADIUS or Diameter. 43 Table of Contents 45 1. Introduction .......................................... 3 46 1.1 Terminology ..................................... 3 47 1.2 Requirements Language ........................... 3 48 1.3 Attribute Interpretation ........................ 4 49 2. Attributes ............................................ 4 50 2.1 Egress-VLANID ................................... 4 51 2.2 Ingress-Filters ................................. 5 52 2.3 Egress-VLAN-Name ................................ 6 53 2.4 User-Priority-Table ............................. 7 54 3. Table of Attributes ................................... 8 55 4. IANA Considerations ................................... 8 56 5. Security Considerations ............................... 9 57 6. References ............................................ 9 58 6.1 Normative References ............................ 9 59 6.2 Informative References .......................... 10 60 ACKNOWLEDGMENTS .............................................. 11 61 AUTHORS' ADDRESSES ........................................... 11 62 Intellectual Property Statement............................... 12 63 Disclaimer of Validity........................................ 13 64 Full Copyright Statement ..................................... 13 65 1. Introduction 67 IEEE 802.1X [IEEE-802.1X] provides "network port authentication" for 68 IEEE 802 [IEEE-802] media, including Ethernet [IEEE-802.3], Token 69 Ring and 802.11 wireless LANs [IEEE-802.11i]. 71 This document describes VLAN and re-prioritization attributes that 72 may prove useful for provisioning of access to IEEE 802 local area 73 networks. 75 While [RFC3580] enables support for VLAN assignment based on the 76 tunnel attributes defined in [RFC2868], it does not provide support 77 for a more complete set of VLAN functionality as defined by 78 [IEEE-802.1Q]. The VLAN attributes defined in this document provide 79 support within RADIUS analogous to the management variables supported 80 in [IEEE-802.1Q] and MIB objects defined in [RFC2674]. In addition, 81 this document enables support for a wider range of [IEEE-802.1X] 82 configurations. 84 1.1. Terminology 86 This document uses the following terms: 88 Authenticator 89 An authenticator is an entity that requires authentication 90 from the supplicant. The authenticator may be connected to 91 the supplicant at the other end of a point-to-point LAN 92 segment or 802.11 wireless link. 94 Authentication server 95 An authentication server is an entity that provides an 96 authentication service to an authenticator. This service 97 verifies from the credentials provided by the supplicant, the 98 claim of identity made by the supplicant. 100 Supplicant 101 A supplicant is an entity that is being authenticated by an 102 authenticator. The supplicant may be connected to the 103 authenticator at one end of a point-to-point LAN segment or 104 802.11 wireless link. 106 1.2. Requirements Language 108 In this document, several words are used to signify the requirements 109 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 110 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 111 and "OPTIONAL" in this document are to be interpreted as described in 112 [RFC2119]. 114 1.3. Attribute Interpretation 116 If a NAS conforming to this specification receives an Access-Accept 117 packet containing an attribute defined in this document which it 118 cannot apply, it MUST act as though it had received an Access-Reject. 120 Similarly, [RFC3576] requires that a NAS receiving a CoA-Request 121 containing an unsupported attribute reply with a CoA-NAK. It is 122 recommended that an Error-Cause attribute with value set to 123 Unsupported Attribute" (401) be included in the packet. As noted in 124 [RFC3576], authorization changes are atomic so that this situation 125 does not result in session termination and the pre-existing 126 configuration remains unchanged. As a result, no accounting packets 127 should be generated. 129 2. Attributes 131 2.1. Egress-VLANID 133 Description 135 The Egress-VLANID attribute represents an allowed IEEE 802 Egress 136 VLANID for this port, indicating if the VLANID is allowed for 137 tagged or untagged packets as well as the VLANID. 139 Multiple Egress-VLANID attributes MAY be included in an Access- 140 Accept or CoA-Request packet; this attribute MUST NOT be sent 141 within an Access-Request, Access-Challenge, Access-Reject, 142 Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or 143 CoA-NAK. Each attribute adds the specified VLAN to the list of 144 allowed egress VLANs for the port. 146 The Egress-VLANID attribute is shown below. The fields are 147 transmitted from left to right: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type | Length | Integer 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Integer | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Type 159 TBD 161 Length 162 6 164 Integer 166 The Integer field is four octets in length. The format is 167 described below: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | VLAN Tag | Pad | VLANID | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 The VLAN Tag field is one octet in length, and indicates whether 176 the frames on the VLAN are tagged (0x31) or untagged (0x32). The 177 Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is 178 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value. 180 2.2. Ingress-Filters 182 Description 184 The Ingress-Filters attribute corresponds to Ingress Filter per- 185 port variable defined in [IEEE-802.1Q] clause 8.4.5. When the 186 attribute has the value "Enabled", the set of VLANs that are 187 allowed to ingress a port must match the set of VLANs that are 188 allowed to egress a port. Only a single Ingress-Filters attribute 189 MAY be sent within an Access-Accept or CoA-Request packet; this 190 attribute MUST NOT be sent within an Access-Request, Access- 191 Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, 192 Disconnect-NAK, CoA-ACK, or CoA-NAK. 194 The Ingress-Filters attribute is shown below. The fields are 195 transmitted from left to right: 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Type | Length | Integer 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Integer | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Type 207 TBD 209 Length 210 6 212 Integer 214 Supported values include: 216 1 - Enabled 217 2 - Disabled 219 2.3. Egress-VLAN-Name 221 Description 223 Clause 12.10.2.1.3 (a) in [IEEE-8021.Q] describes the 224 administratively assigned VLAN Name associated with a VLAN-ID 225 defined within an IEEE 802.1Q bridge. The Egress-VLAN-Name 226 attribute represents an allowed VLAN for this port. It is similar 227 to the Egress-VLANID attribute, except that the VLAN-ID itself is 228 not specified or known; rather the VLAN name is used to identify 229 the VLAN within the system. 231 The Egress-VLAN-Name attribute contains two parts; the first part 232 indicates if frames on the VLAN for this port are to be 233 represented in tagged or untagged format, the second part is the 234 VLAN name. 236 Multiple Egress-VLAN-Name attributes MAY be included within an 237 Access-Accept or CoA-Request packet; this attribute MUST NOT be 238 sent within an Access-Request, Access-Challenge, Access-Reject, 239 Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or 240 CoA-NAK. Each attribute adds the named VLAN to the list of 241 allowed egress VLANs for the port. The Egress-VLAN-Name attribute 242 is shown below. The fields are transmitted from left to right: 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type | Length | VLAN Tag | String... 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Type 252 TBD 254 Length 256 >=4 258 VLAN Tag 260 The VLAN tag field is one octet in length, and indicates whether 261 the frames on the VLAN are tagged (0x31) or untagged (0x32). 263 String 265 The String field is at least one octet in length, and contains the 266 the VLAN Name as defined in [IEEE-802.1Q] clause 12.10.2.1.3 (a). 267 [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a 268 robust implementation SHOULD support the field as undistinguished 269 octets. 271 2.4. User-Priority-Table 273 Description 275 [IEEE-802.1D] clause 7.5.1 discusses how to regenerate (or re-map) 276 user priority on frames received at a port. This per-port 277 configuration enables a bridge to cause the priority of received 278 traffic at a port to be mapped to a particular priority. The 279 management variables are described in clause 14.6.2.2. 281 This attribute represents the IEEE 802 prioritization that will be 282 applied to packets arriving at this port. There are eight 283 possible user priorities, according to the [IEEE-802] standard. A 284 single User-Priority-Table attribute MAY be included in an Access- 285 Accept or CoA-Request packet; this attribute MUST NOT be sent 286 within an Access-Request, Access-Challenge, Access-Reject, 287 Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or 288 CoA-NAK. 290 The User-Priority-Table attribute is shown below. The fields are 291 transmitted from left to right: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length | String 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 String 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 String | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Type 305 TBD 307 Length 309 10 311 String 313 The String field is 8 octets in length, and includes a table which 314 maps the incoming priority (if one exists - the default is 0) into 315 one of eight regenerated priorities. The first octet maps to 316 incoming priority 0, the second octet to incoming priority 1, etc. 317 The values in each octet represent the regenerated priority of the 318 packet. 320 It is thus possible to either remap incoming priorities to more 321 appropriate values; or to honor the incoming priorities; or to 322 override any incoming priorities, forcing them to all map to a 323 single chosen priority. 325 The [IEEE-8021.D] specification, Annex G, provides a useful 326 description of traffic type - traffic class mappings. 328 3. Table of Attributes 330 The following table provides a guide to which attributes may be found 331 in which kinds of packets, and in what quantity. 333 Access- Access- Access- Access- CoA- 334 Request Accept Reject Challenge Req # Attribute 335 0 0+ 0 0 0+ TBD Egress-VLANID 336 0 0-1 0 0 0-1 TBD Ingress-Filters 337 0 0+ 0 0 0+ TBD Egress-VLAN-Name 338 0 0-1 0 0 0-1 TBD User-Priority-Table 340 The following table defines the meaning of the above table entries. 342 0 This attribute MUST NOT be present in the packet. 343 0+ Zero or more instances of this attribute MAY be 344 present in the packet. 345 0-1 Zero or one instance of this attribute MAY be 346 present in the packet. 348 4. IANA Considerations 350 This specification does not create any new registries. 352 This document uses the RADIUS [RFC2865] namespace, see 353 . Allocation of four 354 updates for the section "RADIUS Attribute Types" is requested. The 355 RADIUS attributes for which values are requested are: 357 TBD - Egress-VLANID 358 TBD - Ingress-Filters 359 TBD - Egress-VLAN-Name 360 TBD - User-Priority-Table 362 5. Security Considerations 364 Since this document describes the use of RADIUS for purposes of 365 authentication and authorization, and accounting in IEEE 802.1X- 366 enabled networks, it is vulnerable to all of the threats that are 367 present in other RADIUS applications. For a discussion of these 368 threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580]. 370 This document specifies new attributes that can be included in 371 existing RADIUS packets. These packets are protected as described in 372 [RFC3579] and [RFC3576]; see those documents for a more detailed 373 description and related security considerations. 375 The security mechanisms in [RFC3579] and [RFC3576] are primarily 376 concerned with an attacker attempting to spoof or modify messages in 377 transit. They do not prevent an authorized RADIUS server or proxy 378 from inserting attributes with malicious intent. 380 For example, modifications to VLAN attributes may enable access to 381 unauthorized VLANs. These vulnerabilities can be limited by 382 performing authorization checks at the NAS. For instance, a NAS can 383 be configured to accept only certain VLAN-IDs from a given RADIUS 384 server/proxy. 386 6. References 388 6.1. Normative references 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", RFC 2119, March, 1997. 393 [RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A., 394 McCloghrie, K., Definitions of Managed Objects for Bridges 395 with Traffic Classes, Multicast Filtering and Virtual LAN 396 Extensions", RFC 2674, August 1999. 398 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 399 Authentication Dial In User Service (RADIUS)", RFC 2865, June 400 2000. 402 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 403 2003. 405 [RFC3629] Yergeau, F., "UTF-8, a transformation of ISO 10646", RFC 2607, 406 November 2003. 408 [IEEE-802] 409 IEEE Standards for Local and Metropolitan Area Networks: 410 Overview and Architecture, ANSI/IEEE Std 802, 1990. 412 [IEEE-802.1D] 413 IEEE Standards for Local and Metropolitan Area Networks: Media 414 Access Control (MAC) Bridges, IEEE Std 802.1D-2004, June 2004. 416 [IEEE-802.1Q] 417 IEEE Standards for Local and Metropolitan Area Networks: Draft 418 Standard for Virtual Bridged Local Area Networks, 419 P802.1Q-2003, January 2003. 421 [IEEE-802.1X] 422 IEEE Standards for Local and Metropolitan Area Networks: Port 423 based Network Access Control, IEEE Std 802.1X-2004, August 424 2004. 426 6.2. Informative references 428 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 429 Implementation in Roaming", RFC 2607, June 1999. 431 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 432 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 433 Support", RFC 2868, June 2000. 435 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 436 3162, August 2001. 438 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 439 "Dynamic Authorization Extensions to Remote Authentication 440 Dial In User Service (RADIUS)", RFC 3576, July 2003. 442 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 443 Authentication Protocol (EAP)", RFC 3579, September 2003. 445 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 446 802.1X Remote Authentication Dial In User Service (RADIUS) 447 Usage Guidelines", RFC3580, September 2003. 449 [IEEE-802.3] 450 ISO/IEC 8802-3 Information technology - Telecommunications and 451 information exchange between systems - Local and metropolitan 452 area networks - Common specifications - Part 3: Carrier Sense 453 Multiple Access with Collision Detection (CSMA/CD) Access 454 Method and Physical Layer Specifications, (also ANSI/IEEE Std 455 802.3- 1996), 1996. 457 [IEEE-802.11] 458 Information technology - Telecommunications and information 459 exchange between systems - Local and metropolitan area 460 networks - Specific Requirements Part 11: Wireless LAN Medium 461 Access Control (MAC) and Physical Layer (PHY) Specifications, 462 IEEE Std. 802.11-1999, 1999. 464 [IEEE-802.11i] 465 Institute of Electrical and Electronics Engineers, "Supplement 466 to Standard for Telecommunications and Information Exchange 467 Between Systems - LAN/MAN Specific Requirements - Part 11: 468 Wireless LAN Medium Access Control (MAC) and Physical Layer 469 (PHY) Specifications: Specification for Enhanced Security", 470 June 2004. 472 Acknowledgments 474 The authors would like to acknowledge Joseph Salowey of Cisco, David 475 Nelson of Enterasys, Chuck Black of Hewlett Packard, and Ashwin 476 Palekar of Microsoft. 478 Authors' Addresses 480 Paul Congdon 481 Hewlett Packard Company 482 HP ProCurve Networking 483 8000 Foothills Blvd, M/S 5662 484 Roseville, CA 95747 486 EMail: paul.congdon@hp.com 487 Phone: +1 916 785 5753 488 Fax: +1 916 785 8478 490 Mauricio Sanchez 491 Hewlett Packard Company 492 HP ProCurve Networking 493 8000 Foothills Blvd, M/S 5559 494 Roseville, CA 95747 496 EMail: mauricio.sanchez@hp.com 497 Phone: +1 916 785 1910 498 Fax: +1 916 785 1815 500 Bernard Aboba 501 Microsoft Corporation 502 One Microsoft Way 503 Redmond, WA 98052 505 EMail: bernarda@microsoft.com 506 Phone: +1 425 706 6605 507 Fax: +1 425 936 7329 509 Intellectual Property Statement 511 The IETF takes no position regarding the validity or scope of any 512 Intellectual Property Rights or other rights that might be claimed to 513 pertain to the implementation or use of the technology described in 514 this document or the extent to which any license under such rights 515 might or might not be available; nor does it represent that it has 516 made any independent effort to identify any such rights. Information 517 on the procedures with respect to rights in RFC documents can be 518 found in BCP 78 and BCP 79. 520 Copies of IPR disclosures made to the IETF Secretariat and any 521 assurances of licenses to be made available, or the result of an 522 attempt made to obtain a general license or permission for the use of 523 such proprietary rights by implementers or users of this 524 specification can be obtained from the IETF on-line IPR repository at 525 http://www.ietf.org/ipr. 527 The IETF invites any interested party to bring to its attention any 528 copyrights, patents or patent applications, or other proprietary 529 rights that may cover technology that may be required to implement 530 this standard. Please address the information to the IETF at ietf- 531 ipr@ietf.org. 533 Disclaimer of Validity 535 This document and the information contained herein are provided on an 536 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 537 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 538 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 539 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 540 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 541 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 543 Copyright Statement 544 Copyright (C) The Internet Society (2006). This document is subject 545 to the rights, licenses and restrictions contained in BCP 78, and 546 except as set forth therein, the authors retain all their rights. 548 Acknowledgment 550 Funding for the RFC Editor function is currently provided by the 551 Internet Society. 553 Open issues 555 Open issues relating to this specification are tracked on the 556 following web site: 558 http://www.drizzle.com/~aboba/RADEXT/