draft-ietf-radext-design-06.txt   draft-ietf-radext-design-07.txt 
Network Working Group G. Weber Network Working Group G. Weber
INTERNET-DRAFT Individual Contributor INTERNET-DRAFT Individual Contributor
Category: Best Current Practice Alan DeKok (ed.) Category: Best Current Practice Alan DeKok (ed.)
<draft-ietf-radext-design-06.txt> FreeRADIUS <draft-ietf-radext-design-07.txt> FreeRADIUS
Expires: August 24, 2009 Expires: September 5, 2009
24 February 2009
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-06.txt
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. 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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 24, 2009. This Internet-Draft will expire on September 5, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 6, line 39 skipping to change at page 6, line 39
the SDO requirements, and which are also compatible with the the SDO requirements, and which are also compatible with the
traditional data model and uses of RADIUS. While these reviews traditional data model and uses of RADIUS. While these reviews
require access to public specifications, the review process does not require access to public specifications, the review process does not
require publication of an IETF RFC. require publication of an IETF RFC.
The advice in this document applies to attributes used to encode The advice in this document applies to attributes used to encode
service-provisioning or authentication data. RADIUS protocol service-provisioning or authentication data. RADIUS protocol
changes, or specification of attributes (such as Service-Type) that changes, or specification of attributes (such as Service-Type) that
can be used to, in effect, provide new RADIUS commands require can be used to, in effect, provide new RADIUS commands require
greater expertise and deeper review, as do changes to the RADIUS greater expertise and deeper review, as do changes to the RADIUS
operational model, as described in Section 3.3 . Such changes SHOULD operational model, as described in Section 3.3. Such changes MUST
NOT be undertaken outside the IETF and when handled within the IETF NOT be undertaken outside the IETF and when handled within the IETF
require "IETF Consensus" for adoption, as noted in [RFC3575] Section require "IETF Consensus" for adoption, as noted in [RFC3575] Section
2.1. 2.1.
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
Network Access Server (NAS) Network Access Server (NAS)
A device that provides an access service for a user to a network. A device that provides an access service for a user to a network.
skipping to change at page 14, line 38 skipping to change at page 14, line 38
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id | Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor-Id (cont) | Vendor type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor length | Attribute-Specific... | Vendor length | Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If additional functionality is required, the format defined in If additional functionality is required, the format defined in
[EXTEN] SHOULD be used. [EXTEN] SHOULD be used, with a non-zero Vendor-Id field.
Other attribute formats are NOT RECOMMENDED. Examples of NOT Other attribute formats are NOT RECOMMENDED. Examples of NOT
RECOMMENDED formats include Vendor types of more than 16 bits, Vendor RECOMMENDED formats include Vendor types of more than 16 bits, Vendor
lengths of less than 8 bits, Vendor lengths of more than 8 bits, and lengths of less than 8 bits, Vendor lengths of more than 8 bits, and
Vendor-Specific contents that are not in Type-Length-Value format. Vendor-Specific contents that are not in Type-Length-Value format.
In order to be compatible with the above recommendations for In order to be compatible with the above recommendations for
attribute definitions, it is RECOMMENDED that RADIUS servers support attribute definitions, it is RECOMMENDED that RADIUS servers support
attributes using a 16-bit Vendor type field. attributes using a 16-bit Vendor type field.
skipping to change at page 22, line 40 skipping to change at page 22, line 40
pre-provisioned on the NAS, then the name of the pre-provisioned pre-provisioned on the NAS, then the name of the pre-provisioned
policy can be transmitted in an attribute, rather than the policy can be transmitted in an attribute, rather than the
policy itself, which could be quite large. An example of this policy itself, which could be quite large. An example of this
is the Filter-Id Attribute defined in [RFC2865] Section 5.11, is the Filter-Id Attribute defined in [RFC2865] Section 5.11,
which enables a set of pre-provisioned filter rules to be which enables a set of pre-provisioned filter rules to be
referenced by name. referenced by name.
3. Utilization of Packetization Layer Path MTU Discovery 3. Utilization of Packetization Layer Path MTU Discovery
techniques, as specified in [RFC4821]. As a last resort, where techniques, as specified in [RFC4821]. As a last resort, where
the above techniques cannot be made to work, it may be possible the above techniques cannot be made to work, it may be possible
to apply the techniques described in [RFC4821] to discovery the to apply the techniques described in [RFC4821] to discover the
maximum supported RADIUS packet size on the path between a maximum supported RADIUS packet size on the path between a
RADIUS client and a home server. While such an approach can RADIUS client and a home server. While such an approach can
avoid the complexity of utilization of a sequence of packets, avoid the complexity of utilization of a sequence of packets,
dynamic discovery is likely to be time consuming and cannot be dynamic discovery is likely to be time consuming and cannot be
guaranteed to work with existing RADIUS implementations. As a guaranteed to work with existing RADIUS implementations. As a
result, this technique is not generally applicable. result, this technique is not generally applicable.
4. IANA Considerations 4. IANA Considerations
This document does not require that the IANA update any existing This document does not require that the IANA update any existing
 End of changes. 7 change blocks. 
10 lines changed or deleted 17 lines changed or added

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