7
Network Working Group P. Congdon
8
Request for Comments: 4675 M. Sanchez
9
Category: Standards Track Hewlett-Packard Company
15
RADIUS Attributes for Virtual LAN and Priority Support
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.
27
Copyright (C) The Internet Society (2006).
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
58
Congdon, et al. Standards Track [Page 1]
60
RFC 4675 VLAN and Priority Attributes September 2006
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
114
Congdon, et al. Standards Track [Page 2]
116
RFC 4675 VLAN and Priority Attributes September 2006
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.
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.
137
This document uses the following terms:
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.
144
A RADIUS authentication server is an entity that provides an
145
authentication service to a NAS.
148
A RADIUS proxy acts as an authentication server to the NAS, and
149
a RADIUS client to the RADIUS server.
151
1.2. Requirements Language
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].
157
1.3. Attribute Interpretation
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.
170
Congdon, et al. Standards Track [Page 3]
172
RFC 4675 VLAN and Priority Attributes September 2006
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.
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.
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.
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.
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,
226
Congdon, et al. Standards Track [Page 4]
228
RFC 4675 VLAN and Priority Attributes September 2006
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.
234
The Egress-VLANID attribute is shown below. The fields are
235
transmitted from left to right:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
243
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
255
The Value field is four octets. The format is described below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]
282
Congdon, et al. Standards Track [Page 5]
284
RFC 4675 VLAN and Priority Attributes September 2006
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.
301
The Ingress-Filters attribute is shown below. The fields are
302
transmitted from left to right:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
310
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
322
The Value field is four octets. Supported values include:
338
Congdon, et al. Standards Track [Page 6]
340
RFC 4675 VLAN and Priority Attributes September 2006
343
2.3. Egress-VLAN-Name
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.
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.
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
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:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
394
Congdon, et al. Standards Track [Page 7]
396
RFC 4675 VLAN and Priority Attributes September 2006
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.
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
418
2.4. User-Priority-Table
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:
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...
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.
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
450
Congdon, et al. Standards Track [Page 8]
452
RFC 4675 VLAN and Priority Attributes September 2006
455
as 8 values, each an integer in the range 0-7. The management
456
variables are described in clause 14.6.2.2.
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
467
The User-Priority-Table attribute is shown below. The fields are
468
transmitted from left to right:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
476
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
478
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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.
506
Congdon, et al. Standards Track [Page 9]
508
RFC 4675 VLAN and Priority Attributes September 2006
511
The [IEEE-802.1D] specification, Annex G, provides a useful
512
description of traffic type - traffic class mappings.
514
3. Table of Attributes
516
The following table provides a guide to which attributes may be found
517
in which kinds of packets, and in what quantity.
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
526
The following table defines the meaning of the above table entries.
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.
534
4. Diameter Considerations
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:
542
+---------------------+
544
|----+-----+----+-----|----+
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
-------------------------------|----+-----+----+-----|----|
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]
562
Congdon, et al. Standards Track [Page 10]
564
RFC 4675 VLAN and Priority Attributes September 2006
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.
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.
579
What is said about COA-Request applies in Diameter to Re-Auth-Request
582
What is said about Accounting-Request applies to Diameter
583
Accounting-Request [RFC4005] as well.
585
5. IANA Considerations
587
This specification does not create any new registries.
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:
596
58 - Egress-VLAN-Name
597
59 - User-Priority-Table
599
6. Security Considerations
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].
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
618
Congdon, et al. Standards Track [Page 11]
620
RFC 4675 VLAN and Priority Attributes September 2006
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.
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.
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).
643
7.1. Normative References
645
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
646
Requirement Levels", BCP 14, RFC 2119, March 1997.
648
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
649
"Remote Authentication Dial In User Service (RADIUS)",
652
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
653
J. Arkko, "Diameter Base Protocol", RFC 3588, September
656
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
657
10646", STD 63, RFC 3629, November 2003.
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,
664
[IEEE-802] IEEE Standards for Local and Metropolitan Area
665
Networks: Overview and Architecture, ANSI/IEEE Std
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.
674
Congdon, et al. Standards Track [Page 12]
676
RFC 4675 VLAN and Priority Attributes September 2006
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.
683
7.2. Informative References
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.
689
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
690
Implementation in Roaming", RFC 2607, June 1999.
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.
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
701
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
702
Authentication Dial In User Service) Support For
703
Extensible Authentication Protocol (EAP)", RFC 3579,
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
711
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
712
"Diameter Network Access Server Application", RFC 4005,
715
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
716
Extensible Authentication Protocol (EAP) Application",
717
RFC 4072, August 2005.
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.
730
Congdon, et al. Standards Track [Page 13]
732
RFC 4675 VLAN and Priority Attributes September 2006
738
Hewlett-Packard Company
739
HP ProCurve Networking
740
8000 Foothills Blvd, M/S 5662
743
Phone: +1 916 785 5753
745
EMail: paul.congdon@hp.com
749
Hewlett-Packard Company
750
HP ProCurve Networking
751
8000 Foothills Blvd, M/S 5559
754
Phone: +1 916 785 1910
756
EMail: mauricio.sanchez@hp.com
760
Microsoft Corporation
764
Phone: +1 425 706 6605
766
EMail: bernarda@microsoft.com
786
Congdon, et al. Standards Track [Page 14]
788
RFC 4675 VLAN and Priority Attributes September 2006
791
Full Copyright Statement
793
Copyright (C) The Internet Society (2006).
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.
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.
807
Intellectual Property
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.
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.
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
833
Funding for the RFC Editor function is provided by the IETF
834
Administrative Support Activity (IASA).
842
Congdon, et al. Standards Track [Page 15]
added
removed
doc/rfc/rfc4675.txt
