doc/rfc/rfc4675.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         P. Congdon
   8 Request for Comments: 4675                                    M. Sanchez
   9 Category: Standards Track                        Hewlett-Packard Company
  10                                                                 B. Aboba
  11                                                    Microsoft Corporation
  12                                                           September 2006
  13
  14
  15          RADIUS Attributes for Virtual LAN and Priority Support
  16
  17 Status of This Memo
  18
  19    This document specifies an Internet standards track protocol for the
  20    Internet community, and requests discussion and suggestions for
  21    improvements.  Please refer to the current edition of the "Internet
  22    Official Protocol Standards" (STD 1) for the standardization state
  23    and status of this protocol.  Distribution of this memo is unlimited.
  24
  25 Copyright Notice
  26
  27    Copyright (C) The Internet Society (2006).
  28
  29 Abstract
  30
  31    This document proposes additional Remote Authentication Dial-In User
  32    Service (RADIUS) attributes for dynamic Virtual LAN assignment and
  33    prioritization, for use in provisioning of access to IEEE 802 local
  34    area networks.  These attributes are usable within either RADIUS or
  35    Diameter.
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Congdon, et al.             Standards Track                     [Page 1]
  59 \f
  60 RFC 4675              VLAN and Priority Attributes        September 2006
  61
  62
  63 Table of Contents
  64
  65    1. Introduction ....................................................3
  66       1.1. Terminology ................................................3
  67       1.2. Requirements Language ......................................3
  68       1.3. Attribute Interpretation ...................................3
  69    2. Attributes ......................................................4
  70       2.1. Egress-VLANID ..............................................4
  71       2.2. Ingress-Filters ............................................6
  72       2.3. Egress-VLAN-Name ...........................................7
  73       2.4. User-Priority-Table ........................................8
  74    3. Table of Attributes ............................................10
  75    4. Diameter Considerations ........................................10
  76    5. IANA Considerations ............................................11
  77    6. Security Considerations ........................................11
  78    7. References .....................................................12
  79       7.1. Normative References ......................................12
  80       7.2. Informative References ....................................13
  81    8. Acknowledgements ...............................................13
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Congdon, et al.             Standards Track                     [Page 2]
 115 \f
 116 RFC 4675              VLAN and Priority Attributes        September 2006
 117
 118
 119 1.  Introduction
 120
 121    This document describes Virtual LAN (VLAN) and re-prioritization
 122    attributes that may prove useful for provisioning of access to IEEE
 123    802 local area networks [IEEE-802] with the Remote Authentication
 124    Dial-In User Service (RADIUS) or Diameter.
 125
 126    While [RFC3580] enables support for VLAN assignment based on the
 127    tunnel attributes defined in [RFC2868], it does not provide support
 128    for a more complete set of VLAN functionality as defined by
 129    [IEEE-802.1Q].  The attributes defined in this document provide
 130    support within RADIUS and Diameter analogous to the management
 131    variables supported in [IEEE-802.1Q] and MIB objects defined in
 132    [RFC4363].  In addition, this document enables support for a wider
 133    range of [IEEE-802.1X] configurations.
 134
 135 1.1.  Terminology
 136
 137    This document uses the following terms:
 138
 139    Network Access Server (NAS)
 140         A device that provides an access service for a user to a
 141         network.  Also known as a RADIUS client.
 142
 143    RADIUS server
 144         A RADIUS authentication server is an entity that provides an
 145         authentication service to a NAS.
 146
 147    RADIUS proxy
 148         A RADIUS proxy acts as an authentication server to the NAS, and
 149         a RADIUS client to the RADIUS server.
 150
 151 1.2.  Requirements Language
 152
 153    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 154    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 155    document are to be interpreted as described in [RFC2119].
 156
 157 1.3.  Attribute Interpretation
 158
 159    The attributes described in this document apply to a single instance
 160    of a NAS port, or more specifically an IEEE 802.1Q bridge port.
 161    [IEEE-802.1Q], [IEEE-802.1D], and [IEEE-802.1X] do not recognize
 162    finer management granularity than "per port".  In some cases, such as
 163    with IEEE 802.11 wireless LANs, the concept of a "virtual port" is
 164    used in place of the physical port.  Such virtual ports are typically
 165    based on security associations and scoped by station, or Media Access
 166    Control (MAC) address.
 167
 168
 169
 170 Congdon, et al.             Standards Track                     [Page 3]
 171 \f
 172 RFC 4675              VLAN and Priority Attributes        September 2006
 173
 174
 175    The attributes defined in this document are applied on a per-user
 176    basis and it is expected that there is a single user per port;
 177    however, in some cases that port may be a "virtual port".  If a NAS
 178    implementation conforming to this document supports "virtual ports",
 179    it may be possible to provision those "virtual ports" with unique
 180    values of the attributes described in this document, allowing
 181    multiple users sharing the same physical port to each have a unique
 182    set of authorization parameters.
 183
 184    If a NAS conforming to this specification receives an Access-Accept
 185    packet containing an attribute defined in this document that it
 186    cannot apply, it MUST act as though it had received an Access-Reject.
 187    [RFC3576] requires that a NAS receiving a Change of Authorization
 188    Request (CoA-Request) reply with a CoA-NAK if the Request contains an
 189    unsupported attribute.  It is recommended that an Error-Cause
 190    attribute with the value set to "Unsupported Attribute" (401) be
 191    included in the CoA-NAK.  As noted in [RFC3576], authorization
 192    changes are atomic so that this situation does not result in session
 193    termination and the preexisting configuration remains unchanged.  As
 194    a result, no accounting packets should be generated.
 195
 196 2.  Attributes
 197
 198 2.1.  Egress-VLANID
 199
 200    Description
 201
 202       The Egress-VLANID attribute represents an allowed IEEE 802 Egress
 203       VLANID for this port, indicating if the VLANID is allowed for
 204       tagged or untagged frames as well as the VLANID.
 205
 206       As defined in [RFC3580], the VLAN assigned via tunnel attributes
 207       applies both to the ingress VLANID for untagged packets (known as
 208       the PVID) and the egress VLANID for untagged packets.  In
 209       contrast, the Egress-VLANID attribute configures only the egress
 210       VLANID for either tagged or untagged packets.  The Egress-VLANID
 211       attribute MAY be included in the same RADIUS packet as [RFC3580]
 212       tunnel attributes; however, the Egress-VLANID attribute is not
 213       necessary if it is being used to configure the same untagged
 214       VLANID included in tunnel attributes.  To configure an untagged
 215       VLAN for both ingress and egress, the tunnel attributes of
 216       [RFC3580] MUST be used.
 217
 218       Multiple Egress-VLANID attributes MAY be included in Access-
 219       Request, Access-Accept, CoA-Request, or Accounting-Request
 220       packets; this attribute MUST NOT be sent within an Access-
 221       Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK,
 222
 223
 224
 225
 226 Congdon, et al.             Standards Track                     [Page 4]
 227 \f
 228 RFC 4675              VLAN and Priority Attributes        September 2006
 229
 230
 231       Disconnect-NAK, CoA-ACK, or CoA-NAK.  Each attribute adds the
 232       specified VLAN to the list of allowed egress VLANs for the port.
 233
 234       The Egress-VLANID attribute is shown below.  The fields are
 235       transmitted from left to right:
 236
 237        0                   1                   2                   3
 238        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
 239       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 240       |     Type      |    Length     |            Value
 241       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 242               Value (cont)            |
 243       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 244
 245    Type
 246
 247       56
 248
 249    Length
 250
 251       6
 252
 253    Value
 254
 255       The Value field is four octets.  The format is described below:
 256
 257        0                   1                   2                   3
 258        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
 259       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 260       |  Tag Indic.   |        Pad            |       VLANID          |
 261       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 262
 263       The Tag Indication field is one octet in length and indicates
 264       whether the frames on the VLAN are tagged (0x31) or untagged
 265       (0x32).  The Pad field is 12 bits in length and MUST be 0 (zero).
 266       The VLANID is 12 bits in length and contains the [IEEE-802.1Q]
 267       VLAN VID value.
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Congdon, et al.             Standards Track                     [Page 5]
 283 \f
 284 RFC 4675              VLAN and Priority Attributes        September 2006
 285
 286
 287 2.2.  Ingress-Filters
 288
 289    Description
 290
 291       The Ingress-Filters attribute corresponds to the Ingress Filter
 292       per-port variable defined in [IEEE-802.1Q] clause 8.4.5.  When the
 293       attribute has the value "Enabled", the set of VLANs that are
 294       allowed to ingress a port must match the set of VLANs that are
 295       allowed to egress a port.  Only a single Ingress-Filters attribute
 296       MAY be sent within an Access-Request, Access-Accept, CoA-Request,
 297       or Accounting-Request packet; this attribute MUST NOT be sent
 298       within an Access-Challenge, Access-Reject, Disconnect-Request,
 299       Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK.
 300
 301       The Ingress-Filters attribute is shown below.  The fields are
 302       transmitted from left to right:
 303
 304        0                   1                   2                   3
 305        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
 306       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 307       |     Type      |    Length     |         Value
 308       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 309               Value (cont)            |
 310       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 311
 312    Type
 313
 314       57
 315
 316    Length
 317
 318       6
 319
 320    Value
 321
 322       The Value field is four octets.  Supported values include:
 323
 324       1 - Enabled
 325       2 - Disabled
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Congdon, et al.             Standards Track                     [Page 6]
 339 \f
 340 RFC 4675              VLAN and Priority Attributes        September 2006
 341
 342
 343 2.3.  Egress-VLAN-Name
 344
 345    Description
 346
 347       Clause 12.10.2.1.3 (a) in [IEEE-802.1Q] describes the
 348       administratively assigned VLAN Name associated with a VLAN-ID
 349       defined within an IEEE 802.1Q bridge.  The Egress-VLAN-Name
 350       attribute represents an allowed VLAN for this port.  It is similar
 351       to the Egress-VLANID attribute, except that the VLAN-ID itself is
 352       not specified or known; rather, the VLAN name is used to identify
 353       the VLAN within the system.
 354
 355       The tunnel attributes described in [RFC3580] and the Egress-VLAN-
 356       Name attribute both can be used to configure the egress VLAN for
 357       untagged packets.  These attributes can be used concurrently and
 358       MAY appear in the same RADIUS packet.  When they do appear
 359       concurrently, the list of allowed VLANs is the concatenation of
 360       the Egress-VLAN-Name and the Tunnel-Private-Group-ID (81)
 361       attributes.  The Egress-VLAN-Name attribute does not alter the
 362       ingress VLAN for untagged traffic on a port (also known as the
 363       PVID).  The tunnel attributes from [RFC3580] should be relied upon
 364       instead to set the PVID.
 365
 366       The Egress-VLAN-Name attribute contains two parts; the first part
 367       indicates if frames on the VLAN for this port are to be
 368       represented in tagged or untagged format, the second part is the
 369       VLAN name.
 370
 371       Multiple Egress-VLAN-Name attributes MAY be included within an
 372       Access-Request, Access-Accept, CoA-Request, or Accounting-Request
 373       packet; this attribute MUST NOT be sent within an Access-
 374       Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK,
 375       Disconnect-NAK, CoA-ACK, or CoA-NAK.  Each attribute adds the
 376       named VLAN to the list of allowed egress VLANs for the port.  The
 377       Egress-VLAN-Name attribute is shown below.  The fields are
 378       transmitted from left to right:
 379
 380        0                   1                   2                   3
 381        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
 382       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 383       |     Type      |    Length     |   Tag Indic.  |   String...
 384       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 385
 386    Type
 387
 388       58
 389
 390
 391
 392
 393
 394 Congdon, et al.             Standards Track                     [Page 7]
 395 \f
 396 RFC 4675              VLAN and Priority Attributes        September 2006
 397
 398
 399    Length
 400
 401       >=4
 402
 403    Tag Indication
 404
 405       The Tag Indication field is one octet in length and indicates
 406       whether the frames on the VLAN are tagged (0x31, ASCII '1') or
 407       untagged (0x32, ASCII '2').  These values were chosen so as to
 408       make them easier for users to enter.
 409
 410    String
 411
 412       The String field is at least one octet in length and contains the
 413       VLAN Name as defined in [IEEE-802.1Q] clause 12.10.2.1.3 (a).
 414       [RFC3629] UTF-8 encoded 10646 characters are RECOMMENDED, but a
 415       robust implementation SHOULD support the field as undistinguished
 416       octets.
 417
 418 2.4.  User-Priority-Table
 419
 420    Description
 421
 422       [IEEE-802.1D] clause 7.5.1 discusses how to regenerate (or re-map)
 423       user priority on frames received at a port.  This per-port
 424       configuration enables a bridge to cause the priority of received
 425       traffic at a port to be mapped to a particular priority.
 426       [IEEE-802.1D] clause 6.3.9 describes the use of remapping:
 427
 428          The ability to signal user priority in IEEE 802 LANs allows
 429          user priority to be carried with end-to-end significance across
 430          a Bridged Local Area Network.  This, coupled with a consistent
 431          approach to the mapping of user priority to traffic classes and
 432          of user priority to access_priority, allows consistent use of
 433          priority information, according to the capabilities of the
 434          Bridges and MACs in the transmission path...
 435
 436          Under normal circumstances, user priority is not modified in
 437          transit through the relay function of a Bridge; however,
 438          network management can control how user priority is propagated.
 439          Table 7-1 provides the ability to map incoming user priority
 440          values on a per-Port basis.  By default, the regenerated user
 441          priority is identical to the incoming user priority.
 442
 443       This attribute represents the IEEE 802 prioritization that will be
 444       applied to frames arriving at this port.  There are eight possible
 445       user priorities, according to the [IEEE-802] standard.
 446       [IEEE-802.1D] clause 14.6.2.3.3 specifies the regeneration table
 447
 448
 449
 450 Congdon, et al.             Standards Track                     [Page 8]
 451 \f
 452 RFC 4675              VLAN and Priority Attributes        September 2006
 453
 454
 455       as 8 values, each an integer in the range 0-7.  The management
 456       variables are described in clause 14.6.2.2.
 457
 458       A single User-Priority-Table attribute MAY be included in an
 459       Access-Accept or CoA-Request packet; this attribute MUST NOT be
 460       sent within an Access-Request, Access-Challenge, Access-Reject,
 461       Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, CoA-
 462       NAK or Accounting-Request.  Since the regeneration table is only
 463       maintained by a bridge conforming to [IEEE-802.1D], this attribute
 464       should only be sent to a RADIUS client supporting that
 465       specification.
 466
 467       The User-Priority-Table attribute is shown below.  The fields are
 468       transmitted from left to right:
 469
 470        0                   1                   2                   3
 471        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
 472       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 473       |     Type      |  Length       |          String
 474       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 475                                     String
 476       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 477                     String            |
 478       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 479
 480    Type
 481
 482       59
 483
 484    Length
 485
 486       10
 487
 488    String
 489
 490       The String field is 8 octets in length and includes a table that
 491       maps the incoming priority (if it is set -- the default is 0) into
 492       one of eight regenerated priorities.  The first octet maps to
 493       incoming priority 0, the second octet to incoming priority 1, etc.
 494       The values in each octet represent the regenerated priority of the
 495       frame.
 496
 497       It is thus possible to either remap incoming priorities to more
 498       appropriate values; to honor the incoming priorities; or to
 499       override any incoming priorities, forcing them to all map to a
 500       single chosen priority.
 501
 502
 503
 504
 505
 506 Congdon, et al.             Standards Track                     [Page 9]
 507 \f
 508 RFC 4675              VLAN and Priority Attributes        September 2006
 509
 510
 511       The [IEEE-802.1D] specification, Annex G, provides a useful
 512       description of traffic type - traffic class mappings.
 513
 514 3.  Table of Attributes
 515
 516    The following table provides a guide to which attributes may be found
 517    in which kinds of packets, and in what quantity.
 518
 519    Access- Access- Access- Access-   CoA-  Acct-
 520    Request Accept  Reject  Challenge Req   Req   #   Attribute
 521     0+      0+      0       0        0+    0+   56   Egress-VLANID
 522     0-1     0-1     0       0        0-1   0-1  57   Ingress-Filters
 523     0+      0+      0       0        0+    0+   58   Egress-VLAN-Name
 524     0       0-1     0       0        0-1   0    59   User-Priority-Table
 525
 526    The following table defines the meaning of the above table entries.
 527
 528      0     This attribute MUST NOT be present in the packet.
 529      0+    Zero or more instances of this attribute MAY be
 530            present in the packet.
 531      0-1   Zero or one instance of this attribute MAY be
 532            present in the packet.
 533
 534 4.  Diameter Considerations
 535
 536    When used in Diameter, the attributes defined in this specification
 537    can be used as Diameter attribute-value pair (AVPs) from the Code
 538    space 1-255 (RADIUS attribute compatibility space).  No additional
 539    Diameter Code values are therefore allocated.  The data types and
 540    flag rules for the attributes are as follows:
 541
 542                                   +---------------------+
 543                                   |    AVP Flag rules   |
 544                                   |----+-----+----+-----|----+
 545                                   |    |     |SHLD| MUST|    |
 546    Attribute Name      Value Type |MUST| MAY | NOT|  NOT|Encr|
 547    -------------------------------|----+-----+----+-----|----|
 548    Egress-VLANID       OctetString| M  |  P  |    |  V  | Y  |
 549    Ingress-Filters     Enumerated | M  |  P  |    |  V  | Y  |
 550    Egress-VLAN-Name    UTF8String | M  |  P  |    |  V  | Y  |
 551    User-Priority-Table OctetString| M  |  P  |    |  V  | Y  |
 552    -------------------------------|----+-----+----+-----|----|
 553
 554    The attributes in this specification have no special translation
 555    requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
 556    they are copied as is, except for changes relating to headers,
 557    alignment, and padding.  See also [RFC3588] Section 4.1 and [RFC4005]
 558    Section 9.
 559
 560
 561
 562 Congdon, et al.             Standards Track                    [Page 10]
 563 \f
 564 RFC 4675              VLAN and Priority Attributes        September 2006
 565
 566
 567    What this specification says about the applicability of the
 568    attributes for RADIUS Access-Request packets applies in Diameter to
 569    AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072].  What is said
 570    about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or
 571    Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to
 572    DIAMETER_MULTI_ROUND_AUTH.
 573
 574    What is said about Access-Accept applies in Diameter to AA-Answer or
 575    Diameter-EAP-Answer messages that indicate success.  Similarly, what
 576    is said about RADIUS Access-Reject packets applies in Diameter to
 577    AA-Answer or Diameter-EAP-Answer messages that indicate failure.
 578
 579    What is said about COA-Request applies in Diameter to Re-Auth-Request
 580    [RFC4005].
 581
 582    What is said about Accounting-Request applies to Diameter
 583    Accounting-Request [RFC4005] as well.
 584
 585 5.  IANA Considerations
 586
 587    This specification does not create any new registries.
 588
 589    This document uses the RADIUS [RFC2865] namespace; see
 590    <http://www.iana.org/assignments/radius-types>.  Allocation of four
 591    updates for the section "RADIUS Attribute Types" has been made by the
 592    IANA.  The RADIUS attributes are:
 593
 594    56 - Egress-VLANID
 595    57 - Ingress-Filters
 596    58 - Egress-VLAN-Name
 597    59 - User-Priority-Table
 598
 599 6.  Security Considerations
 600
 601    This specification describes the use of RADIUS and Diameter for
 602    purposes of authentication, authorization, and accounting in IEEE 802
 603    local area networks.  RADIUS threats and security issues for this
 604    application are described in [RFC3579] and [RFC3580]; security issues
 605    encountered in roaming are described in [RFC2607].  For Diameter, the
 606    security issues relating to this application are described in
 607    [RFC4005] and [RFC4072].
 608
 609    This document specifies new attributes that can be included in
 610    existing RADIUS packets, which are protected as described in
 611    [RFC3579] and [RFC3576].  In Diameter, the attributes are protected
 612    as specified in [RFC3588].  See those documents for a more detailed
 613    description.
 614
 615
 616
 617
 618 Congdon, et al.             Standards Track                    [Page 11]
 619 \f
 620 RFC 4675              VLAN and Priority Attributes        September 2006
 621
 622
 623    The security mechanisms supported in RADIUS and Diameter are focused
 624    on preventing an attacker from spoofing packets or modifying packets
 625    in transit.  They do not prevent an authorized RADIUS/Diameter server
 626    or proxy from inserting attributes with malicious intent.
 627
 628    VLAN attributes sent by a RADIUS/Diameter server or proxy may enable
 629    access to unauthorized VLANs.  These vulnerabilities can be limited
 630    by performing authorization checks at the NAS.  For example, a NAS
 631    can be configured to accept only certain VLANIDs from a given
 632    RADIUS/Diameter server/proxy.
 633
 634    Similarly, an attacker gaining control of a RADIUS/Diameter server or
 635    proxy can modify the user priority table, causing either degradation
 636    of quality of service (by downgrading user priority of frames
 637    arriving at a port), or denial of service (by raising the level of
 638    priority of traffic at multiple ports of a device, oversubscribing
 639    the switch or link capabilities).
 640
 641 7.  References
 642
 643 7.1.  Normative References
 644
 645    [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
 646                  Requirement Levels", BCP 14, RFC 2119, March 1997.
 647
 648    [RFC2865]     Rigney, C., Willens, S., Rubens, A., and W. Simpson,
 649                  "Remote Authentication Dial In User Service (RADIUS)",
 650                  RFC 2865, June 2000.
 651
 652    [RFC3588]     Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
 653                  J. Arkko, "Diameter Base Protocol", RFC 3588, September
 654                  2003.
 655
 656    [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
 657                  10646", STD 63, RFC 3629, November 2003.
 658
 659    [RFC4363]     Levi, D. and D. Harrington, "Definitions of Managed
 660                  Objects for Bridges with Traffic Classes, Multicast
 661                  Filtering, and Virtual LAN Extensions", RFC 4363,
 662                  January 2006.
 663
 664    [IEEE-802]    IEEE Standards for Local and Metropolitan Area
 665                  Networks:  Overview and Architecture, ANSI/IEEE Std
 666                  802, 1990.
 667
 668    [IEEE-802.1D] IEEE Standards for Local and Metropolitan Area
 669                  Networks: Media Access Control (MAC) Bridges, IEEE Std
 670                  802.1D-2004, June 2004.
 671
 672
 673
 674 Congdon, et al.             Standards Track                    [Page 12]
 675 \f
 676 RFC 4675              VLAN and Priority Attributes        September 2006
 677
 678
 679    [IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area
 680                  Networks: Draft Standard for Virtual Bridged Local Area
 681                  Networks, P802.1Q-2003, January 2003.
 682
 683 7.2.  Informative References
 684
 685    [IEEE-802.1X] IEEE Standards for Local and Metropolitan Area
 686                  Networks: Port based Network Access Control, IEEE Std
 687                  802.1X-2004, December 2004.
 688
 689    [RFC2607]     Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
 690                  Implementation in Roaming", RFC 2607, June 1999.
 691
 692    [RFC2868]     Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
 693                  Holdrege, M., and I. Goyret, "RADIUS Attributes for
 694                  Tunnel Protocol Support", RFC 2868, June 2000.
 695
 696    [RFC3576]     Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
 697                  Aboba, "Dynamic Authorization Extensions to Remote
 698                  Authentication Dial In User Service (RADIUS)", RFC
 699                  3576, July 2003.
 700
 701    [RFC3579]     Aboba, B. and P. Calhoun, "RADIUS (Remote
 702                  Authentication Dial In User Service) Support For
 703                  Extensible Authentication Protocol (EAP)", RFC 3579,
 704                  September 2003.
 705
 706    [RFC3580]     Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
 707                  Roese, "IEEE 802.1X Remote Authentication Dial In User
 708                  Service (RADIUS) Usage Guidelines", RFC 3580, September
 709                  2003.
 710
 711    [RFC4005]     Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
 712                  "Diameter Network Access Server Application", RFC 4005,
 713                  August 2005.
 714
 715    [RFC4072]     Eronen, P., Hiller, T., and G. Zorn, "Diameter
 716                  Extensible Authentication Protocol (EAP) Application",
 717                  RFC 4072, August 2005.
 718
 719 8.  Acknowledgements
 720
 721    The authors would like to acknowledge Joseph Salowey of Cisco, David
 722    Nelson of Enterasys, Chuck Black of Hewlett-Packard, and Ashwin
 723    Palekar of Microsoft.
 724
 725
 726
 727
 728
 729
 730 Congdon, et al.             Standards Track                    [Page 13]
 731 \f
 732 RFC 4675              VLAN and Priority Attributes        September 2006
 733
 734
 735 Authors' Addresses
 736
 737    Paul Congdon
 738    Hewlett-Packard Company
 739    HP ProCurve Networking
 740    8000 Foothills Blvd, M/S 5662
 741    Roseville, CA  95747
 742
 743    Phone: +1 916 785 5753
 744    Fax:   +1 916 785 8478
 745    EMail: paul.congdon@hp.com
 746
 747
 748    Mauricio Sanchez
 749    Hewlett-Packard Company
 750    HP ProCurve Networking
 751    8000 Foothills Blvd, M/S 5559
 752    Roseville, CA  95747
 753
 754    Phone: +1 916 785 1910
 755    Fax:   +1 916 785 1815
 756    EMail: mauricio.sanchez@hp.com
 757
 758
 759    Bernard Aboba
 760    Microsoft Corporation
 761    One Microsoft Way
 762    Redmond, WA 98052
 763
 764    Phone: +1 425 706 6605
 765    Fax:   +1 425 936 7329
 766    EMail: bernarda@microsoft.com
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786 Congdon, et al.             Standards Track                    [Page 14]
 787 \f
 788 RFC 4675              VLAN and Priority Attributes        September 2006
 789
 790
 791 Full Copyright Statement
 792
 793    Copyright (C) The Internet Society (2006).
 794
 795    This document is subject to the rights, licenses and restrictions
 796    contained in BCP 78, and except as set forth therein, the authors
 797    retain all their rights.
 798
 799    This document and the information contained herein are provided on an
 800    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 801    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 802    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 803    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 804    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 805    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 806
 807 Intellectual Property
 808
 809    The IETF takes no position regarding the validity or scope of any
 810    Intellectual Property Rights or other rights that might be claimed to
 811    pertain to the implementation or use of the technology described in
 812    this document or the extent to which any license under such rights
 813    might or might not be available; nor does it represent that it has
 814    made any independent effort to identify any such rights.  Information
 815    on the procedures with respect to rights in RFC documents can be
 816    found in BCP 78 and BCP 79.
 817
 818    Copies of IPR disclosures made to the IETF Secretariat and any
 819    assurances of licenses to be made available, or the result of an
 820    attempt made to obtain a general license or permission for the use of
 821    such proprietary rights by implementers or users of this
 822    specification can be obtained from the IETF on-line IPR repository at
 823    http://www.ietf.org/ipr.
 824
 825    The IETF invites any interested party to bring to its attention any
 826    copyrights, patents or patent applications, or other proprietary
 827    rights that may cover technology that may be required to implement
 828    this standard.  Please address the information to the IETF at
 829    ietf-ipr@ietf.org.
 830
 831 Acknowledgement
 832
 833    Funding for the RFC Editor function is provided by the IETF
 834    Administrative Support Activity (IASA).
 835
 836
 837
 838
 839
 840
 841
 842 Congdon, et al.             Standards Track                    [Page 15]
 843 \f