| TOC |
|
By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
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.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 14, 2008.
This document specifies RADIUS [RFC2865] attributes supporting IPv6 network access to complement [RFC3162] in DHCP environments. It addresses the need to dynamically advertise DNS Server addresses and one or multiple IPv6 addresses via DHCPv6.
1.
Requirements notation
2.
Introduction
3.
Deployment scenario
4.
IPv6-Address Attribute
5.
IPv6-DNS Attribute
6.
Table of attributes
7.
Security Considerations
8.
IANA Considerations
9.
References
9.1.
Normative References
9.2.
Informative References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
This document specifies RADIUS attributes used to support DHCP based IPv6 access networks : DNS Server IPv6 address and IPv6 addresses.
| TOC |
The attributes defined in this document are targeted at enhancing the IPv6 access deployment scenarios involving DHCPv6 [RFC3315].
The IPv6-Address attribute is used by a router fulfilling DHCPv6 Server function for individual addresses when it receives configuration information from a RADIUS server, as illustrated in the following message sequence.
Router/Host (DHCPv6 Client) Router (DHCPv6 Server) RADIUS Server
| | |
|--Solicit(Address)-------->| |
| |-----Request------------------->|
| |<---------Accept(IPv6-Address)--|
|<-Advertise(Address)-------| |
|---Request(Address)------->| |
|<---Reply(Address)---------| |
This attributes offers an entire IPv6 address to the DHCPv6 Server in contrast to Interface-id [RFC3162] that offers only 64 bits. Even concatenated with Framed-IPv6 prefix [RFC3162] to make a 128 bit IPv6 address, this does not address scenarios where there is a need to offer multiple addresses or off-link IPv6 addresses that are not part of the prefix stored in the Framed-IPv6-Prefix attribute. Storing the IPv6 address in the subscriber RADIUS profile is particularly useful as the Service Provider will know in advance the customers uplink IPv6 address, hence facilitating management or security policy implementation.
The IPv6-DNS attribute is used by a router fulfilling DHCPv6 Server function for individual addresses when it receives configuration information from a RADIUS server, as illustrated in the following message sequence.
Router/Host (DHCPv6 Client) Router (DHCPv6 Server) RADIUS Server
| | |
|--Solicit (DNS)------------>| |
| |-Request----------------------->|
| |<-------Accept(Ipv6-DNS)--------|
|<-Advertise(DNS)------------| |
|-Request(DNS)-------------->| |
|<--Reply(DNS)---------------| |
The attributes offer the capability to specify IPv6 DNS Server address on a subscriber basis instead of hardcoding the value on the DHCP Server on a pool basis. This is particularly useful in wholesale scenarios where the list of DNS Servers to provide depends on the subscriber itself.
| TOC |
This Attribute indicates an IPv6 Address that is assigned to the uplink of the user equipment. This attribute will be mapped to Non-temporary Addresses option in DHCPv6. It MAY be used in Access-Accept 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 would prefer these IPv6 address(es), but the server is not required to honor the hint. Since it is assumed that the NAS, when necessary will add a route corresponding to the address, it is not necessary for the server to also send a host Framed-IPv6-Route attribute for the same address.
A summary of the IPv6-Address 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv6-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6-Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
x for IPv6-Address
Length
18
IPv6-Address
The IPv6-Address field is 16 octets.
| TOC |
The IPv6-DNS Attribute contains an ordered list of addresses of the Domain Name Service (DNS) Servers to be used by the DHCPv6 Client. This attribute is mapped into the DNS Recursive Name Server option [RFC3646]. This attribute MAY be included in both Access-Accept and Accounting-Request packets.
A summary of the IPv6-DNS Attribute format is given below. The fields are transmitted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv6-Address-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6-Address-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6-Address-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6-Address-1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6-Address-1 | IPv6-Address-2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6-Address-2 ....................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
y for IPv6-DNS
Length
2 + number of DNS Servers
IPv6-Address(es)
Each IPv6-Address in the list is 16 octets in length.
It contains the IPv6 addresses of the DNS servers.
| TOC |
The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity.
Request Accept Reject Challenge Accounting # Attribute
Request
0-1 0-1 0 0 0-1 x IPv6-Address
0 0-1 0 0 0-1 y IPv6-DNS
| TOC |
Security considerations do not differ from the one expressed in RFC3162.
| TOC |
This document requires the assignment of two new RADIUS attribute numbers for the following attributes:
IPv6-Address
IPv6-DNS
| TOC |
| TOC |
| [RFC3162] | Aboba, B., Zorn, G., and D. Mitton, “RADIUS and IPv6,” RFC 3162, August 2001 (TXT). |
| [RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” RFC 3315, July 2003 (TXT). |
| [RFC3646] | Droms, R., “DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” RFC 3646, December 2003 (TXT). |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC2865] | Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” RFC 2865, June 2000 (TXT). |
| TOC |
| Benoit Lourdelet | |
| Cisco Systems, Inc. | |
| Village ent. GreenSide, Bat T3, | |
| 400, Av de Roumanille, | |
| 06410 BIOT - Sophia-Antipolis Cedex | |
| France | |
| Phone: | +33 4 97 23 26 23 |
| Email: | blourdel@cisco.com |
| TOC |
Copyright © The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
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.