📄 rfc4679.txt
字号:
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 141 (0x8D) for Maximum-Interleaving-Delay-DownstreamMammoliti, et al. Informational [Page 17] RFC 4679 DSL Forum RADIUS VSA September 2006 Vendor-Length 6 Value This field is a 4-byte unsigned integer, indicating the numeric value in milliseconds of the subscriber's DSL maximum one-way downstream interleaving delay.3.3.16. Actual-Interleaving-Delay-Downstream Description This Attribute contains the subscriber's actual one-way downstream interleaving delay. It MAY be included in Accounting-Request packets. A summary of the Actual-Interleaving-Delay-Downstream Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 142 (0x8E) for Actual-Interleaving-Delay-Downstream Vendor-Length 6 Value This field is a 4-byte unsigned integer, indicating the numeric value in milliseconds of the subscriber's DSL actual downstream interleaving delay.Mammoliti, et al. Informational [Page 18] RFC 4679 DSL Forum RADIUS VSA September 20063.3.17. Access-Loop-Encapsulation Description This Attribute describes the encapsulation(s) used by the subscriber on the DSL access loop. It MAY be present in both Access-Request and Accounting-Request packets. A summary of the Access-Loop-Encapsulation Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont'd) | +-+-+-+-+-+-+-+-+ Vendor-Type 144 (0x90) for Access-Loop-Encapsulation Vendor-Length 5 Value This field is a string 3 bytes in length, logically divided into three 1-byte sub-fields as shown in the following diagram: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Link | Encaps 1 | Encaps 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valid values for the sub-fields are as follows: Data Link 0x01 AAL5 0x02 EthernetMammoliti, et al. Informational [Page 19] RFC 4679 DSL Forum RADIUS VSA September 2006 Encaps 1 0x00 NA - Not Available 0x01 Untagged Ethernet 0x02 Single-Tagged Ethernet Encaps 2 0x00 NA - Not Available 0x01 PPPoA LLC 0x02 PPPoA Null 0x03 IPoA LLC 0x04 IPoA Null 0x05 Ethernet over AAL5 LLC with FCS 0x06 Ethernet over AAL5 LLC without FCS 0x07 Ethernet over AAL5 Null with FCS 0x08 Ethernet over AAL5 Null without FCS3.3.18. IWF-Session Description The presence of this Attribute indicates that the IWF has been performed with respect to the subscriber's session; note that no data field is necessary. It MAY be included in both Access- Request and Accounting-Request packets. A summary of the IWF-Session Attribute format is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Type | Vendor-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Type 254 (0xFE) for IWF-Session Vendor-Length 2Mammoliti, et al. Informational [Page 20] RFC 4679 DSL Forum RADIUS VSA September 20064. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity; note that since none of the DSL Forum VSAs may be present in the Access-Accept, Access- Reject or Access-Challenge packets, those columns have been omitted from the table. Request Acct-Request # Attribute 0-1 0-1 1 Agent-Circuit-Id 0-1 0-1 2 Agent-Remote-Id 0-1 0-1 129 Actual-Data-Rate-Upstream 0-1 0-1 130 Actual-Data-Rate-Downstream 0 0-1 131 Minimum-Data-Rate-Upstream 0 0-1 132 Minimum-Data-Rate-Downstream 0 0-1 133 Attainable-Data-Rate-Upstream 0 0-1 134 Attainable-Data-Rate-Downstream 0 0-1 135 Maximum-Data-Rate-Upstream 0 0-1 136 Maximum-Data-Rate-Downstream 0 0-1 137 Minimum-Data-Rate-Upstream-Low-Power 0 0-1 138 Minimum-Data-Rate-Downstream-Low-Power 0 0-1 139 Maximum-Interleaving-Delay-Upstream 0 0-1 140 Actual-Interleaving-Delay-Upstream 0 0-1 141 Maximum-Interleaving-Delay-Downstream 0 0-1 142 Actual-Interleaving-Delay-Downstream 0-1 0-1 144 Access-Loop-Encapsulation 0-1 0-1 254 IWF-Session The following table defines the meaning of the above table entries. 0 This Attribute MUST NOT be present in packet. 0-1 Zero or one instances of this Attribute MAY be present in packet.5. Security Considerations The security of these Attributes relies on an implied trust relationship between the Access Node/DSLAM and the BRAS. The identifiers that are inserted by the Access Node/DSLAM are unconditionally trusted; the BRAS does not perform any validity check on the information received. These Attributes are intended to be used in environments in which the network infrastructure (the Access Node/DSLAM, the BRAS, and the entire network in which those two devices reside) is trusted and secure.Mammoliti, et al. Informational [Page 21] RFC 4679 DSL Forum RADIUS VSA September 2006 As used in this document, the word "trusted" implies that unauthorized traffic cannot enter the network except through secured and trusted devices and that all devices internal to the network are secure and trusted. Careful consideration should be given to the potential security vulnerabilities that are present in this model before deploying this option in actual networks. The Attributes described in this document neither increase nor decrease the security of the RADIUS protocol. For discussions of various RADIUS vulnerabilities, see [RFC2607], [RFC3579], [RFC3162], and [RFC3580].6. References6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.6.2. Informative References [IANA] Internet Assigned Numbers Authority, "PRIVATE ENTERPRISE NUMBERS", January 2006, <http://www.iana.org/assignments/enterprise-numbers>. [ITU.I363-5.1996] International Telecommunications Union, "B-ISDN ATM Adaptation Layer Specification: Type 5 AAL", ITU-T Recommendation I.363.5, August 1996. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.Mammoliti, et al. Informational [Page 22] RFC 4679 DSL Forum RADIUS VSA September 2006 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. [RFC4243] Stapp, M., Johnson, R., and T. Palaniappan, "Vendor- Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4243, December 2005.Mammoliti, et al. Informational [Page 23] RFC 4679 DSL Forum RADIUS VSA September 2006Authors' Addresses Vince Mammoliti Cisco Systems 181 Bay Street, Suite 3400 Toronto, ON M5J 2T3 Canada EMail: vince@cisco.com Glen Zorn Cisco Systems 2901 Third Avenue, Suite 600 SEA1/5/ Seattle, WA 98121 USA Phone: +1 (425) 344 8113 EMail: gwz@cisco.com Peter Arberg Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 USA EMail: parberg@redback.com Robert Rennison ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 USA EMail: robert.rennison@ecitele.comMammoliti, et al. Informational [Page 24] RFC 4679 DSL Forum RADIUS VSA September 2006Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).Mammoliti, et al. Informational [Page 25] ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -