idnits 2.17.1 draft-ietf-radext-vlan-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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 556. ** 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 13 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 14 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 107, but not defined == Missing Reference: 'IEEE-802.11i' is mentioned on line 71, but not defined == Missing Reference: 'IEEE-8021.Q' is mentioned on line 226, but not defined == Missing Reference: 'IEEE-8021.D' is mentioned on line 329, but not defined == Unused Reference: 'RFC3575' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1X' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'IEEE802.11i' is defined on line 489, but no explicit reference was found in the text ** 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. 'IEEE802.1X' -- Duplicate reference: RFC2607, mentioned in 'RFC2607', was also mentioned in 'RFC3629'. -- 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: 4 errors (**), 0 flaws (~~), 10 warnings (==), 14 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 26 March 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 by IEEE 802.1X authenticators. These 42 attributes are usable within either RADIUS or Diameter. 44 Table of Contents 46 1. Introduction .......................................... 3 47 1.1 Terminology ..................................... 3 48 1.2 Requirements Language ........................... 3 49 1.3 Attribute Interpretation ........................ 4 50 2. Attributes ............................................ 4 51 2.1 Egress-VLANID ................................... 4 52 2.2 Ingress-Filters ................................. 5 53 2.3 Egress-VLAN-Name ................................ 6 54 2.4 User-Priority-Table ............................. 7 55 3. Table of Attributes ................................... 8 56 4. Diameter Considerations ............................... 9 57 5. IANA Considerations ................................... 9 58 6. Security Considerations ............................... 9 59 7. References ............................................ 10 60 7.1 Normative References ............................ 10 61 7.2 Informative References .......................... 10 62 ACKNOWLEDGMENTS .............................................. 12 63 AUTHORS' ADDRESSES ........................................... 12 64 Intellectual Property Statement............................... 13 65 Disclaimer of Validity........................................ 13 66 Full Copyright Statement ..................................... 13 67 1. Introduction 69 IEEE 802.1X [IEEE-802.1X] provides "network port authentication" for 70 IEEE 802 [IEEE-802] media, including Ethernet [IEEE-802.3], Token 71 Ring and 802.11 wireless LANs [IEEE-802.11][IEEE-802.11i]. 73 This document describes Virtual LAN (VLAN) and re-prioritization 74 attributes that may prove useful for provisioning of access to IEEE 75 802 local area networks with the Remote Authentication Dialin User 76 Service (RADIUS). 78 While [RFC3580] enables support for VLAN assignment based on the 79 tunnel attributes defined in [RFC2868], it does not provide support 80 for a more complete set of VLAN functionality as defined by 81 [IEEE-802.1Q]. The attributes defined in this document provide 82 support within RADIUS analogous to the management variables supported 83 in [IEEE-802.1Q] and MIB objects defined in [RFC4363]. In addition, 84 this document enables support for a wider range of [IEEE-802.1X] 85 configurations. 87 1.1. Terminology 89 This document uses the following terms: 91 Authenticator 92 The end of the link initiating EAP authentication. The term 93 authenticator is used in [RFC3748] and [IEEE-802.1X], and has the 94 same meaning in this document. 96 backend authentication server 97 A backend authentication server is an entity that provides an 98 authentication service to an authenticator. When used, this server 99 typically executes EAP methods for the authenticator. This 100 terminology is also used in [IEEE-802.1X]. 102 Network Access Server (NAS) 103 A device that provides an access service for a user to a network. 105 Supplicant 106 The end of the link that responds to the authenticator in 107 [IEEE-802.1X]. 109 1.2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 1.3. Attribute Interpretation 117 If a NAS conforming to this specification receives an Access-Accept 118 packet containing an attribute defined in this document which it 119 cannot apply, it MUST act as though it had received an Access-Reject. 121 Similarly, [RFC3576] requires that a NAS receiving a Change of 122 Authorization Request (CoA-Request) containing an unsupported 123 attribute reply with a CoA-NAK. It is recommended that an Error- 124 Cause attribute with value set to "Unsupported Attribute" (401) be 125 included in the packet. As noted in [RFC3576], authorization changes 126 are atomic so that this situation does not result in session 127 termination and the pre-existing configuration remains unchanged. As 128 a result, no accounting packets should be generated. 130 2. Attributes 132 2.1. Egress-VLANID 134 Description 136 The Egress-VLANID attribute represents an allowed IEEE 802 Egress 137 VLANID for this port, indicating if the VLANID is allowed for 138 tagged or untagged packets as well as the VLANID. 140 Multiple Egress-VLANID attributes MAY be included in an Access- 141 Request, Access-Accept or CoA-Request packet; this attribute MUST 142 NOT be sent within an Access-Challenge, Access-Reject, Disconnect- 143 Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK. 144 Each attribute adds the specified VLAN to the list of allowed 145 egress VLANs for the port. 147 The Egress-VLANID attribute is shown below. The fields are 148 transmitted from left to right: 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type | Length | Integer 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Integer | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Type 160 TBD 162 Length 163 6 165 Integer 167 The Integer field is four octets in length. The format is 168 described below: 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Tag Indic. | Pad | VLANID | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 The Tag Indication field is one octet in length, and indicates 177 whether the frames on the VLAN are tagged (0x31) or untagged 178 (0x32). The Pad field is 12-bits in length and MUST be 0 (zero). 179 The VLANID is 12-bits in length and contains the [IEEE-802.1Q] 180 VLAN VID value. 182 2.2. Ingress-Filters 184 Description 186 The Ingress-Filters attribute corresponds to Ingress Filter per- 187 port variable defined in [IEEE-802.1Q] clause 8.4.5. When the 188 attribute has the value "Enabled", the set of VLANs that are 189 allowed to ingress a port must match the set of VLANs that are 190 allowed to egress a port. Only a single Ingress-Filters attribute 191 MAY be sent within an Access-Request, Access-Accept or CoA-Request 192 packet; this attribute MUST NOT be sent within an Access- 193 Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, 194 Disconnect-NAK, CoA-ACK, or CoA-NAK. 196 The Ingress-Filters attribute is shown below. The fields are 197 transmitted from left to right: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Length | Integer 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Integer | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Type 209 TBD 211 Length 213 6 215 Integer 217 Supported values include: 219 1 - Enabled 220 2 - Disabled 222 2.3. Egress-VLAN-Name 224 Description 226 Clause 12.10.2.1.3 (a) in [IEEE-8021.Q] describes the 227 administratively assigned VLAN Name associated with a VLAN-ID 228 defined within an IEEE 802.1Q bridge. The Egress-VLAN-Name 229 attribute represents an allowed VLAN for this port. It is similar 230 to the Egress-VLANID attribute, except that the VLAN-ID itself is 231 not specified or known; rather the VLAN name is used to identify 232 the VLAN within the system. 234 The Egress-VLAN-Name attribute contains two parts; the first part 235 indicates if frames on the VLAN for this port are to be 236 represented in tagged or untagged format, the second part is the 237 VLAN name. 239 Multiple Egress-VLAN-Name attributes MAY be included within an 240 Access-Request, Access-Accept or CoA-Request packet; this 241 attribute MUST NOT be sent within an Access-Challenge, Access- 242 Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA- 243 ACK, or CoA-NAK. Each attribute adds the named VLAN to the list 244 of allowed egress VLANs for the port. The Egress-VLAN-Name 245 attribute is shown below. The fields are transmitted from left to 246 right: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type | Length | Tag Indic. | String... 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Type 256 TBD 258 Length 260 >=4 262 Tag Indication 264 The Tag Indication field is one octet in length, and indicates 265 whether the frames on the VLAN are tagged (0x31) or untagged 266 (0x32). 268 String 270 The String field is at least one octet in length, and contains the 271 the VLAN Name as defined in [IEEE-802.1Q] clause 12.10.2.1.3 (a). 272 [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a 273 robust implementation SHOULD support the field as undistinguished 274 octets. 276 2.4. User-Priority-Table 278 Description 280 [IEEE-802.1D] clause 7.5.1 discusses how to regenerate (or re-map) 281 user priority on frames received at a port. This per-port 282 configuration enables a bridge to cause the priority of received 283 traffic at a port to be mapped to a particular priority. The 284 management variables are described in clause 14.6.2.2. 286 This attribute represents the IEEE 802 prioritization that will be 287 applied to packets arriving at this port. There are eight 288 possible user priorities, according to the [IEEE-802] standard. A 289 single User-Priority-Table attribute MAY be included in an Access- 290 Request, Access-Accept or CoA-Request packet; this attribute MUST 291 NOT be sent within an Access-Challenge, Access-Reject, Disconnect- 292 Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK. 294 The User-Priority-Table attribute is shown below. The fields are 295 transmitted from left to right: 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type | Length | String 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 String 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 String | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Type 309 TBD 311 Length 313 10 315 String 317 The String field is 8 octets in length, and includes a table which 318 maps the incoming priority (if one exists - the default is 0) into 319 one of eight regenerated priorities. The first octet maps to 320 incoming priority 0, the second octet to incoming priority 1, etc. 321 The values in each octet represent the regenerated priority of the 322 packet. 324 It is thus possible to either remap incoming priorities to more 325 appropriate values; or to honor the incoming priorities; or to 326 override any incoming priorities, forcing them to all map to a 327 single chosen priority. 329 The [IEEE-8021.D] specification, Annex G, provides a useful 330 description of traffic type - traffic class mappings. 332 3. Table of Attributes 334 The following table provides a guide to which attributes may be found 335 in which kinds of packets, and in what quantity. 337 Access- Access- Access- Access- CoA- 338 Request Accept Reject Challenge Req # Attribute 339 0+ 0+ 0 0 0+ TBD Egress-VLANID 340 0-1 0-1 0 0 0-1 TBD Ingress-Filters 341 0+ 0+ 0 0 0+ TBD Egress-VLAN-Name 342 0-1 0-1 0 0 0-1 TBD User-Priority-Table 344 The following table defines the meaning of the above table entries. 346 0 This attribute MUST NOT be present in the packet. 347 0+ Zero or more instances of this attribute MAY be 348 present in the packet. 349 0-1 Zero or one instance of this attribute MAY be 350 present in the packet. 352 4. Diameter Considerations 354 Diameter needs to define identical attributes with the same Type 355 values. The attributes should be available as part of the NASREQ 356 application [RFC4005], as well as the Diameter EAP application 357 [RFC4072]. 359 5. IANA Considerations 361 This specification does not create any new registries. 363 This document uses the RADIUS [RFC2865] namespace, see 364 . Allocation of four 365 updates for the section "RADIUS Attribute Types" is requested. The 366 RADIUS attributes for which values are requested are: 368 TBD - Egress-VLANID 369 TBD - Ingress-Filters 370 TBD - Egress-VLAN-Name 371 TBD - User-Priority-Table 373 6. Security Considerations 375 This specification describes the use of RADIUS for purposes of 376 authentication, authorization and accounting in networks supporting 377 [IEEE 802.1X]. Threats and security issues for this application are 378 described in [RFC3579] and [RFC3580]; security issues encountered in 379 roaming are described in [RFC2607]. 381 This document specifies new attributes that can be included in 382 existing RADIUS packets, which are protected as described in 383 [RFC3579] and [RFC3576]. See those documents for a more detailed 384 description. 386 The security mechanisms described in [RFC3579] and [RFC3576] are 387 focused on preventing an attacker from spoofing packets or modifying 388 packets in transit. They do not prevent an authorized RADIUS server 389 or proxy from inserting attributes with malicious intent. 391 VLAN attributes sent by a RADIUS server or proxy may enable access to 392 unauthorized VLANs. These vulnerabilities can be limited by 393 performing authorization checks at the NAS. For example, a NAS can 394 be configured to accept only certain VLANIDs from a given RADIUS 395 server/proxy. 397 Similarly, an attacker gaining control of a RADIUS server or proxy 398 can modify the user priority table, causing either degradation of 399 quality of service (by downgrading user priority of packets arriving 400 at a port), or denial of service (by raising the level of priority of 401 traffic at multiple ports of a device, oversubscribing the switch or 402 link capabilities). 404 7. References 406 7.1. Normative references 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", RFC 2119, March, 1997. 411 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 412 Authentication Dial In User Service (RADIUS)", RFC 2865, June 413 2000. 415 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 416 2003. 418 [RFC3629] Yergeau, F., "UTF-8, a transformation of ISO 10646", RFC 2607, 419 November 2003. 421 [RFC4363] Levi, D. and D. Harrington, "Definitions of Managed Objects 422 for Bridges with Traffic Classes, Multicast Filtering and 423 Virtual LAN Extensions", RFC 4363, January 2006. 425 [IEEE-802] 426 IEEE Standards for Local and Metropolitan Area Networks: 427 Overview and Architecture, ANSI/IEEE Std 802, 1990. 429 [IEEE-802.1D] 430 IEEE Standards for Local and Metropolitan Area Networks: Media 431 Access Control (MAC) Bridges, IEEE Std 802.1D-2004, June 2004. 433 [IEEE-802.1Q] 434 IEEE Standards for Local and Metropolitan Area Networks: Draft 435 Standard for Virtual Bridged Local Area Networks, 436 P802.1Q-2003, January 2003. 438 [IEEE802.1X] 439 IEEE Standards for Local and Metropolitan Area Networks: Port 440 based Network Access Control, IEEE Std 802.1X-2004, December 441 2004. 443 7.2. Informative references 445 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 446 Implementation in Roaming", RFC 2607, June 1999. 448 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 449 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 450 Support", RFC 2868, June 2000. 452 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 453 "Dynamic Authorization Extensions to Remote Authentication 454 Dial In User Service (RADIUS)", RFC 3576, July 2003. 456 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 457 Authentication Protocol (EAP)", RFC 3579, September 2003. 459 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE 460 802.1X Remote Authentication Dial In User Service (RADIUS) 461 Usage Guidelines", RFC3580, September 2003. 463 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 464 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 465 3748, June 2004. 467 [RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter 468 Network Access Server Application", RFC 4005, August 2005. 470 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 471 Authentication Protocol (EAP) Application", RFC 4072, August 472 2005. 474 [IEEE-802.3] 475 ISO/IEC 8802-3 Information technology - Telecommunications and 476 information exchange between systems - Local and metropolitan 477 area networks - Common specifications - Part 3: Carrier Sense 478 Multiple Access with Collision Detection (CSMA/CD) Access 479 Method and Physical Layer Specifications, (also ANSI/IEEE Std 480 802.3- 1996), 1996. 482 [IEEE-802.11] 483 Information technology - Telecommunications and information 484 exchange between systems - Local and metropolitan area 485 networks - Specific Requirements Part 11: Wireless LAN Medium 486 Access Control (MAC) and Physical Layer (PHY) Specifications, 487 IEEE Std. 802.11- 2003, 2003. 489 [IEEE802.11i] 490 Institute of Electrical and Electronics Engineers, "Supplement 491 to Standard for Telecommunications and Information Exchange 492 Between Systems - LAN/MAN Specific Requirements - Part 11: 493 Wireless LAN Medium Access Control (MAC) and Physical Layer 494 (PHY) Specifications: Specification for Enhanced Security", 495 IEEE 802.11i, July 2004. 497 Acknowledgments 499 The authors would like to acknowledge Joseph Salowey of Cisco, David 500 Nelson of Enterasys, Chuck Black of Hewlett Packard, and Ashwin 501 Palekar of Microsoft. 503 Authors' Addresses 505 Paul Congdon 506 Hewlett Packard Company 507 HP ProCurve Networking 508 8000 Foothills Blvd, M/S 5662 509 Roseville, CA 95747 511 EMail: paul.congdon@hp.com 512 Phone: +1 916 785 5753 513 Fax: +1 916 785 8478 515 Mauricio Sanchez 516 Hewlett Packard Company 517 HP ProCurve Networking 518 8000 Foothills Blvd, M/S 5559 519 Roseville, CA 95747 521 EMail: mauricio.sanchez@hp.com 522 Phone: +1 916 785 1910 523 Fax: +1 916 785 1815 525 Bernard Aboba 526 Microsoft Corporation 527 One Microsoft Way 528 Redmond, WA 98052 530 EMail: bernarda@microsoft.com 531 Phone: +1 425 706 6605 532 Fax: +1 425 936 7329 534 Intellectual Property Statement 536 The IETF takes no position regarding the validity or scope of any 537 Intellectual Property Rights or other rights that might be claimed to 538 pertain to the implementation or use of the technology described in 539 this document or the extent to which any license under such rights 540 might or might not be available; nor does it represent that it has 541 made any independent effort to identify any such rights. Information 542 on the procedures with respect to rights in RFC documents can be 543 found in BCP 78 and BCP 79. 545 Copies of IPR disclosures made to the IETF Secretariat and any 546 assurances of licenses to be made available, or the result of an 547 attempt made to obtain a general license or permission for the use of 548 such proprietary rights by implementers or users of this 549 specification can be obtained from the IETF on-line IPR repository at 550 http://www.ietf.org/ipr. 552 The IETF invites any interested party to bring to its attention any 553 copyrights, patents or patent applications, or other proprietary 554 rights that may cover technology that may be required to implement 555 this standard. Please address the information to the IETF at ietf- 556 ipr@ietf.org. 558 Disclaimer of Validity 560 This document and the information contained herein are provided on an 561 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 562 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 563 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 564 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 565 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 566 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 568 Copyright Statement 570 Copyright (C) The Internet Society (2006). This document is subject 571 to the rights, licenses and restrictions contained in BCP 78, and 572 except as set forth therein, the authors retain all their rights. 574 Acknowledgment 576 Funding for the RFC Editor function is currently provided by the 577 Internet Society. 579 Open issues 581 Open issues relating to this specification are tracked on the 582 following web site: 584 http://www.drizzle.com/~aboba/RADEXT/