As per Relevance of the word indicate, we have this rfc below:
Network Working Group B.
Request for Comments: 3162
Category: Standards Track G.
Cisco
D.
Circular Logic UnLtd
August 2001
RADIUS and IPv
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document specifies the operation of RADIUS (
Authentication Dial In User Service) when run over IPv6 as well
the RADIUS attributes used to support IPv6 network access
1.
This document specifies the operation of RADIUS [4]-[8] over IPv
[13] as well as the RADIUS attributes used to support IPv6
access
Note that a NAS sending a RADIUS Access-Request may not know a-
whether the host will be using IPv4, IPv6, or both. For example
within PPP, IPv6CP [11] occurs after LCP, so that address
will not occur until after RADIUS authentication and
has completed
Therefore it is presumed that the IPv6 attributes described in
document MAY be sent along with IPv4-related attributes within
same RADIUS message and that the NAS will decide which attributes
use. The NAS SHOULD only allocate addresses and prefixes that
client can actually use, however. For example, there is no need
Aboba, et al. Standards Track [Page 1]
RFC 3162 RADIUS and IPv6 August 2001
the NAS to reserve use of an IPv4 address for a host that
supports IPv6; similarly, a host only using IPv4 or 6to4 [12]
not require allocation of an IPv6 prefix
The NAS can provide IPv6 access natively, or alternatively, via
methods such as IPv6 within IPv4 tunnels [15] or 6over4 [14].
choice of method for providing IPv6 access has no effect on
usage per se, although if it is desired that an IPv6 within IPv
tunnel be opened to a particular location, then tunnel
should be utilized, as described in [6], [7].
1.1. Requirements
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted
described in [1].
2.
2.1. NAS-IPv6-
This Attribute indicates the identifying IPv6 Address of the
which is requesting authentication of the user, and SHOULD
unique to the NAS within the scope of the RADIUS server. NAS
IPv6-Address is only used in Access-Request packets. NAS-IPv6-
Address and/or NAS-IP-Address MAY be present in an Access-
packet; however, if neither attribute is present then NAS
Identifier MUST be present
A summary of the NAS-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Aboba, et al. Standards Track [Page 2]
RFC 3162 RADIUS and IPv6 August 2001
95 for NAS-IPv6-
18
The Address field is 16 octets
3.2. Framed-Interface-
This Attribute indicates the IPv6 interface identifier to
configured for the user. It MAY be used in Access-Accept packets
If the Interface-Identifier IPv6CP option [11] has
successfully negotiated, this Attribute MUST be included in
Access-Request packet as a hint by the NAS to the server that
would prefer that value. It is recommended, but not required
that the server honor the hint
A summary of the Framed-Interface-Id 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 | Interface-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
96 for Framed-Interface-
10
Interface-
The Interface-Id field is 8 octets
Aboba, et al. Standards Track [Page 3]
RFC 3162 RADIUS and IPv6 August 2001
2.3. Framed-IPv6-
This Attribute indicates an IPv6 prefix (and corresponding route
to be configured for the user. It MAY be used in Access-
packets, and can appear multiple times. It MAY be used in
Access-Request packet as a hint by the NAS to the server that
would prefer these prefix(es), but the server is not required
honor the hint. Since it is assumed that the NAS will plumb
route corresponding to the prefix, it is not necessary for
server to also send a Framed-IPv6-Route attribute for the
prefix
A summary of the Framed-IPv6-Prefix 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 | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
97 for Framed-IPv6-
At least 4 and no larger than 20.
This field, which is reserved and MUST be present, is always
to zero
Prefix-
The length of the prefix, in bits. At least 0 and no larger
128.
Aboba, et al. Standards Track [Page 4]
RFC 3162 RADIUS and IPv6 August 2001
The Prefix field is up to 16 octets in length. Bits outside
the Prefix-Length, if included, must be zero
2.4. Login-IPv6-
This Attribute indicates the system with which to connect
user, when the Login-Service Attribute is included. It MAY
used in Access-Accept packets. It MAY be used in an Access
Request packet as a hint to the server that the NAS would
to use that host, but the server is not required to honor
hint
A summary of the Login-IPv6-Host 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
98 for Login-IPv6-
18
Aboba, et al. Standards Track [Page 5]
RFC 3162 RADIUS and IPv6 August 2001
The Address field is 16 octets in length. The
0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS
allow the user to select an address or name to be connected to
The value 0 indicates that the NAS SHOULD select a host to
the user to. Other values indicate the address the NAS
connect the user to
2.5. Framed-IPv6-
This Attribute provides routing information to be configured
the user on the NAS. It is used in the Access-Accept packet
can appear multiple times
A summary of the Framed-IPv6-Route Attribute format is shown below
The fields are transmitted from left to right
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
99 for Framed-IPv6-
>=3
The Text field is one or more octets, and its contents
implementation dependent. The field is not NUL (hex 00)
terminated. It is intended to be human readable and MUST
affect operation of the protocol
For IPv6 routes, it SHOULD contain a destination prefix
followed by a slash and a decimal length specifier stating
many high order bits of the prefix to use. That is followed by
space, a gateway address, a space, and one or more
(encoded in decimal) separated by spaces. Prefixes and
are formatted as described in [16]. For example
"2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".
Aboba, et al. Standards Track [Page 6]
RFC 3162 RADIUS and IPv6 August 2001
Whenever the gateway address is the IPv6 unspecified address
IP address of the user SHOULD be used as the gateway address.
unspecified address can be expressed in any of the
formats described in [16]. For example, "2000:0:0:106::/64 :: 1".
2.6. Framed-IPv6-
This Attribute contains the name of an assigned pool that
be used to assign an IPv6 prefix for the user. If a NAS does
support multiple prefix pools, the NAS MUST ignore this Attribute
A summary of the Framed-IPv6-Pool Attribute format is shown below
The fields are transmitted from left to right
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
100 for Framed-IPv6-
>= 3
The string field contains the name of an assigned IPv6 prefix
configured on the NAS. The field is not NUL (hex 00) terminated
3. Table of
The following table provides a guide to which attributes may be
in which kinds of packets, and in what quantity
Request Accept Reject Challenge Accounting #
0-1 0 0 0 0-1 95 NAS-IPv6-
0-1 0-1 0 0 0-1 96 Framed-Interface-
0+ 0+ 0 0 0+ 97 Framed-IPv6-
0+ 0+ 0 0 0+ 98 Login-IPv6-
0 0+ 0 0 0+ 99 Framed-IPv6-
0 0-1 0 0 0-1 100 Framed-IPv6-
Aboba, et al. Standards Track [Page 7]
RFC 3162 RADIUS and IPv6 August 2001
4.
[1] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March, 1997.
[2] Yergeau, F., "UTF-8, a transformation format of Unicode and
10646", RFC 2044, October 1996.
[3] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
Implementation in Roaming", RFC 2607, June 1999.
[4] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "
Authentication Dial In User Service (RADIUS)", RFC 2865,
2000.
[5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[6] Zorn, G., Mitton, D. and B. Aboba, "RADIUS
Modifications for Tunnel Protocol Support", RFC 2867,
2000.
[7] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M
and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",
RFC 2868, June 2000.
[8] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions",
RFC 2869, June 2000.
[9] Kent S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.
[10] Alvestrand, H. and T. Narten, "Guidelines for Writing an
Considerations Section in RFCs", BCP 26, RFC 2434,
1998.
[11] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.
[12] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
IPv4 Clouds", RFC 3056, February 2001.
[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[14] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv
Domains without Explicit Tunnels", RFC 2529, March 1999.
Aboba, et al. Standards Track [Page 8]
RFC 3162 RADIUS and IPv6 August 2001
[15] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv
Hosts and Routers", RFC 2893, August 2000.
[16] Hinden, R. and S. Deering, "IP Version 6
Architecture", RFC 2373, July 1998.
5. Security
This document describes the use of RADIUS for the purposes
authentication, authorization and accounting in IPv6-
networks. In such networks, the RADIUS protocol may run either
IPv4 or over IPv6. Known security vulnerabilities of the
protocol are described in [3], [4] and [8].
Since IPSEC [9] is mandatory to implement for IPv6, it is
that running RADIUS implementations supporting IPv6 will
run over IPSEC. Where RADIUS is run over IPSEC and
certificates are used for authentication, it may be desirable
avoid management of RADIUS shared secrets, so as to leverage
improved scalability of public key infrastructure
Within RADIUS, a shared secret is used for hiding of attributes
as User-Password [4] and Tunnel-Password [7]. In addition,
shared secret is used in computation of the Response
[4], as well as the Message-Authenticator attribute [8]. Therefore
in RADIUS a shared secret is used to provide confidentiality as
as integrity protection and authentication. As a result, only use
IPSEC ESP with a non-null transform can provide security
sufficient to substitute for RADIUS application-layer security
Therefore, where IPSEC AH or ESP null is used, it will
still be necessary to configure a RADIUS shared secret
However, where RADIUS is run over IPSEC ESP with a non-
transform, the secret shared between the NAS and the RADIUS
MAY NOT be configured. In this case, a shared secret of zero
MUST be assumed
Aboba, et al. Standards Track [Page 9]
RFC 3162 RADIUS and IPv6 August 2001
6. IANA
This document requires the assignment of six new RADIUS
numbers for the following attributes
NAS-IPv6-
Framed-Interface-
Framed-IPv6-
Login-IPv6-
Framed-IPv6-
Framed-IPv6-
See section 3 for the registered list of numbers
7.
The authors would like to acknowledge Jun-ichiro itojun Hagino of
Research Laboratory, Darran Potter of Cisco and Carl Rigney of
for contributions to this document
Aboba, et al. Standards Track [Page 10]
RFC 3162 RADIUS and IPv6 August 2001
8. Authors'
Bernard
Microsoft
One Microsoft
Redmond, WA 98052
Phone: +1 425 936 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.
Glen
Cisco Systems, Inc
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004
Phone: +1 425 471 4861
EMail: gwz@cisco.
Dave
Circular Logic UnLtd
733 Turnpike Street #154
North Andover, MA 01845
Phone: 978 683-1814
Email: david@mitton.
Aboba, et al. Standards Track [Page 11]
RFC 3162 RADIUS and IPv6 August 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Aboba, et al. Standards Track [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
