One document matched: draft-hu-v6ops-radius-issues-ipv6-00.txt
V6ops Jie. Hu
Internet-Draft Lu. Yan
Intended status: Informational Qian. Wang
Expires: August 13, 2011 China Telecom
Jacni. Qin
ZTE
February 9, 2011
RADIUS issues in IPv6 deployments
draft-hu-v6ops-radius-issues-ipv6-00
Abstract
RADIUS is a protocol that provides centralized authentication,
authorization and accounting management for users to connect network
services. In current practical broadband networks, RADIUS protocol
is widely used by ISPs when provisioning subscribers the access
services (e.g. PPPoE). The RADIUS protocol has currently been
specified to support both IPv4 and IPv6, while there are some issues
emerging from the deployments of IPv6.
Notes: This initial version is just to get the work started, and will
be updated soon.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 13, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Hu, et al. Expires August 13, 2011 [Page 1]
Internet-Draft RADIUS issues IPv6 February 2011
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Hu, et al. Expires August 13, 2011 [Page 2]
Internet-Draft RADIUS issues IPv6 February 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Issue 1: Identification of users of different protocols . . 4
2.2. Issue 2: Network or Host on Customer Premises? . . . . . . 4
2.3. Issue 3: Protocol Specific Accounting . . . . . . . . . . . 5
3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Hu, et al. Expires August 13, 2011 [Page 3]
Internet-Draft RADIUS issues IPv6 February 2011
1. Introduction
For the IPv6 network access, IPv6 related Attributes are specified in
[RFC3162], [RFC4818], [I-D.ietf-radext-ipv6-access]. Still, there
are some RADIUS operation issues that were missed or newly emerged.
This document tries to discuss these issues learnt from the IPv6
deployments and the possible solution spaces..
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Problem Statement
2.1. Issue 1: Identification of users of different protocols
Although Attributes are defined to convey configuration information
for different users (e.g., IPv4, IPv6, and other protocols) over
given access service, there is no Attribute specified for identifying
or authorizing the categories of users of different protocols (e.g.,
v4-only, v6-only, dual stack, or other protocols). Particularly, in
the case where configuration information assignment of different
network protocols are managed by NAS but not along with the
centralized authentication and authorization by RADIUS server, a
means is needed to notify NAS the categories of users according to
the result of authentication and authorization, either explicitly
(define a new attribute) or implicitly (re-use existing attributes).
2.2. Issue 2: Network or Host on Customer Premises?
In the provisioning mode where user!_s network is connected through a
RG for instance, a delegated prefix is needed to be assigned to the
RG which behaves as the delegating router. Or in other provisioning
mode, only a framed IPv6 address/prefix is needed to be assigned to
the accessing host. If the assignment is centralized managed by the
RADIUS server, the Delegated-IPv6-Prefix Attribute [RFC4818] or
Frame-IPv6-Address/Prefix should be used accordingly to convey the
information to authorized users. While if the configuration
information assignment is managed by NAS, there needs a means for
RADIUS server to notify NAS whether the user is authorized to be
assigned a delegated prefix or just a framed IPv6 address /prefix to
its NAS facing interface.
The possible approach can be either to define a dedicated Attribute
for the explicit notification, or to specify the rule of
Hu, et al. Expires August 13, 2011 [Page 4]
Internet-Draft RADIUS issues IPv6 February 2011
implementation of Attributes related, for example Frame-IPv6-Address/
Prefix Attribute and Delegated-IPv6-Prefix Attribute with special
value on RADIUS server for the notification to NAS as an instruction.
2.3. Issue 3: Protocol Specific Accounting
Accounting operations and Attributes are specified in [RFC2866] to
collect statistics for all traffic (including IPv4, IPv6, and other
protocols). In current practice, generally it is simply treated as
the statistics for IPv4 traffic. That works well since in most
cases, only IPv4 connectivity is provided over given access service
(e.g., PPPoE). While if IPv6 connectivity is provided as well, for
instance, there is no means by which the statistics for traffic of
respective protocols can be collected.
When to START/STOP the accounting in the context of multiple
protocols? And based on different accounting policies of operators?
(More elaborations needed)
3. Solution Space
The current practice or tentative solutions to the issues above will
be listed in this section.
To be added in the next revision...
4. IANA Considerations
This document includes no request to IANA.
5. Security Considerations
TBD
6. Acknowledgements
TBD
7. References
Hu, et al. Expires August 13, 2011 [Page 5]
Internet-Draft RADIUS issues IPv6 February 2011
7.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.
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867,
June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
7.2. Informative References
[I-D.ietf-radext-ipv6-access]
Lourdelet, B., Dec, W., Sarikaya, B., Zorn, G., and D.
Miles, "RADIUS attributes for IPv6 Access Networks",
draft-ietf-radext-ipv6-access-03 (work in progress),
January 2011.
[I-D.maglione-radext-ipv6-acct-extensions]
Maglione, R., Krishnan, S., Kavanagh, A., Varga, B., and
J. Kaippallimalil, "RADIUS Accounting Extensions for
IPv6", draft-maglione-radext-ipv6-acct-extensions-01 (work
in progress), March 2010.
[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended
RADIUS Practices", RFC 2882, July 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication
Dial-In User Service (RADIUS) Attributes Suboption for the
Dynamic Host Configuration Protocol (DHCP) Relay Agent
Information Option", RFC 4014, February 2005.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Hu, et al. Expires August 13, 2011 [Page 6]
Internet-Draft RADIUS issues IPv6 February 2011
Attribute", RFC 4818, April 2007.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007.
Authors' Addresses
Jie Hu
China Telecom
No.118, Xizhimennei
Beijing, 100035
China
Phone: +86 10 5855 2808
Email: huj@ctbri.com.cn
Lu Yan
China Telecom
No.19, Chaoyangmenbei
Beijing, 100010
China
Phone: +86 1891 023 0550
Email: yanlu@chinatelecom.com.cn
Qian Wang
China Telecom
No.118, Xizhimennei
Beijing, 100035
China
Phone: +86 10 5855 2177
Email: wangqian@ctbri.com.cn
Jacni Qin
ZTE
Shanghai,
China
Phone: +86 1391 861 9913
Email: jacniq@gmail.com
Hu, et al. Expires August 13, 2011 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-23 10:53:17 |