draft-ietf-radext-fixes-00.txt   draft-ietf-radext-fixes-01.txt 
Network Working Group David Nelson Network Working Group David Nelson
INTERNET-DRAFT Enterasys Networks INTERNET-DRAFT Individual contributor
Updates: 2865, 2866, 2869, 3576, 3579 Alan DeKok Updates: 2865, 2866, 2869, 3576, 3579 Alan DeKok
Category: Proposed Standard FreeRADIUS Category: Proposed Standard FreeRADIUS
<draft-ietf-radext-fixes-00.txt> <draft-ietf-radext-fixes-01.txt>
19 December 2006 13 February 2007
Common RADIUS Implementation Issues and Suggested Fixes Common RADIUS Implementation Issues and Suggested Fixes
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 19, 2007. This Internet-Draft will expire on August 14, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2006). All rights reserved. Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes common issues seen in RADIUS implementations This document describes common issues seen in RADIUS implementations
and suggests some fixes. Where applicable, ambiguities and errors in and suggests some fixes. Where applicable, ambiguities and errors in
previous RADIUS specifications are clarified. previous RADIUS specifications are clarified.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction ............................................. 2
1.1 Terminology ..................................... 3 1.1. Terminology ......................................... 2
1.2 Requirements Language ........................... 3 1.2. Requirements Language ............................... 2
2. Issues ................................................ 4 2. Issues ................................................... 3
2.1 Session Definition .............................. 4 2.1. Session Definition .................................. 3
2.2 Overload Conditions ............................. 6 2.1.1. State Attribute ................................ 3
2.3 Accounting Issues ............................... 7 2.1.2. Request-ID Supplementation ..................... 4
2.4 Multiple Filter-ID Attributes ................... 9 2.2. Overload Conditions ................................. 4
2.5 Mandatory and Optional Attributes ............... 9 2.2.1. Retransmission Behavior ........................ 4
2.6 Interpretation of Access-Reject ................. 10 2.2.2. Server Response to Overload .................... 5
2.7 Addressing ...................................... 12 2.3. Accounting Issues ................................... 6
2.8 Idle Timeout .................................... 13 2.3.1. Attributes allowed in an Interim Update ........ 6
2.9 Unknown Identity ................................ 14 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 6
2.10 Responses after retransmissions ................. 15 2.3.3. Request Authenticator .......................... 6
2.11 Framed-IPv6-Prefix .............................. 15 2.3.4. Interim-Accounting-Interval .................... 7
3. IANA Considerations ................................... 16 2.3.5. Counter values in the RADIUS MIBs .............. 7
4. Security Considerations ............................... 16 2.4. Multiple Filter-ID Attributes ....................... 9
5. References ............................................ 17 2.5. Mandatory and Optional Attributes ................... 9
5.1 Informative References ................................ 17 2.6. Interpretation of Access-Reject ..................... 11
ACKNOWLEDGMENTS .............................................. 18 2.6.1. Improper Use of Access-Reject .................. 11
AUTHORS' ADDRESSES ........................................... 18 2.6.2. Service Request Denial ......................... 12
2.7. Addressing .......................................... 13
2.7.1. Link-Local Addresses ........................... 13
2.7.2. Multiple Addresses ............................. 13
2.8. Idle-Timeout ........................................ 14
2.9. Unknown Identity .................................... 14
2.10. Responses after retransmissions .................... 15
2.11. Framed-IPv6-Prefix ................................. 16
3. IANA Considerations ...................................... 17
4. Security Considerations .................................. 17
5. References ............................................... 17
5.1. Normative references. ............................... 17
5.2. Informative references. ............................. 18
Intellectual Property Statement .............................. 19 Intellectual Property Statement .............................. 19
Disclaimer of Validity ....................................... 22 Disclaimer of Validity ....................................... 21
Copyright Statement .......................................... 22 Full Copyright Statement ..................................... 21
1. Introduction 1. Introduction
The last few years have seen an increase in the deployment of RADIUS The last few years have seen an increase in the deployment of RADIUS
clients and servers. This document describes common issues seen in clients and servers. This document describes common issues seen in
RADIUS implementations and suggests some fixes. Where applicable, RADIUS implementations and suggests some fixes. Where applicable,
ambiguities and errors in previous RADIUS specifications are ambiguities and errors in previous RADIUS specifications are
clarified. clarified.
1.1. Terminology 1.1. Terminology
skipping to change at page 4, line 32 skipping to change at page 4, line 32
termination of the current session, it MUST include the State termination of the current session, it MUST include the State
attribute unchanged in that Access-Request. attribute unchanged in that Access-Request.
Some RADIUS client implementations do not properly use the State Some RADIUS client implementations do not properly use the State
attribute in order to distinguish a restarted EAP authentication attribute in order to distinguish a restarted EAP authentication
process from the continuation of an ongoing process (by the same user process from the continuation of an ongoing process (by the same user
on the same NAS and port). on the same NAS and port).
Where an EAP-Message attribute is included in an Access-Challenge or Where an EAP-Message attribute is included in an Access-Challenge or
Access-Accept attribute, RADIUS servers SHOULD also include a State Access-Accept attribute, RADIUS servers SHOULD also include a State
attribute. attribute. See the following section for additional benefits to
using the State attribute in this fashion.
An Access-Request sent as a result of a new or restarted An Access-Request sent as a result of a new or restarted
authentication run MUST NOT include the State attribute, even if the authentication run MUST NOT include the State attribute, even if the
State attribute has previously been received in an Access-Challenge State attribute has previously been received in an Access-Challenge
for the same user and port. for the same user and port.
Since a State attribute is always initially provided by the server in Since a State attribute is always initially provided by the server in
an Access-Accept, Access-Challenge, CoA-Request or Disconnect- an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
Request, a RADIUS client MUST NOT insert a State attribute that it Request, a RADIUS client MUST NOT insert a State attribute that it
has not previously received from the server. has not previously received from the server.
skipping to change at page 5, line 29 skipping to change at page 5, line 35
The FreeRADIUS implementation does not track EAP identifiers by NAS- The FreeRADIUS implementation does not track EAP identifiers by NAS-
IP-Address or other non-EAP attributes sent by the NAS. Instead, it IP-Address or other non-EAP attributes sent by the NAS. Instead, it
uses the EAP identifier, source IP address, and the State attribute uses the EAP identifier, source IP address, and the State attribute
as a "key" to uniquely identify each EAP session. Since the State as a "key" to uniquely identify each EAP session. Since the State
attribute is under the control of the RADIUS server, this means that attribute is under the control of the RADIUS server, this means that
the uniqueness of each session is controlled by the server, not the the uniqueness of each session is controlled by the server, not the
NAS. The algorithm used in FreeRADIUS is as follows: NAS. The algorithm used in FreeRADIUS is as follows:
if (EAP start, or EAP identity) { if (EAP start, or EAP identity) {
allocate unique State Attribute allocate unique State Attribute
insert session into "active session" table insert session into "active session" table with
with key (EAP identifier, State, source IP) key=(EAP identifier, State, source IP)
} else { } else {
look up active session in table, with above key look up active session in table, with above key
} }
This algorithm appears to work well in variety of situations, This algorithm appears to work well in variety of situations,
including situations where home servers receive messages via including situations where home servers receive messages via
intermediate RADIUS proxies. intermediate RADIUS proxies.
2.2. Overload Conditions 2.2. Overload Conditions
skipping to change at page 7, line 25 skipping to change at page 7, line 30
It is envisioned that an Interim Accounting record (with Acct- It is envisioned that an Interim Accounting record (with Acct-
Status-Type = Interim-Update (3)) would contain all of the Status-Type = Interim-Update (3)) would contain all of the
attributes normally found in an Accounting Stop message with the attributes normally found in an Accounting Stop message with the
exception of the Acct-Term-Cause attribute. exception of the Acct-Term-Cause attribute.
Although [RFC2869] does not indicate that it updates [RFC2866], this Although [RFC2869] does not indicate that it updates [RFC2866], this
is an oversight, and the above attributes are allowable in an Interim is an oversight, and the above attributes are allowable in an Interim
Accounting record. Accounting record.
2.3.2. NAS handling of Acct-Interim-Update 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id
[RFC2869] Section 2.1 states
It is also possible to statically configure an interim value on
the NAS itself. Note that a locally configured value on the NAS
MUST override the value found in an Access-Accept.
This requirement may be too strong in practice. If an implementator
chooses to permit the Acct-Interim-Interval in an Access-Accept to
override a global default for that value, then the implementation
MUST enforce a minimum acceptable value on the Acct-Interim-Interval
in an Access-Accept. The alternative would be to accept
inappropriately small values, which may have performance impact on
the NAS.
This minimum SHOULD be configurable on the NAS, as a "minimim
acceptable Acct-Intim-Interval".
2.3.3. Acct-Session-Id and Acct-Multi-Session-Id
[RFC2866] Section 5.5 describes Acct-Session-Id as Text within the [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the
description, but also states that "The String field SHOULD be a description, but also states that "The String field SHOULD be a
string of UTF-8 encoded 10646 characters." string of UTF-8 encoded 10646 characters."
Since Acct-Multi-Session-Id is consistently described as a String, it Since Acct-Multi-Session-Id is consistently described as a String, it
appears that this is a typographical error, and that Acct-Session-Id appears that this is a typographical error, and that Acct-Session-Id
is of type String. is of type String.
The implication is that a robust implementation SHOULD support the The implication is that a robust implementation SHOULD support the
String fields within Acct-Session-Id and Acct-Multi-Session-Id as String fields within Acct-Session-Id and Acct-Multi-Session-Id as
undistinguished octets. undistinguished octets.
2.3.4. Request Authenticator 2.3.3. Request Authenticator
[RFC2866] Section 4.1 states: [RFC2866] Section 4.1 states:
The Request Authenticator of an Accounting-Request contains a The Request Authenticator of an Accounting-Request contains a
16-octet MD5 hash value calculated according to the method 16-octet MD5 hash value calculated according to the method
described in "Request Authenticator" above. described in "Request Authenticator" above.
However, the text does not indicate any action to take when an However, the text does not indicate any action to take when an
Accounting-Request packet contains an invalid Request Authenticator. Accounting-Request packet contains an invalid Request Authenticator.
The following text should be considered to be part of the above The following text should be considered to be part of the above
description: description:
The Request Authenticator field MUST contain the correct data, as The Request Authenticator field MUST contain the correct data, as
given by the above calculation. Invalid packets are silently given by the above calculation. Invalid packets are silently
discarded. Note that some early implementations always set the discarded. Note that some early implementations always set the
Request Authenticator to all zeros. New implementations of RADIUS Request Authenticator to all zeros. New implementations of RADIUS
clients MUST use the above algorithm to calculate the Request clients MUST use the above algorithm to calculate the Request
Authenticator field. New RADIUS server implementations MUST Authenticator field. New RADIUS server implementations MUST
silently discard invalid packets. silently discard invalid packets.
2.3.4. Interim-Accounting-Interval
[RFC2869] Section 2.1 states:
It is also possible to statically configure an interim value on
the NAS itself. Note that a locally configured value on the NAS
MUST override the value found in an Access-Accept.
This requirement may be phrased too strongly. It is conceivable that
a NAS implementation has a setting for a "minimum" value of Interim-
Accounting-Interval, based on resource constraints in the NAS, and
network loading in the local environment of the NAS. In such cases,
the value administratively provisioned in the NAS should not be over-
ridden by a smaller value from an Access-Accept message. The NAS's
value could be over-ridden by a larger one, however. The intent is
that the NAS sends accounting information at fixed intervals, short
enough such that the potential loss of billable revenue is limited,
but also that the accounting updates are infrequent enough such that
the NAS, network, and RADIUS server are not overloaded.
2.3.5. Counter values in the RADIUS MIBs
The RADIUS Authentication and Authorization Client MIB module
[RFC2618], [RFC4668] includes counters of packet statistics. In the
descriptive text of the MIB module, formulas are provided for certain
counter objects. Implementors have noted apparent inconsistencies in
the formulas, which could result in negative values.
Since the original MIB module specified in [RFC2618] had been widely
implemented, the RADEXT WG chose not to change the object definitions
or to create new ones within the revised MIB module [RFC4668].
However, this section explains the issues and provides guidance for
implementors regarding the interpretation of the textual description
and comments for certain MIB objects.
The issues raised can be summarized as follows:
Issue (1):
-- TotalIncomingPackets = Accepts + Rejects + Challenges +
UnknownTypes
--
-- TotalIncomingPackets - MalformedResponses - BadAuthenticators -
-- UnknownTypes - PacketsDropped = Successfully received
--
-- AccessRequests + PendingRequests + ClientTimeouts =
-- Successfully Received
It appears that the value of "Successfully Received" could be
negative, since various counters are subtracted from
TotalIncomingPackets that are not included in the calculation of
TotalIncomingPackets.
It also appears that "AccessRequests + PendingRequests +
ClientTimeouts = Successfully Received" should read "AccessRequests +
PendingRequests + ClientTimeouts = Successfully Transmitted".
"TotalIncomingPackets" and "Successfully Received" are temporary
variables, i.e. not objects within the MIB module. The comment text
in the MIB modules is intended, therefore, to aid in understanding.
What's of consequence is the consistency of values of the objects in
the MIB module, and that does not appear to be impacted by the
inconsistencies noted above. It does appear, however, that the
"Successfully Received" variable should be labeled "Successfully
Transmitted".
In addition, the definition of Accept, Reject or Challenge counters
indicates that they MUST be incremented before the message is
validated. If the message is invalid, one of MalformedResponses,
BadAuthenticators or PacketsDropped counters will be additionally
incremented. In that case the first two equations are consistent,
i.e. "Successfully Received" could not be negative.
Issue (2):
It appears that the radiusAuthClientPendingRequests counter is
decremented upon retransmission. That would mean a retransmitted
packet is not considered as being as pending, although such
retransmissions can still be considered as being pending requests.
The definition of this MIB object in [RFC2618] is as follows:
The number of RADIUS Access-Request packets destined for this
server that have not yet timed out or received a response. This
variable is incremented when an Access-Request is sent and
decremented due to receipt of an Access-Accept, Access-Reject or
Access-Challenge, a timeout or retransmission.
This object purports to count the number of pending request packets.
It is open to interpretation whether or not retransmissions of a
request are to be counted as additional pending packets. In either
event, it seems appropriate to treat retransmissions consistently
with respect to incrementing and decrementing this counter.
2.4. Multiple Filter-ID Attributes 2.4. Multiple Filter-ID Attributes
[RFC2865] Section 5.11 states: [RFC2865] Section 5.11 states:
Zero or more Filter-Id attributes MAY be sent in an Access-Accept Zero or more Filter-Id attributes MAY be sent in an Access-Accept
packet. packet.
In practice the behavior of a RADIUS client receiving multiple In practice the behavior of a RADIUS client receiving multiple
Filter-ID attributes is implementation dependent. For example, some Filter-ID attributes is implementation dependent. For example, some
implementations treat multiple instances of the Filter-ID attribute implementations treat multiple instances of the Filter-ID attribute
skipping to change at page 12, line 4 skipping to change at page 13, line 40
0 0 0 0-1 75 Password-Retry [Note 2] 0 0 0 0-1 75 Password-Retry [Note 2]
[Note 2] As per RFC 3579, the use of the Password-Retry in EAP [Note 2] As per RFC 3579, the use of the Password-Retry in EAP
authentications is deprecated. The Password-Retry attribute can be authentications is deprecated. The Password-Retry attribute can be
used only for ARAP authentication. used only for ARAP authentication.
2.6.2. Service Request Denial 2.6.2. Service Request Denial
RADIUS has been deployed for purposes outside network access RADIUS has been deployed for purposes outside network access
authentication, authorization and accounting. For example, RADIUS authentication, authorization and accounting. For example, RADIUS
has been deployed as a "back-end" for authenticating VOIP has been deployed as a "back-end" for authenticating Voice Over IP
connections, HTTP sessions (e.g. Apache), FTP sessions (e.g. (VOIP) connections, HTTP sessions (e.g. Apache), FTP sessions (e.g.
proftpd), and machine logins for multiple operating systems (e.g. proftpd), and machine logins for multiple operating systems (e.g.
bsdi, pam, gina). In those contexts, an Access-Reject sent to the bsdi, pam, gina). In those contexts, an Access-Reject sent to the
RADIUS client MUST be interpreted as a rejection of the request for RADIUS client MUST be interpreted as a rejection of the request for
service, and the RADIUS client MUST NOT offer that service to the service, and the RADIUS client MUST NOT offer that service to the
user. user.
For example, when an authentication failure occurs in the context of For example, when an authentication failure occurs in the context of
an FTP session, the normal semantics for rejecting FTP services an FTP session, the normal semantics for rejecting FTP services
apply. The rejection does not necessarily cause the FTP server to apply. The rejection does not necessarily cause the FTP server to
terminate the underlying TCP connection, but the FTP server MUST NOT terminate the underlying TCP connection, but the FTP server MUST NOT
skipping to change at page 12, line 45 skipping to change at page 14, line 32
Disconnect-Request and CoA-Request packets, rather than just the Disconnect-Request and CoA-Request packets, rather than just the
User-Name attribute. User-Name attribute.
2.7. Addressing 2.7. Addressing
2.7.1. Link-Local Addresses 2.7.1. Link-Local Addresses
Since Link-Local addresses are unique only on the local link, if the Since Link-Local addresses are unique only on the local link, if the
NAS and RADIUS server are not on the same link, then an IPv6 Link- NAS and RADIUS server are not on the same link, then an IPv6 Link-
Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927] Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927]
cannot be used to uniquely identify the NAS. A RADIUS server cannot be used to uniquely identify the NAS. A NAS SHOULD NOT
receiving a NAS-IPv6-Address or NAS-IP-Address attribute containing a utilize a link-scope address within a NAS-IPv6-Address or NAS-IP-
Link-Local address SHOULD NOT count such an attribute toward Address attributes. A RADIUS server receiving a NAS-IPv6-Address or
satisfying the requirements of [RFC3162] Section 2.1: NAS-IP-Address attribute containing a Link-Local address SHOULD NOT
count such an attribute toward satisfying the requirements of
[RFC3162] Section 2.1:
NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an
Access-Request packet; however, if neither attribute is present Access-Request packet; however, if neither attribute is present
then NAS-Identifier MUST be present. then NAS-Identifier MUST be present.
2.7.2. Multiple Addresses 2.7.2. Multiple Addresses
There are situations in which a RADIUS client or server may have There are situations in which a RADIUS client or server may have
multiple addresses. For example, a dual stack host can have both multiple addresses. For example, a dual stack host can have both
IPv4 and IPv6 addresses; a host that is a member of multiple VLANs IPv4 and IPv6 addresses; a host that is a member of multiple VLANs
skipping to change at page 15, line 8 skipping to change at page 16, line 45
Note that [RFC4282] does not permit an NAI of zero octets, so that an Note that [RFC4282] does not permit an NAI of zero octets, so that an
EAP-Response/Identity with a Type-Data field of zero octets MUST NOT EAP-Response/Identity with a Type-Data field of zero octets MUST NOT
be construed as a request for privacy (e.g. anonymous NAI). be construed as a request for privacy (e.g. anonymous NAI).
When a NAS receives an EAP-Response/Identity with a Type-Data field When a NAS receives an EAP-Response/Identity with a Type-Data field
that is zero octets in length, it is RECOMMENDED that it either omit that is zero octets in length, it is RECOMMENDED that it either omit
a User-Name attribute in the Access-Request or include the Calling- a User-Name attribute in the Access-Request or include the Calling-
Station-Id in the User-Name attribute, along with a Calling-Station- Station-Id in the User-Name attribute, along with a Calling-Station-
Id attribute. Id attribute.
2.10. Responses after retransmissions. 2.10. Responses after retransmissions
Some implementations do not correctly handle the receipt of RADIUS Some implementations do not correctly handle the receipt of RADIUS
responses after retransmissions. [RFC2865] Section 2.5 states responses after retransmissions. [RFC2865] Section 2.5 states
If the NAS is retransmitting a RADIUS request to the same server If the NAS is retransmitting a RADIUS request to the same server
as before, and the attributes haven't changed, you MUST use the as before, and the attributes haven't changed, you MUST use the
same Request Authenticator, ID, and source port. If any same Request Authenticator, ID, and source port. If any
attributes have changed, you MUST use a new Request Authenticator attributes have changed, you MUST use a new Request Authenticator
and ID. and ID.
skipping to change at page 16, line 8 skipping to change at page 17, line 44
This Attribute indicates an IPv6 prefix (and corresponding route) This Attribute indicates an IPv6 prefix (and corresponding route)
to be configured for the user. It MAY be used in Access-Accept to be configured for the user. It MAY be used in Access-Accept
packets, and can appear multiple times. It MAY be used in an packets, and can appear multiple times. It MAY be used in an
Access-Request packet as a hint by the NAS to the server that it Access-Request packet as a hint by the NAS to the server that it
would prefer these prefix(es), but the server is not required to would prefer these prefix(es), but the server is not required to
honor the hint. Since it is assumed that the NAS will plumb a honor the hint. Since it is assumed that the NAS will plumb a
route corresponding to the prefix, it is not necessary for the route corresponding to the prefix, it is not necessary for the
server to also send a Framed-IPv6-Route attribute for the same server to also send a Framed-IPv6-Route attribute for the same
prefix. prefix.
If an ISP desires to support Prefix Delegation at the same time that An ISP may desire to support Prefix Delegation at the same time that
it would like to assign a prefix for the link between the NAS and it would like to assign a prefix for the link between the NAS and the
customer premises equipment (CPE). In this situation, the sematics of user. The intent of the paragraph was to enable the NAS to advertise
Framed-IPv6-Prefix may be unclear, in that it is difficult to know the prefix (such as via a Router Advertisement). If the Framed-
which prefixes are to be used for delegation, and which one is to be Routing attribute is used, it is also possible that the prefix would
used for the link. The intent of the paragraph was to enable the NAS be advertised in a routing protocol such as RIPNG. RFC 2865 Section
to advertise the prefix (such as via a Router Advertisement). If the 5.10 describes the purpose of Framed-Routing:
Framed-Routing attribute is used, it is also possible that the prefix
would be advertised in a routing protocol such as RIPNG. RFC 2865
Section 5.10 describes the purpose of Framed-Routing:
This Attribute indicates the routing method for the user, when the This Attribute indicates the routing method for the user, when the
user is a router to a network. It is only used in Access-Accept user is a router to a network. It is only used in Access-Accept
packets. packets.
The description of the Prefix-Length field in RFC 3162 indicates The description of the Prefix-Length field in RFC 3162 indicates
excessively wide latitude: excessively wide latitude:
The length of the prefix, in bits. At least 0 and no larger than The length of the prefix, in bits. At least 0 and no larger than
128. 128.
This length appears too broad, because it is not clear what a NAS This length appears too broad, because it is not clear what a NAS
should do with a prefix of greater granularity than /64. For example, should do with a prefix of greater granularity than /64. For example,
the Framed-IPv6-Prefix may contain a /128. This does not imply that the Framed-IPv6-Prefix may contain a /128. This does not imply that
the NAS should assign an IPv6 address to the end user, because RFC the NAS should assign an IPv6 address to the end user, because RFC
3162 already defines a Framed-IPv6-Identifier attribute to handle the 3162 already defines a Framed-IPv6-Identifier attribute to handle the
Identifier portion. Identifier portion.
It appears that the Framed-IPv6-Prefix is used for the link between It appears that the Framed-IPv6-Prefix is used for the link between
the NAS and CPE only if a /64 prefix is assigned. When a larger the NAS and CPE only if a /64 prefix is assigned. When a larger
prefix is sent, the intent is to provide the entire prefix to the prefix is sent, the intent is for the NAS to send a routing
CPE, enabling the CPE to assign sub-prefixes if it wishes to do so. advertisement containing the information present in the Framed-
IPv6-Prefix attribute.
3. IANA Considerations 3. IANA Considerations
This specification does not create any new registries, nor does it This specification does not create any new registries, nor does it
require assignment of any protocol parameters. require assignment of any protocol parameters.
4. Security Considerations 4. Security Considerations
Since this document describes the use of RADIUS for purposes of Since this document describes the use of RADIUS for purposes of
authentication, authorization, and accounting in WLANs, it is authentication, authorization, and accounting in WLANs, it is
vulnerable to all of the threats that are present in other RADIUS vulnerable to all of the threats that are present in other RADIUS
applications. For a discussion of these threats, see [RFC2865], applications. For a discussion of these threats, see [RFC2865],
[RFC2607], [RFC3162], [RFC3576], [RFC3579], and [RFC3580]. [RFC2607], [RFC3162], [RFC3576], [RFC3579], and [RFC3580].
5. References 5. References
5.1. Informative references 5.1. Normative references.
[RFC2865]
Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2866]
Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2869]
Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
2869, June 2000.
[RFC3576]
Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,
"Dynamic Authorization Extensions to Remote Authentication Dial In
User Service (RADIUS)", RFC 3576, July 2003.
[RFC3579]
Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
5.2. Informative references.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. Implementation in Roaming", RFC 2607, June 1999.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote [RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client MIB", RFC
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2618, June 1999.
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.
[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 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001. 3162, August 2001.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July
2003.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,
"Dynamic Authorization Extensions to Remote Authentication
Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003. (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004. 3748, June 2004.
[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of IPv4 Link-Local Addresses", RFC 3927, May 2005. of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005. Access Identifier", RFC 4282, December 2005.
[RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC
4668, August 2006.
Acknowledgments Acknowledgments
The authors would like to acknowledge Glen Zorn for contributions to The authors would like to acknowledge Glen Zorn and Bernard Aboba for
this document. contributions to this document.
The alternate algorithm to [RFC3579] Section 2.6.1 that is described The alternate algorithm to [RFC3579] Section 2.6.1 that is described
in section 2.1.2 of this document was designed by Raghu Dendukuri. in section 2.1.2 of this document was designed by Raghu Dendukuri.
David Nelson wishes to acknowledge the support of Enterasys Networks,
where he was employed during much of the work on this document.
Authors' Addresses Authors' Addresses
David B. Nelson David B. Nelson
Enterasys Networks (Independent contributor)
50 Minuteman Road 72 Old Chester Road
Andover, MA 01810 Derry, NH 03038
Email: dnelson@enterasys.com Email: d.b.nelson@comcast.net
Alan DeKok Alan DeKok
The FreeRADIUS Server Project The FreeRADIUS Server Project
http://freeradius.org/ http://freeradius.org/
Email: aland@freeradius.org Email: aland@freeradius.org
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
skipping to change at page 20, line 15 skipping to change at page 22, line 15
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006). This document is subject to the Copyright (C) The IETF Trust (2007).
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights. This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Open issues Open issues
Open issues relating to this specification are tracked on the Open issues relating to this specification are tracked on the
following web site: following web site:
 End of changes. 26 change blocks. 
111 lines changed or deleted 202 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/