idnits 2.17.1 draft-ietf-radext-vlan-03.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 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 536. ** 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-802.1X' is mentioned on line 81, but not defined == Missing Reference: 'IEEE-8021.Q' is mentioned on line 208, but not defined == Missing Reference: 'IEEE-8021.D' is mentioned on line 335, but not defined == Unused Reference: 'IEEE802.1X' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'RFC3748' is defined on line 466, but no explicit reference was found in the text -- 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' -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 12 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 12 April 2006 Microsoft Corporation 8 RADIUS Attributes for Virtual LAN and Priority Support 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 October 10, 2006. 33 Copyright Notice 35 Copyright (C) The Internet Society 2006. 37 Abstract 39 This document proposes additional RADIUS (Remote Authentication Dial 40 In User Service) attributes for dynamic Virtual LAN assignment and 41 prioritization, for use in provisioning of access to IEEE 802 local 42 area networks. These attributes are usable within either RADIUS or 43 Diameter. 45 Table of Contents 47 1. Introduction .......................................... 3 48 1.1 Terminology ..................................... 3 49 1.2 Requirements Language ........................... 3 50 1.3 Attribute Interpretation ........................ 3 51 2. Attributes ............................................ 4 52 2.1 Egress-VLANID ................................... 4 53 2.2 Ingress-Filters ................................. 5 54 2.3 Egress-VLAN-Name ................................ 6 55 2.4 User-Priority-Table ............................. 7 56 3. Table of Attributes ................................... 9 57 4. Diameter Considerations ............................... 9 58 5. IANA Considerations ................................... 9 59 6. Security Considerations ............................... 9 60 7. References ............................................ 10 61 7.1 Normative References ............................ 10 62 7.2 Informative References .......................... 11 63 ACKNOWLEDGMENTS .............................................. 11 64 AUTHORS' ADDRESSES ........................................... 12 65 Intellectual Property Statement............................... 12 66 Disclaimer of Validity........................................ 13 67 Full Copyright Statement ..................................... 13 68 1. Introduction 70 This document describes Virtual LAN (VLAN) and re-prioritization 71 attributes that may prove useful for provisioning of access to IEEE 72 802 local area networks [IEEE-802] with the Remote Authentication 73 Dialin User Service (RADIUS). 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 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 [RFC4363]. 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 Network Access Server (NAS) 89 A device that provides an access service for a user to a network. 91 1.2. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 1.3. Attribute Interpretation 99 If a NAS conforming to this specification receives an Access-Accept 100 packet containing an attribute defined in this document which it 101 cannot apply, it MUST act as though it had received an Access-Reject. 103 Similarly, [RFC3576] requires that a NAS receiving a Change of 104 Authorization Request (CoA-Request) containing an unsupported 105 attribute reply with a CoA-NAK. It is recommended that an Error- 106 Cause attribute with value set to "Unsupported Attribute" (401) be 107 included in the packet. As noted in [RFC3576], authorization changes 108 are atomic so that this situation does not result in session 109 termination and the pre-existing configuration remains unchanged. As 110 a result, no accounting packets should be generated. 112 2. Attributes 114 2.1. Egress-VLANID 116 Description 118 The Egress-VLANID attribute represents an allowed IEEE 802 Egress 119 VLANID for this port, indicating if the VLANID is allowed for 120 tagged or untagged packets as well as the VLANID. 122 Multiple Egress-VLANID attributes MAY be included in Access- 123 Request, Access-Accept, CoA-Request or Accounting-Request packets; 124 this attribute MUST NOT be sent within an Access-Challenge, 125 Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, 126 CoA-ACK or CoA-NAK. Each attribute adds the specified VLAN to the 127 list of allowed egress VLANs for the port. 129 The Egress-VLANID attribute is shown below. The fields are 130 transmitted from left to right: 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Type | Length | Value 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 Value (cont) | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Type 142 TBD 144 Length 146 6 148 Value 150 The Value field is four octets. The format is described below: 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Tag Indic. | Pad | VLANID | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 The Tag Indication field is one octet in length, and indicates 159 whether the frames on the VLAN are tagged (0x31) or untagged 160 (0x32). The Pad field is 12-bits in length and MUST be 0 (zero). 161 The VLANID is 12-bits in length and contains the [IEEE-802.1Q] 162 VLAN VID value. 164 2.2. Ingress-Filters 166 Description 168 The Ingress-Filters attribute corresponds to the Ingress Filter 169 per-port variable defined in [IEEE-802.1Q] clause 8.4.5. When the 170 attribute has the value "Enabled", the set of VLANs that are 171 allowed to ingress a port must match the set of VLANs that are 172 allowed to egress a port. Only a single Ingress-Filters attribute 173 MAY be sent within an Access-Request, Access-Accept, CoA-Request 174 or Accounting-Request packet; this attribute MUST NOT be sent 175 within an Access-Challenge, Access-Reject, Disconnect-Request, 176 Disconnect-ACK, Disconnect-NAK, CoA-ACK or CoA-NAK. 178 The Ingress-Filters attribute is shown below. The fields are 179 transmitted from left to right: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type | Length | Value 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Value (cont) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Type 191 TBD 193 Length 195 6 197 Value 199 The Value field is four octets. Supported values include: 201 1 - Enabled 202 2 - Disabled 204 2.3. Egress-VLAN-Name 206 Description 208 Clause 12.10.2.1.3 (a) in [IEEE-8021.Q] describes the 209 administratively assigned VLAN Name associated with a VLAN-ID 210 defined within an IEEE 802.1Q bridge. The Egress-VLAN-Name 211 attribute represents an allowed VLAN for this port. It is similar 212 to the Egress-VLANID attribute, except that the VLAN-ID itself is 213 not specified or known; rather the VLAN name is used to identify 214 the VLAN within the system. 216 The Egress-VLAN-Name attribute contains two parts; the first part 217 indicates if frames on the VLAN for this port are to be 218 represented in tagged or untagged format, the second part is the 219 VLAN name. 221 Multiple Egress-VLAN-Name attributes MAY be included within an 222 Access-Request, Access-Accept, CoA-Request or Accounting-Request 223 packet; this attribute MUST NOT be sent within an Access- 224 Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, 225 Disconnect-NAK, CoA-ACK or CoA-NAK. Each attribute adds the named 226 VLAN to the list of allowed egress VLANs for the port. The 227 Egress-VLAN-Name attribute is shown below. The fields are 228 transmitted from left to right: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type | Length | Tag Indic. | String... 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Type 238 TBD 240 Length 242 >=4 244 Tag Indication 246 The Tag Indication field is one octet in length, and indicates 247 whether the frames on the VLAN are tagged (0x31, ASCII '1') or 248 untagged (0x32, ASCII '2'). These values were chosen so as to 249 make them easier for users to enter. 251 String 253 The String field is at least one octet in length, and contains the 254 the VLAN Name as defined in [IEEE-802.1Q] clause 12.10.2.1.3 (a). 255 [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a 256 robust implementation SHOULD support the field as undistinguished 257 octets. 259 2.4. User-Priority-Table 261 Description 263 [IEEE-802.1D] clause 7.5.1 discusses how to regenerate (or re-map) 264 user priority on frames received at a port. This per-port 265 configuration enables a bridge to cause the priority of received 266 traffic at a port to be mapped to a particular priority. 267 [IEEE-802.1D] clause 6.3.9 describes the use of remapping: 269 The ability to signal user priority in IEEE 802 LANs allows 270 user priority to be carried with end-to-end significance across 271 a Bridged Local Area Network. This, coupled with a consistent 272 approach to the mapping of user priority to traffic classes and 273 of user priority to access_priority, allows consistent use of 274 priority information, according to the capabilities of the 275 Bridges and MACs in the transmission path... 277 Under normal circumstances, user priority is not modified in 278 transit through the relay function of a Bridge; however, 279 network management can control how user priority is propagated. 280 Table 7-1 provides the ability to map incoming user priority 281 values on a per-Port basis. By default, the regenerated user 282 priority is identical to the incoming user priority. 284 This attribute represents the IEEE 802 prioritization that will be 285 applied to packets arriving at this port. There are eight 286 possible user priorities, according to the [IEEE-802] standard. 287 [IEEE-802.1D] clause 14.6.2.3.3 specifies the regeneration table 288 as 8 values, each an integer in the range 0-7. The management 289 variables are described in clause 14.6.2.2. 291 A single User-Priority-Table attribute MAY be included in an 292 Access-Accept or CoA-Request packet; this attribute MUST NOT be 293 sent within an Access-Request, Access-Challenge, Access-Reject, 294 Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, CoA- 295 NAK or Accounting-Request. Since the regeneration table is only 296 maintained by a bridge conforming to [IEEE-802.1D], this attribute 297 should only be sent to a RADIUS client supporting that 298 specification. 300 The User-Priority-Table attribute is shown below. The fields are 301 transmitted from left to right: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type | Length | String 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 String 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 String | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Type 315 TBD 317 Length 319 10 321 String 323 The String field is 8 octets in length, and includes a table which 324 maps the incoming priority (if it is set - the default is 0) into 325 one of eight regenerated priorities. The first octet maps to 326 incoming priority 0, the second octet to incoming priority 1, etc. 327 The values in each octet represent the regenerated priority of the 328 packet. 330 It is thus possible to either remap incoming priorities to more 331 appropriate values; to honor the incoming priorities; or to 332 override any incoming priorities, forcing them to all map to a 333 single chosen priority. 335 The [IEEE-8021.D] specification, Annex G, provides a useful 336 description of traffic type - traffic class mappings. 338 3. Table of Attributes 340 The following table provides a guide to which attributes may be found 341 in which kinds of packets, and in what quantity. 343 Access- Access- Access- Access- CoA- Acct- 344 Request Accept Reject Challenge Req Req # Attribute 345 0+ 0+ 0 0 0+ 0+ TBD Egress-VLANID 346 0-1 0-1 0 0 0-1 0-1 TBD Ingress-Filters 347 0+ 0+ 0 0 0+ 0+ TBD Egress-VLAN-Name 348 0 0-1 0 0 0-1 0 TBD User-Priority-Table 350 The following table defines the meaning of the above table entries. 352 0 This attribute MUST NOT be present in the packet. 353 0+ Zero or more instances of this attribute MAY be 354 present in the packet. 355 0-1 Zero or one instance of this attribute MAY be 356 present in the packet. 358 4. Diameter Considerations 360 Diameter needs to define identical attributes with the same Type 361 values. The attributes should be available as part of the NASREQ 362 application [RFC4005], as well as the Diameter EAP application 363 [RFC4072]. 365 5. IANA Considerations 367 This specification does not create any new registries. 369 This document uses the RADIUS [RFC2865] namespace, see 370 . Allocation of four 371 updates for the section "RADIUS Attribute Types" is requested. The 372 RADIUS attributes for which values are requested are: 374 TBD - Egress-VLANID 375 TBD - Ingress-Filters 376 TBD - Egress-VLAN-Name 377 TBD - User-Priority-Table 379 6. Security Considerations 381 This specification describes the use of RADIUS for purposes of 382 authentication, authorization and accounting in IEEE 802 local area 383 networks. Threats and security issues for this application are 384 described in [RFC3579] and [RFC3580]; security issues encountered in 385 roaming are described in [RFC2607]. 387 This document specifies new attributes that can be included in 388 existing RADIUS packets, which are protected as described in 389 [RFC3579] and [RFC3576]. See those documents for a more detailed 390 description. 392 The security mechanisms described in [RFC3579] and [RFC3576] are 393 focused on preventing an attacker from spoofing packets or modifying 394 packets in transit. They do not prevent an authorized RADIUS server 395 or proxy from inserting attributes with malicious intent. 397 VLAN attributes sent by a RADIUS server or proxy may enable access to 398 unauthorized VLANs. These vulnerabilities can be limited by 399 performing authorization checks at the NAS. For example, a NAS can 400 be configured to accept only certain VLANIDs from a given RADIUS 401 server/proxy. 403 Similarly, an attacker gaining control of a RADIUS server or proxy 404 can modify the user priority table, causing either degradation of 405 quality of service (by downgrading user priority of packets arriving 406 at a port), or denial of service (by raising the level of priority of 407 traffic at multiple ports of a device, oversubscribing the switch or 408 link capabilities). 410 7. References 412 7.1. Normative references 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", RFC 2119, March, 1997. 417 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 418 Authentication Dial In User Service (RADIUS)", RFC 2865, June 419 2000. 421 [RFC3629] Yergeau, F., "UTF-8, a transformation of ISO 10646", RFC 3629, 422 November 2003. 424 [RFC4363] Levi, D. and D. Harrington, "Definitions of Managed Objects 425 for Bridges with Traffic Classes, Multicast Filtering and 426 Virtual LAN Extensions", RFC 4363, January 2006. 428 [IEEE-802] 429 IEEE Standards for Local and Metropolitan Area Networks: 430 Overview and Architecture, ANSI/IEEE Std 802, 1990. 432 [IEEE-802.1D] 433 IEEE Standards for Local and Metropolitan Area Networks: Media 434 Access Control (MAC) Bridges, IEEE Std 802.1D-2004, June 2004. 436 [IEEE-802.1Q] 437 IEEE Standards for Local and Metropolitan Area Networks: Draft 438 Standard for Virtual Bridged Local Area Networks, 439 P802.1Q-2003, January 2003. 441 7.2. Informative references 443 [IEEE802.1X] 444 IEEE Standards for Local and Metropolitan Area Networks: Port 445 based Network Access Control, IEEE Std 802.1X-2004, December 446 2004. 448 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 449 Implementation in Roaming", RFC 2607, June 1999. 451 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 452 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 453 Support", RFC 2868, June 2000. 455 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 456 "Dynamic Authorization Extensions to Remote Authentication 457 Dial In User Service (RADIUS)", RFC 3576, July 2003. 459 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 460 Authentication Protocol (EAP)", RFC 3579, September 2003. 462 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 463 802.1X Remote Authentication Dial In User Service (RADIUS) 464 Usage Guidelines", RFC3580, September 2003. 466 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 467 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 468 3748, June 2004. 470 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 471 Network Access Server Application", RFC 4005, August 2005. 473 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 474 Authentication Protocol (EAP) Application", RFC 4072, August 475 2005. 477 Acknowledgments 479 The authors would like to acknowledge Joseph Salowey of Cisco, David 480 Nelson of Enterasys, Chuck Black of Hewlett Packard, and Ashwin 481 Palekar of Microsoft. 483 Authors' Addresses 485 Paul Congdon 486 Hewlett Packard Company 487 HP ProCurve Networking 488 8000 Foothills Blvd, M/S 5662 489 Roseville, CA 95747 491 EMail: paul.congdon@hp.com 492 Phone: +1 916 785 5753 493 Fax: +1 916 785 8478 495 Mauricio Sanchez 496 Hewlett Packard Company 497 HP ProCurve Networking 498 8000 Foothills Blvd, M/S 5559 499 Roseville, CA 95747 501 EMail: mauricio.sanchez@hp.com 502 Phone: +1 916 785 1910 503 Fax: +1 916 785 1815 505 Bernard Aboba 506 Microsoft Corporation 507 One Microsoft Way 508 Redmond, WA 98052 510 EMail: bernarda@microsoft.com 511 Phone: +1 425 706 6605 512 Fax: +1 425 936 7329 514 Intellectual Property Statement 516 The IETF takes no position regarding the validity or scope of any 517 Intellectual Property Rights or other rights that might be claimed to 518 pertain to the implementation or use of the technology described in 519 this document or the extent to which any license under such rights 520 might or might not be available; nor does it represent that it has 521 made any independent effort to identify any such rights. Information 522 on the procedures with respect to rights in RFC documents can be 523 found in BCP 78 and BCP 79. 525 Copies of IPR disclosures made to the IETF Secretariat and any 526 assurances of licenses to be made available, or the result of an 527 attempt made to obtain a general license or permission for the use of 528 such proprietary rights by implementers or users of this 529 specification can be obtained from the IETF on-line IPR repository at 530 http://www.ietf.org/ipr. 532 The IETF invites any interested party to bring to its attention any 533 copyrights, patents or patent applications, or other proprietary 534 rights that may cover technology that may be required to implement 535 this standard. Please address the information to the IETF at ietf- 536 ipr@ietf.org. 538 Disclaimer of Validity 540 This document and the information contained herein are provided on an 541 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 542 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 543 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 544 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 545 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 546 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 548 Copyright Statement 550 Copyright (C) The Internet Society (2006). This document is subject 551 to the rights, licenses and restrictions contained in BCP 78, and 552 except as set forth therein, the authors retain all their rights. 554 Acknowledgment 556 Funding for the RFC Editor function is currently provided by the 557 Internet Society. 559 Open issues 561 Open issues relating to this specification are tracked on the 562 following web site: 564 http://www.drizzle.com/~aboba/RADEXT/