RADIUS attributes dictionary

MS-RAS-Client-Name is a vendor-specific attribute (VSA).
It is used to specify the name of the endpoint generating a request.
The fields of the MS-RAS-Client-Name VSA MUST be set as follows:

Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x22 for MS-RAS-Client-Name.

Vendor-Length: An 8-bit unsigned integer that MUST be set to 2 added to the length
of the Attribute-Specific Value field. Its value MUST be at least 3 and less than 36.

Attribute-Specific Value: This field MUST be the machine name of the endpoint that
requests network access, sent in ASCII format, and MUST be null terminated. A valid
character set includes the symbols ! @ # $ % ^ & ' ) ( . - _ { } ~ in addition
to letters and numbers.

When the RADIUS server receives this VSA, it MUST search the PolicyConfiguration.RASClientName
ADM element for the value of the VSA. If a match is not found, the server SHOULD send an
Access-Reject message to the NAS and stop processing.

If the clientName parameter of the SendRadiusAccessRequest abstract interface is set to NULL,
this attribute MUST NOT be set. Otherwise, the attribute-specific value is obtained by serializing
the clientName parameter to the format described above.

If the RADIUS User-Name attribute ( section 5.1) is found in the request, the RADIUS
server MUST ignore this attribute. Otherwise, the RADIUS server SHOULD convert the SID to a
Fully Qualified User Name using Active Directory Domain Services (AD DS). Once the Fully
Qualified User Name is available, the server MUST follow the same processing
rules specified for MS-RAS-Client-Name. If the server fails to obtain the Fully Qualified User Name
from AD DS, the server SHOULD send an Access-Reject message back to the NAS and stop processing.

Used to specify the security-identifier (SID). A security identifier (SID) uniquely identifies a security
principal. Each security principal has a unique SID that is issued by a security agent. The agent can be a
Windows local system or domain. The agent generates the SID when the security principal is created. The SID
can be represented as a character string or as a structure. When represented as strings, for example
in documentation or logs, SIDs are expressed as follows:

The fields of MS-User-Security-Identity MUST be set as follows:

Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x28 for MS-User-Security-Identity.

Vendor-Length: An 8-bit unsigned integer that MUST be set to 2 plus the length of the Attribute-Specific
Value field. Its value MUST be at least 3.

Attribute-Specific Value: This field MUST contain the account SID of the user requesting access in the
format of a binary SID used to authenticate a remote access client.

MS-Network-Access-Server-Type is a VSA used to specify the type of the network access server making the request.

The fields of MS-Network-Access-Server-Type MUST be set as follows:

Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x2F.

Vendor-Length: An 8-bit unsigned integer that MUST be set to 6.

Attribute-Specific Value: A 32-bit unsigned integer in network byte order that MUST
indicate the type of the NAS. The value MUST be interpreted in accordance with the following table:

0x00000000 Unspecified

0x00000001 Terminal Server Gateway

0x00000002 Remote Access Service (RAS) server (VPN or dial-in)

0x00000003 DHCP server

0x00000005 Health Registration Authority (HRA)

0x00000006 Host Credential Authorization Protocol (HCAP) server

All Other Values A tag value used to identify applicable network access policies on the RADIUS server.

MS-AFW-Protection-Level is a vendor-specific attribute (VSA).
It is used as a hint for dynamic selection of a preconfigured IPsec policy by the endpoint requesting access.

The fields of MS-AFW-Protection-Level MUST be set as follows:

Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x31.

Vendor-Length: An 8-bit unsigned integer that MUST be set to 6.

Attribute-Specific Value: A 32-bit unsigned integer in network byte order that MUST indicate
the protection level that the RADIUS server authorizes for the endpoint.
It MUST be set to one of the following values.

0x00000001 Indicates that the certificate payload specified in the response can be used for signing data.

0x00000002 Indicates that the certificate payload in the HCEP response can be used for signing and encrypting data.

When a NAS receives this attribute, it MUST assign the extended Quarantine state specified by this
attribute, to the client requesting access.
This attribute is used in NAP scenarios.

This attribute further qualifies the level of network access that the RADIUS server
authorizes to the endpoint. When a network access server receives this attribute from
a RADIUS server in an Access-Accept message, it MAY combine the value of this attribute
with the value of MS-Quarantine-State attribute in an implementation specific manner.

The MS-Extended-Quarantine-State VSA is used to specify additional information about
a restricted access decision by a RADIUS server.
The fields of MS-Extended-Quarantine-State MUST be set as follows:

Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x39.

Vendor-Length: An 8-bit unsigned integer that MUST be set to 6.

Attribute-Specific Value: A 32-bit unsigned integer in network-byte order that
MUST contain one of the following values.
0x00000000 No data
0x00000001 Transition
0x00000002 Infected
0x00000003 Unknown

HCAP-User-Name is a VSA used to indicate user identity information received over a
HCAP interface by a RADIUS client.

The fields of HCAP-User-Name MUST be set as follows:

Vendor-Type: An 8-bit unsigned integer that MUST be set to 0x3C.

Vendor-Length: An 8-bit unsigned integer that MUST be set to the length of the
Attribute-Specific Value field plus 2. Its value MUST be at least 3.

Attribute-Specific Value: An octet string that contains characters from Windows ANSI code page (for more
information, see ) and MUST specify the name for the HCAP user (as specified in ).

This Attribute indicates the name of the user to be authenticated.
It MUST be sent in Access-Request packets if available.

It MAY be sent in an Access-Accept packet, in which case the
client SHOULD use the name returned in the Access-Accept packet in
all Accounting-Request packets for this session. If the Access-
Accept includes Service-Type = Rlogin and the User-Name attribute,
a NAS MAY use the returned User-Name when performing the Rlogin
function.

A summary of the User-Name 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

1 for User-Name.

Length

>= 3

String

The String field is one or more octets. The NAS may limit the
maximum length of the User-Name but the ability to handle at least
63 octets is recommended.

The format of the username MAY be one of several forms:

text Consisting only of UTF-8 encoded 10646 characters.

network access identifier
A Network Access Identifier as described in.

distinguished name
A name in ASN.1 form used in Public Key authentication
systems.

This Attribute indicates the password of the user to be
authenticated, or the user's input following an Access-Challenge.
It is only used in Access-Request packets.

On transmission, the password is hidden. The password is first
padded at the end with nulls to a multiple of 16 octets. A one-
way MD5 hash is calculated over a stream of octets consisting of
the shared secret followed by the Request Authenticator. This
value is XORed with the first 16 octet segment of the password and
placed in the first 16 octets of the String field of the User-
Password Attribute.

If the password is longer than 16 characters, a second one-way MD5
hash is calculated over a stream of octets consisting of the
shared secret followed by the result of the first xor. That hash
is XORed with the second 16 octet segment of the password and
placed in the second 16 octets of the String field of the User-
Password Attribute.

If necessary, this operation is repeated, with each xor result
being used along with the shared secret to generate the next hash
to xor the next segment of the password, to no more than 128
characters.

The method is taken from the book "Network Security" by Kaufman,
Perlman and Speciner pages 109-110. A more precise
explanation of the method follows:

Call the shared secret S and the pseudo-random 128-bit Request
Authenticator RA. Break the password into 16-octet chunks p1, p2,
etc. with the last one padded at the end with nulls to a 16-octet
boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need
intermediate values b1, b2, etc.

b1 = MD5(S + RA) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi

The String will contain c(1)+c(2)+...+c(i) where + denotes
concatenation.On receipt, the process is reversed to yield the original
password.

A summary of the User-Password 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

2 for User-Password.

Length

At least 18 and no larger than 130.

String

The String field is between 16 and 128 octets long, inclusive.

This Attribute indicates the response value provided by a PPP
Challenge-Handshake Authentication Protocol (CHAP) user in
response to the challenge. It is only used in Access-Request
packets.

The CHAP challenge value is found in the CHAP-Challenge Attribute
(60) if present in the packet, otherwise in the Request
Authenticator field.

A summary of the CHAP-Password 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 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | CHAP Ident | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type

3 for CHAP-Password.

Length

19

CHAP Ident

This field is one octet, and contains the CHAP Identifier from the
user's CHAP Response.

String

The String field is 16 octets, and contains the CHAP Response from
the user.

This Attribute indicates the identifying IP Address of the NAS
which is requesting authentication of the user, and SHOULD be
unique to the NAS within the scope of the RADIUS server. NAS-IP-
Address is only used in Access-Request packets. Either NAS-IP-
Address or NAS-Identifier MUST be present in an Access-Request
packet.

Note that NAS-IP-Address MUST NOT be used to select the shared
secret used to authenticate the request. The source IP address of
the Access-Request packet MUST be used to select the shared
secret.

A summary of the NAS-IP-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

4 for NAS-IP-Address.Length

6

Address

The Address field is four octets.

This Attribute indicates the physical port number of the NAS which
is authenticating the user. It is only used in Access-Request
packets. Note that this is using "port" in its sense of a
physical connection on the NAS, not in the sense of a TCP or UDP
port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD
be present in an Access-Request packet, if the NAS differentiates
among its ports.

A summary of the NAS-Port 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

5 for NAS-Port.

Length

6

Value

The Value field is four octets.

This Attribute indicates the type of service the user has
requested, or the type of service to be provided. It MAY be used
in both Access-Request and Access-Accept packets. A NAS is not
required to implement all of these service types, and MUST treat
unknown or unsupported Service-Types as though an Access-Reject
had been received instead.

A summary of the Service-Type 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

6 for Service-Type.

Length

6

Value

The Value field is four octets.

1 Login
2 Framed
3 Callback Login
4 Callback Framed
5 Outbound
6 Administrative
7 NAS Prompt
8 Authenticate Only
9 Callback NAS Prompt
10 Call Check
11 Callback AdministrativeThe service types are defined as follows when used in an Access-
Accept. When used in an Access-Request, they MAY be considered to
be a hint to the RADIUS server that the NAS has reason to believe
the user would prefer the kind of service indicated, but the
server is not required to honor the hint.

Login The user should be connected to a host.

Framed A Framed Protocol should be started for the
User, such as PPP or SLIP.

Callback Login The user should be disconnected and called
back, then connected to a host.

Callback Framed The user should be disconnected and called
back, then a Framed Protocol should be started
for the User, such as PPP or SLIP.

Outbound The user should be granted access to outgoing
devices.

Administrative The user should be granted access to the
administrative interface to the NAS from which
privileged commands can be executed.

NAS Prompt The user should be provided a command prompt
on the NAS from which non-privileged commands
can be executed.

Authenticate Only Only Authentication is requested, and no
authorization information needs to be returned
in the Access-Accept (typically used by proxy
servers rather than the NAS itself).

Callback NAS Prompt The user should be disconnected and called
back, then provided a command prompt on the
NAS from which non-privileged commands can be
executed.

Call Check Used by the NAS in an Access-Request packet to
indicate that a call is being received and
that the RADIUS server should send back an
Access-Accept to answer the call, or an
Access-Reject to not accept the call,
typically based on the Called-Station-Id or
Calling-Station-Id attributes. It isrecommended that such Access-Requests use the
value of Calling-Station-Id as the value of
the User-Name.

Callback Administrative
The user should be disconnected and called
back, then granted access to the
administrative interface to the NAS from which
privileged commands can be executed.

This Attribute indicates the framing to be used for framed access.
It MAY be used in both Access-Request and Access-Accept packets.

A summary of the Framed-Protocol 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

7 for Framed-Protocol.

Length

6

Value

The Value field is four octets.

1 PPP
2 SLIP
3 AppleTalk Remote Access Protocol (ARAP)
4 Gandalf proprietary SingleLink/MultiLink protocol
5 Xylogics proprietary IPX/SLIP
6 X.75 Synchronous

This Attribute indicates the address to be configured for the
user. It MAY be used in Access-Accept packets. It MAY be used in
an Access-Request packet as a hint by the NAS to the server that
it would prefer that address, but the server is not required to
honor the hint.

A summary of the Framed-IP-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

8 for Framed-IP-Address.

Length

6

Address

The Address field is four octets. The value 0xFFFFFFFF indicates
that the NAS Should allow the user to select an address (e.g.
Negotiated). The value 0xFFFFFFFE indicates that the NAS should
select an address for the user (e.g. Assigned from a pool of
addresses kept by the NAS). Other valid values indicate that the
NAS should use that value as the user's IP address.

This Attribute indicates the IP netmask to be configured for the
user when the user is a router to a network. It MAY be used in
Access-Accept packets. It MAY be used in an Access-Request packet
as a hint by the NAS to the server that it would prefer that
netmask, but the server is not required to honor the hint.A summary of the Framed-IP-Netmask 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

9 for Framed-IP-Netmask.

Length

6

Address

The Address field is four octets specifying the IP netmask of the
user.

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
packets.

A summary of the Framed-Routing 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

10 for Framed-Routing.Length

6

Value

The Value field is four octets.

0 None
1 Send routing packets
2 Listen for routing packets
3 Send and Listen

This Attribute indicates the name of the filter list for this
user. Zero or more Filter-Id attributes MAY be sent in an
Access-Accept packet.

Identifying a filter list by name allows the filter to be used on
different NASes without regard to filter-list implementation
details.

A summary of the Filter-Id 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

11 for Filter-Id.

Length

>= 3

Text

The Text field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable and
MUST NOT affect operation of the protocol. It is recommended that
the message contain UTF-8 encoded 10646 characters.

This Attribute indicates the Maximum Transmission Unit to be
configured for the user, when it is not negotiated by some other
means (such as PPP). It MAY be used in Access-Accept packets. It
MAY be used in an Access-Request packet as a hint by the NAS to
the server that it would prefer that value, but the server is not
required to honor the hint.

A summary of the Framed-MTU 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

12 for Framed-MTU.

Length

6

Value

The Value field is four octets. Despite the size of the field,
values range from 64 to 65535.

This Attribute indicates a compression protocol to be used for the
link. It MAY be used in Access-Accept packets. It MAY be used in
an Access-Request packet as a hint to the server that the NAS
would prefer to use that compression, but the server is not
required to honor the hint.

More than one compression protocol Attribute MAY be sent. It is
the responsibility of the NAS to apply the proper compression
protocol to appropriate link traffic.A summary of the Framed-Compression 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

13 for Framed-Compression.

Length

6

Value

The Value field is four octets.

0 None
1 VJ TCP/IP header compression
2 IPX header compression
3 Stac-LZS compression

This Attribute indicates the system with which to connect the user,
when the Login-Service Attribute is included. It MAY be used in
Access-Accept packets. It MAY be used in an Access-Request packet as
a hint to the server that the NAS would prefer to use that host, but
the server is not required to honor the hint.

A summary of the Login-IP-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

14 for Login-IP-Host.

Length

6

Address

The Address field is four octets. The value 0xFFFFFFFF indicates
that the NAS SHOULD allow the user to select an address. The
value 0 indicates that the NAS SHOULD select a host to connect the
user to. Other values indicate the address the NAS SHOULD connect
the user to.

This Attribute indicates the service to use to connect the user to
the login host. It is only used in Access-Accept packets.

A summary of the Login-Service 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

15 for Login-Service.Length

6

Value

The Value field is four octets.

0 Telnet
1 Rlogin
2 TCP Clear
3 PortMaster (proprietary)
4 LAT
5 X25-PAD
6 X25-T3POS
8 TCP Clear Quiet (suppresses any NAS-generated connect string)

This Attribute indicates the TCP port with which the user is to be
connected, when the Login-Service Attribute is also present. It
is only used in Access-Accept packets.

A summary of the Login-TCP-Port 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

16 for Login-TCP-Port.

Length

6

Value

The Value field is four octets. Despite the size of the field,
values range from 0 to 65535.

This Attribute indicates text which MAY be displayed to the user.

When used in an Access-Accept, it is the success message.

When used in an Access-Reject, it is the failure message. It MAY
indicate a dialog message to prompt the user before another
Access-Request attempt.

When used in an Access-Challenge, it MAY indicate a dialog message
to prompt the user for a response.

Multiple Reply-Message's MAY be included and if any are displayed,
they MUST be displayed in the same order as they appear in the
packet.

A summary of the Reply-Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

18 for Reply-Message.

Length

>= 3

Text

The Text field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
that the message contain UTF-8 encoded 10646 characters.

This Attribute indicates a dialing string to be used for callback.
It MAY be used in Access-Accept packets. It MAY be used in an
Access-Request packet as a hint to the server that a Callback
service is desired, but the server is not required to honor the
hint.

A summary of the Callback-Number 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

19 for Callback-Number.

Length

>= 3

String

The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.

This Attribute indicates the name of a place to be called, to be
interpreted by the NAS. It MAY be used in Access-Accept packets.A summary of the Callback-Id 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

20 for Callback-Id.

Length

>= 3

String

The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.

This Attribute provides routing information to be configured for
the user on the NAS. It is used in the Access-Accept packet and
can appear multiple times.

A summary of the Framed-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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type

22 for Framed-Route.

Length

>= 3

Text

The Text field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable and
MUST NOT affect operation of the protocol. It is recommended that
the message contain UTF-8 encoded 10646 characters.

For IP routes, it SHOULD contain a destination prefix in dotted
quad form optionally followed by a slash and a decimal length
specifier stating how many high order bits of the prefix to use.
That is followed by a space, a gateway address in dotted quad
form, a space, and one or more metrics separated by spaces. For
example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
specifier may be omitted, in which case it defaults to 8 bits for
class A prefixes, 16 bits for class B prefixes, and 24 bits for
class C prefixes. For example, "192.168.1.0 192.168.1.1 1".

Whenever the gateway address is specified as "0.0.0.0" the IP
address of the user SHOULD be used as the gateway address.

This Attribute indicates the IPX Network number to be configured
for the user. It is used in Access-Accept packets.

A summary of the Framed-IPX-Network 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type

23 for Framed-IPX-Network.

Length

6

Value

The Value field is four octets. The value 0xFFFFFFFE indicates
that the NAS should select an IPX network for the user (e.g.
assigned from a pool of one or more IPX networks kept by the NAS).
Other values should be used as the IPX network for the link to the
user.

This Attribute is available to be sent by the server to the client
in an Access-Challenge and MUST be sent unmodified from the client
to the server in the new Access-Request reply to that challenge,
if any.

This Attribute is available to be sent by the server to the client
in an Access-Accept that also includes a Termination-Action
Attribute with the value of RADIUS-Request. If the NAS performs
the Termination-Action by sending a new Access-Request upon
termination of the current session, it MUST include the State
attribute unchanged in that Access-Request.

In either usage, the client MUST NOT interpret the attribute
locally. A packet must have only zero or one State Attribute.
Usage of the State Attribute is implementation dependent.

A summary of the State 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

24 for State.Length

>= 3

String

The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.

This Attribute is available to be sent by the server to the client
in an Access-Accept and SHOULD be sent unmodified by the client to
the accounting server as part of the Accounting-Request packet if
accounting is supported. The client MUST NOT interpret the
attribute locally.

A summary of the Class 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

25 for Class.

Length

>= 3

String

The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.

This Attribute is available to allow vendors to support their own
extended Attributes not suitable for general usage. It MUST not
affect the operation of the RADIUS protocol.

Servers not equipped to interpret the vendor-specific information
sent by a client MUST ignore it (although it may be reported).
Clients which do not receive desired vendor-specific information
SHOULD make an attempt to operate without it, although they may do
so (and report they are doing so) in a degraded mode.

A summary of the Vendor-Specific 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 | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

26 for Vendor-Specific.

Length

>= 7

Vendor-Id

The high-order octet is 0 and the low-order 3 octets are the SMI
Network Management Private Enterprise Code of the Vendor in
network byte order, as defined in the "Assigned Numbers" RFC .

String

The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.It SHOULD be encoded as a sequence of vendor type / vendor length
/ value fields, as follows. The Attribute-Specific field is
dependent on the vendor's definition of that attribute. An
example encoding of the Vendor-Specific attribute using this
method follows:

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 | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Specific...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Multiple subattributes MAY be encoded within a single Vendor-
Specific attribute, although they do not have to be.

This Attribute sets the maximum number of seconds of service to be
provided to the user before termination of the session or prompt.
This Attribute is available to be sent by the server to the client
in an Access-Accept or Access-Challenge.

A summary of the Session-Timeout 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

27 for Session-Timeout.

Length

6Value

The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of seconds this user should be allowed to
remain connected by the NAS.

This Attribute sets the maximum number of consecutive seconds of
idle connection allowed to the user before termination of the
session or prompt. This Attribute is available to be sent by the
server to the client in an Access-Accept or Access-Challenge.

A summary of the Idle-Timeout 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

28 for Idle-Timeout.

Length

6

Value

The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of consecutive seconds of idle time this user
should be permitted before being disconnected by the NAS.

This Attribute indicates what action the NAS should take when the
specified service is completed. It is only used in Access-Accept
packets.A summary of the Termination-Action 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

29 for Termination-Action.

Length

6

Value

The Value field is four octets.

0 Default
1 RADIUS-Request

If the Value is set to RADIUS-Request, upon termination of the
specified service the NAS MAY send a new Access-Request to the
RADIUS server, including the State attribute if any.

This Attribute allows the NAS to send in the Access-Request packet
the phone number that the user called, using Dialed Number
Identification (DNIS) or similar technology. Note that this may
be different from the phone number the call comes in on. It is
only used in Access-Request packets.

A summary of the Called-Station-Id 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type

30 for Called-Station-Id.

Length

>= 3

String

The String field is one or more octets, containing the phone
number that the user's call came in on.

The actual format of the information is site or application
specific. UTF-8 encoded 10646 characters are recommended, but
a robust implementation SHOULD support the field as
undistinguished octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.

The Calling-Station-Id attribute (Type value 31) is of type String.
When used within PMIPv6 deployments, the attribute contains the MN
Link-Layer Identifier option of the MN as defined in ,
Sectionsand.

This Attribute contains a string identifying the NAS originating
the Access-Request. It is only used in Access-Request packets.
Either NAS-IP-Address or NAS-Identifier MUST be present in an
Access-Request packet.

Note that NAS-Identifier MUST NOT be used to select the shared
secret used to authenticate the request. The source IP address of
the Access-Request packet MUST be used to select the shared
secret.

A summary of the NAS-Identifier 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

32 for NAS-Identifier.

Length

>= 3String

The String field is one or more octets, and should be unique to
the NAS within the scope of the RADIUS server. For example, a
fully qualified domain name would be suitable as a NAS-Identifier.

The actual format of the information is site or application
specific, and a robust implementation SHOULD support the field as
undistinguished octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.

This Attribute is available to be sent by a proxy server to
another server when forwarding an Access-Request and MUST be
returned unmodified in the Access-Accept, Access-Reject or
Access-Challenge. When the proxy server receives the response to
its request, it MUST remove its own Proxy-State (the last Proxy-
State in the packet) before forwarding the response to the NAS.

If a Proxy-State Attribute is added to a packet when forwarding
the packet, the Proxy-State Attribute MUST be added after any
existing Proxy-State attributes.

The content of any Proxy-State other than the one added by the
current server should be treated as opaque octets and MUST NOT
affect operation of the protocol.

Usage of the Proxy-State Attribute is implementation dependent. A
description of its function is outside the scope of this
specification.

A summary of the Proxy-State 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

33 for Proxy-State.Length

>= 3

String

The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.

This Attribute indicates the system with which the user is to be
connected by LAT. It MAY be used in Access-Accept packets, but
only when LAT is specified as the Login-Service. It MAY be used
in an Access-Request packet as a hint to the server, but the
server is not required to honor the hint.

Administrators use the service attribute when dealing with
clustered systems, such as a VAX or Alpha cluster. In such an
environment several different time sharing hosts share the same
resources (disks, printers, etc.), and administrators often
configure each to offer access (service) to each of the shared
resources. In this case, each host in the cluster advertises its
services through LAT broadcasts.

Sophisticated users often know which service providers (machines)
are faster and tend to use a node name when initiating a LAT
connection. Alternately, some administrators want particular
users to use certain machines as a primitive form of load
balancing (although LAT knows how to do load balancing itself).

A summary of the Login-LAT-Service 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type

34 for Login-LAT-Service.

Length

>= 3

String

The String field is one or more octets, and contains the identity
of the LAT service to use. The LAT Architecture allows this
string to contain $ (dollar), - (hyphen), . (period), _
(underscore), numerics, upper and lower case alphabetics, and the
ISO Latin-1 character set extension . All LAT string
comparisons are case insensitive.

This Attribute indicates the Node with which the user is to be
automatically connected by LAT. It MAY be used in Access-Accept
packets, but only when LAT is specified as the Login-Service. It
MAY be used in an Access-Request packet as a hint to the server,
but the server is not required to honor the hint.

A summary of the Login-LAT-Node 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

35 for Login-LAT-Node.

Length

>= 3String

The String field is one or more octets, and contains the identity
of the LAT Node to connect the user to. The LAT Architecture
allows this string to contain $ (dollar), - (hyphen), . (period),
_ (underscore), numerics, upper and lower case alphabetics, and
the ISO Latin-1 character set extension. All LAT string
comparisons are case insensitive.

This Attribute contains a string identifying the LAT group codes
which this user is authorized to use. It MAY be used in Access-
Accept packets, but only when LAT is specified as the Login-
Service. It MAY be used in an Access-Request packet as a hint to
the server, but the server is not required to honor the hint.

LAT supports 256 different group codes, which LAT uses as a form
of access rights. LAT encodes the group codes as a 256 bit
bitmap.

Administrators can assign one or more of the group code bits at
the LAT service provider; it will only accept LAT connections that
have these group codes set in the bit map. The administrators
assign a bitmap of authorized group codes to each user; LAT gets
these from the operating system, and uses these in its requests to
the service providers.

A summary of the Login-LAT-Group 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

36 for Login-LAT-Group.

Length

34String

The String field is a 32 octet bit map, most significant octet
first. A robust implementation SHOULD support the field as
undistinguished octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.

This Attribute indicates the AppleTalk network number which should
be used for the serial link to the user, which is another
AppleTalk router. It is only used in Access-Accept packets. It
is never used when the user is not another router.

A summary of the Framed-AppleTalk-Link 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

37 for Framed-AppleTalk-Link.

Length

6

Value

The Value field is four octets. Despite the size of the field,
values range from 0 to 65535. The special value of 0 indicates
that this is an unnumbered serial link. A value of 1-65535 means
that the serial line between the NAS and the user should be
assigned that value as an AppleTalk network number.

This Attribute indicates the AppleTalk Network number which the
NAS should probe to allocate an AppleTalk node for the user. It
is only used in Access-Accept packets. It is never used when the
user is another router. Multiple instances of this Attribute
indicate that the NAS may probe using any of the network numbers
specified.

A summary of the Framed-AppleTalk-Network 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

38 for Framed-AppleTalk-Network.

Length

6

Value

The Value field is four octets. Despite the size of the field,
values range from 0 to 65535. The special value 0 indicates that
the NAS should assign a network for the user, using its default
cable range. A value between 1 and 65535 (inclusive) indicates
the AppleTalk Network the NAS should probe to find an address for
the user.

This Attribute indicates the AppleTalk Default Zone to be used for
this user. It is only used in Access-Accept packets. Multiple
instances of this attribute in the same packet are not allowed.A summary of the Framed-AppleTalk-Zone 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 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

39 for Framed-AppleTalk-Zone.

Length

>= 3

String

The name of the Default AppleTalk Zone to be used for this user.
A robust implementation SHOULD support the field as
undistinguished octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.

This Attribute contains the CHAP Challenge sent by the NAS to a
PPP Challenge-Handshake Authentication Protocol (CHAP) user. It
is only used in Access-Request packets.

If the CHAP challenge value is 16 octets long it MAY be placed in
the Request Authenticator field instead of using this attribute.

A summary of the CHAP-Challenge 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-Type

60 for CHAP-Challenge.

Length

>= 7

String

The String field contains the CHAP Challenge.

This Attribute indicates the type of the physical port of the NAS
which is authenticating the user. It can be used instead of or in
addition to the NAS-Port (5) attribute. It is only used in
Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or
both SHOULD be present in an Access-Request packet, if the NAS
differentiates among its ports.

A summary of the NAS-Port-Type 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

61 for NAS-Port-Type.

Length

6

Value

The Value field is four octets. "Virtual" refers to a connection
to the NAS via some transport protocol, instead of through a
physical port. For example, if a user telnetted into a NAS toauthenticate himself as an Outbound-User, the Access-Request might
include NAS-Port-Type = Virtual as a hint to the RADIUS server
that the user was not on a physical port.

0 Async
1 Sync
2 ISDN Sync
3 ISDN Async V.120
4 ISDN Async V.110
5 Virtual
6 PIAFS
7 HDLC Clear Channel
8 X.25
9 X.75
10 G.3 Fax
11 SDSL - Symmetric DSL
12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
Modulation
13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
14 IDSL - ISDN Digital Subscriber Line
15 Ethernet
16 xDSL - Digital Subscriber Line of unknown type
17 Cable
18 Wireless - Other
19 Wireless - IEEE 802.11

PIAFS is a form of wireless ISDN commonly used in Japan, and
stands for PHS (Personal Handyphone System) Internet Access Forum
Standard (PIAFS).

This Attribute sets the maximum number of ports to be provided to
the user by the NAS. This Attribute MAY be sent by the server to
the client in an Access-Accept packet. It is intended for use in
conjunction with Multilink PPP or similar uses. It MAY also
be sent by the NAS to the server as a hint that that many ports
are desired for use, but the server is not required to honor the
hint.

A summary of the Port-Limit 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

62 for Port-Limit.

Length

6

Value

The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of ports this user should be allowed to connect
to on the NAS.

This Attribute indicates the Port with which the user is to be
connected by LAT. It MAY be used in Access-Accept packets, but
only when LAT is specified as the Login-Service. It MAY be used
in an Access-Request packet as a hint to the server, but the
server is not required to honor the hint.

A summary of the Login-LAT-Port 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

63 for Login-LAT-Port.

Length

>= 3String

The String field is one or more octets, and contains the identity
of the LAT port to use. The LAT Architecture allows this string
to contain $ (dollar), - (hyphen), . (period), _ (underscore),
numerics, upper and lower case alphabetics, and the ISO Latin-1
character set extension. All LAT string comparisons are case
insensitive.

This attribute indicates whether this Accounting-Request marks the
beginning of the user service (Start) or the end (Stop).

It MAY be used by the client to mark the start of accounting (for
example, upon booting) by specifying Accounting-On and to mark the
end of accounting (for example, just before a scheduled reboot) by
specifying Accounting-Off.

A summary of the Acct-Status-Type 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type

40 for Acct-Status-Type.

Length

6

Value

The Value field is four octets.

1 Start
2 Stop
3 Interim-Update
7 Accounting-On
8 Accounting-Off
9-14 Reserved for Tunnel Accounting
15 Reserved for Failed

This attribute indicates how many seconds the client has been
trying to send this record for, and can be subtracted from the
time of arrival on the server to find the approximate time of the
event generating this Accounting-Request. (Network transit time
is ignored.)

Note that changing the Acct-Delay-Time causes the Identifier to
change; see the discussion under Identifier above.

A summary of the Acct-Delay-Time 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type

41 for Acct-Delay-Time.

Length

6

Value

The Value field is four octets.

This attribute indicates how many octets have been received from
the port over the course of this service being provided, and can
only be present in Accounting-Request records where the Acct-
Status-Type is set to Stop.

A summary of the Acct-Input-Octets 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

42 for Acct-Input-Octets.

Length

6

Value

The Value field is four octets.

This attribute indicates how many octets have been sent to the
port in the course of delivering this service, and can only be
present in Accounting-Request records where the Acct-Status-Type
is set to Stop.

A summary of the Acct-Output-Octets 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

43 for Acct-Output-Octets.

Length

6

Value

The Value field is four octets.

This attribute is a unique Accounting ID to make it easy to match
start and stop records in a log file. The start and stop records
for a given session MUST have the same Acct-Session-Id. An
Accounting-Request packet MUST have an Acct-Session-Id. An
Access-Request packet MAY have an Acct-Session-Id; if it does,
then the NAS MUST use the same Acct-Session-Id in the Accounting-
Request packets for that session.

The Acct-Session-Id SHOULD contain UTF-8 encoded 10646
characters.For example, one implementation uses a string with an 8-digit
upper case hexadecimal number, the first two digits increment on
each reboot (wrapping every 256 reboots) and the next 6 digits
counting from 0 for the first person logging in after a reboot up
to 2^24-1, about 16 million. Other encodings are possible.

A summary of the Acct-Session-Id 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

44 for Acct-Session-Id.

Length

>= 3

String

The String field SHOULD be a string of UTF-8 encoded 10646
characters.

This attribute MAY be included in an Accounting-Request to
indicate how the user was authenticated, whether by RADIUS, the
NAS itself, or another remote authentication protocol. Users who
are delivered service without being authenticated SHOULD NOT
generate Accounting records.

A summary of the Acct-Authentic 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type

45 for Acct-Authentic.

Length

6

Value

The Value field is four octets.

1 RADIUS
2 Local
3 Remote

This attribute indicates how many seconds the user has received
service for, and can only be present in Accounting-Request records
where the Acct-Status-Type is set to Stop.

A summary of the Acct-Session-Time 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

46 for Acct-Session-Time.

Length

6

Value

The Value field is four octets.

This attribute indicates how many packets have been received from
the port over the course of this service being provided to a
Framed User, and can only be present in Accounting-Request records
where the Acct-Status-Type is set to Stop.

A summary of the Acct-Input-packets 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

47 for Acct-Input-Packets.

Length

6

Value

The Value field is four octets.

This attribute indicates how many packets have been sent to the
port in the course of delivering this service to a Framed User,
and can only be present in Accounting-Request records where the
Acct-Status-Type is set to Stop.

A summary of the Acct-Output-Packets 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

48 for Acct-Output-Packets.

Length

6

Value

The Value field is four octets.

This attribute indicates how the session was terminated, and can
only be present in Accounting-Request records where the Acct-
Status-Type is set to Stop.

A summary of the Acct-Terminate-Cause 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type

49 for Acct-Terminate-Cause

Length

6

Value

The Value field is four octets, containing an integer specifying
the cause of session termination, as follows:

1 User Request
2 Lost Carrier
3 Lost Service
4 Idle Timeout
5 Session Timeout
6 Admin Reset
7 Admin Reboot
8 Port Error
9 NAS Error
10 NAS Request
11 NAS Reboot
12 Port Unneeded
13 Port Preempted
14 Port Suspended
15 Service Unavailable
16 Callback
17 User Error
18 Host Request

The termination causes are as follows:

User Request User requested termination of service, for
example with LCP Terminate or by logging out.

Lost Carrier DCD was dropped on the port.

Lost Service Service can no longer be provided; for
example, user's connection to a host was
interrupted.

Idle Timeout Idle timer expired.

Session Timeout Maximum session length timer expired.

Admin Reset Administrator reset the port or session.Admin Reboot Administrator is ending service on the NAS,
for example prior to rebooting the NAS.

Port Error NAS detected an error on the port which
required ending the session.

NAS Error NAS detected some error (other than on the
port) which required ending the session.

NAS Request NAS ended session for a non-error reason not
otherwise listed here.

NAS Reboot The NAS ended the session in order to reboot
non-administratively ("crash").

Port Unneeded NAS ended session because resource usage fell
below low-water mark (for example, if a
bandwidth-on-demand algorithm decided that
the port was no longer needed).

Port Preempted NAS ended session in order to allocate the
port to a higher priority use.

Port Suspended NAS ended session to suspend a virtual
session.

Service Unavailable NAS was unable to provide requested service.

Callback NAS is terminating current session in order
to perform callback for a new session.

User Error Input from user is in error, causing
termination of session.

Host Request Login Host terminated session normally.

This attribute is a unique Accounting ID to make it easy to link
together multiple related sessions in a log file. Each session
linked together would have a unique Acct-Session-Id but the same
Acct-Multi-Session-Id. It is strongly recommended that the Acct-
Multi-Session-Id contain UTF-8 encoded 10646 characters.

A summary of the Acct-Session-Id 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

50 for Acct-Multi-Session-Id.

Length

>= 3

String

The String field SHOULD contain UTF-8 encoded 10646 characters.

This attribute gives the count of links which are known to have been
in a given multilink session at the time the accounting record is
generated. The NAS MAY include the Acct-Link-Count attribute in any
Accounting-Request which might have multiple links.

A summary of the Acct-Link-Count attribute format is show 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type

51 for Acct-Link-Count.

Length

6

Value

The Value field is four octets, and contains the number of links
seen so far in this Multilink Session.

It may be used to make it easier for an accounting server to know
when it has all the records for a given Multilink session. When
the number of Accounting-Requests received with Acct-Status-Type =
Stop and the same Acct-Multi-Session-Id and unique Acct-Session-
Id's equals the largest value of Acct-Link-Count seen in those
Accounting-Requests, all Stop Accounting-Requests for that
Multilink Session have been received.

An example showing 8 Accounting-Requests should make things
clearer. For clarity only the relevant attributes are shown, but
additional attributes containing accounting information will also
be present in the Accounting-Request.

Multi-Session-Id Session-Id Status-Type Link-Count
"10" "10" Start 1
"10" "11" Start 2
"10" "11" Stop 2
"10" "12" Start 3
"10" "13" Start 4
"10" "12" Stop 4
"10" "13" Stop 4
"10" "10" Stop 4

This Attribute indicates the identifier assigned to the tunnel
session. It SHOULD be included in Accounting-Request packets
which contain an Acct-Status-Type attribute having the value
Start, Stop or any of the values described above. This
attribute, along with the Tunnel-Client-Endpoint and Tunnel-
Server-Endpoint attributes , may be used to provide a means
to uniquely identify a tunnel session for auditing purposes.

A summary of the Acct-Tunnel-Connection 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

68 for Acct-Tunnel-Connection

Length

>= 3

String

The format of the identifier represented by the String field
depends upon the value of the Tunnel-Type attribute . For
example, to fully identify an L2TP tunnel connection, the L2TP
Tunnel ID and Call ID might be encoded in this field. The
exact encoding of this field is implementation dependent.

This Attribute indicates the number of packets lost on a given
link. It SHOULD be included in Accounting-Request packets
which contain an Acct-Status-Type attribute having the value
Tunnel-Link-Stop.A summary of the Acct-Tunnel-Packets-Lost 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 | Lost
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lost (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

86 for Acct-Tunnel-Packets-Lost

Length

6

Lost

The Lost field is 4 octets in length and represents the number
of packets lost on the link.5. Table of AttributesThe following table provides a guide to which attributes may be found
in Accounting-Request packets. No tunnel attributes should be found
in Accounting-Response packets.

Request # Attribute
0-1 64 Tunnel-Type
0-1 65 Tunnel-Medium-Type
0-1 66 Tunnel-Client-Endpoint
0-1 67 Tunnel-Server-Endpoint
0-1 68 Acct-Tunnel-Connection
0 69 Tunnel-Password
0-1 81 Tunnel-Private-Group-ID
0-1 82 Tunnel-Assignment-ID
0 83 Tunnel-Preference
0-1 86 Acct-Tunnel-Packets-LostThe following table defines the meaning of the above table entries.

0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in
packet.
0-1 Zero or one instance of this attribute MAY be present in
packet.6. Security ConsiderationsBy "sniffing" RADIUS Accounting packets, it might be possible for an
eavesdropper to perform a passive analysis of tunnel connections.7. References Rigney, C., "RADIUS Accounting",, June 2000.

Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels",,, March 1997.

Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",, June 2000.

Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
B. Palter, "Layer Two Tunneling Protocol "L2TP"",,
August 1999.

Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",,
July 1999.8. AcknowledgmentsThanks to Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall
for salient input and review.9. Authors' AddressesQuestions about this memo can be directed to:

Glen Zorn
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, Washington 98004
USA

Phone: +1 425 438 8218
FAX: +1 425 438 1848
EMail: [email protected]


Dave Mitton
Nortel Networks
880 Technology Park Drive
Billerica, MA 01821

Phone: +1 978 288 4570
Fax: +1 978 288 3030
EMail: [email protected]


Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052

Phone: +1 425 936 6605
Fax: +1 425 936 7329
EMail: [email protected]. Full Copyright StatementCopyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.



















Zorn, et al. Informational

This Attribute indicates the tunneling protocol(s) to be used (in
the case of a tunnel initiator) or the the tunneling protocol in
use (in the case of a tunnel terminator). It MAY be included in
Access-Request, Access-Accept and Accounting-Request packets. If
the Tunnel-Type Attribute is present in an Access-Request packet
sent from a tunnel initiator, it SHOULD be taken as a hint to the
RADIUS server as to the tunnelling protocols supported by the
tunnel end-point; the RADIUS server MAY ignore the hint, however.
A tunnel initiator is not required to implement any of these
tunnel types; if a tunnel initiator receives an Access-Accept
packet which contains only unknown or unsupported Tunnel-Types,
the tunnel initiator MUST behave as though an Access-Reject had
been received instead.

If the Tunnel-Type Attribute is present in an Access-Request
packet sent from a tunnel terminator, it SHOULD be taken to
signify the tunnelling protocol in use. In this case, if the
RADIUS server determines that the use of the communicated protocol
is not authorized, it MAY return an Access-Reject packet. If a
tunnel terminator receives an Access-Accept packet which containsone or more Tunnel-Type Attributes, none of which represent the
tunneling protocol in use, the tunnel terminator SHOULD behave as
though an Access-Reject had been received instead.

A summary of the Tunnel-Type 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 | Tag | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
64 for Tunnel-Type

Length
Always 6.

Tag
The Tag field is one octet in length and is intended to provide a
means of grouping attributes in the same packet which refer to the
same tunnel. Valid values for this field are 0x01 through 0x1F,
inclusive. If the Tag field is unused, it MUST be zero (0x00).

Value
The Value field is three octets and contains one of the following
values, indicating the type of tunnel to be started.

1 Point-to-Point Tunneling Protocol (PPTP)
2 Layer Two Forwarding (L2F)
3 Layer Two Tunneling Protocol (L2TP)
4 Ascend Tunnel Management Protocol (ATMP)
5 Virtual Tunneling Protocol (VTP)
6 IP Authentication Header in the Tunnel-mode (AH)
7 IP-in-IP Encapsulation (IP-IP)
8 Minimal IP-in-IP Encapsulation (MIN-IP-IP)
9 IP Encapsulating Security Payload in the Tunnel-mode (ESP)
10 Generic Route Encapsulation (GRE)
11 Bay Dial Virtual Services (DVS)
12 IP-in-IP Tunneling

The Tunnel-Medium-Type Attribute indicates which transport medium
to use when creating a tunnel for those protocols (such as L2TP)
that can operate over multiple transports. It MAY be included in
both Access-Request and Access-Accept packets; if it is present in
an Access-Request packet, it SHOULD be taken as a hint to the
RADIUS server as to the tunnel media supported by the tunnel end-
point. The RADIUS server MAY ignore the hint, however.

A summary of the Tunnel-Medium-Type 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 | Tag | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
65 for Tunnel-Medium-Type

Length
6

Tag
The Tag field is one octet in length and is intended to provide a
means of grouping attributes in the same packet which refer to the
same tunnel. Valid values for this field are 0x01 through 0x1F,
inclusive. If the Tag field is unused, it MUST be zero (0x00).

Value
The Value field is three octets and contains one of the values
listed under "Address Family Numbers" in . For the sake of
convenience, a relevant excerpt of this list is reproduced below.

1 IPv4 (IP version 4)
2 IPv6 (IP version 6)
3 NSAP
4 HDLC (8-bit multidrop)
5 BBN 1822
6 802 (includes all 802 media plus Ethernet "canonical format")
7 E.163 (POTS)
8 E.164 (SMDS, Frame Relay, ATM)9 F.69 (Telex)
10 X.121 (X.25, Frame Relay)
11 IPX
12 Appletalk
13 Decnet IV
14 Banyan Vines
15 E.164 with NSAP format subaddress

This Attribute contains the address of the initiator end of the
tunnel. It MAY be included in both Access-Request and Access-
Accept packets to indicate the address from which a new tunnel is
to be initiated. If the Tunnel-Client-Endpoint Attribute is
included in an Access-Request packet, the RADIUS server should
take the value as a hint; the server is not obligated to honor the
hint, however. This Attribute SHOULD be included in Accounting-
Request packets which contain Acct-Status-Type attributes with
values of either Start or Stop, in which case it indicates the
address from which the tunnel was initiated. This Attribute,
along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection-
ID attributes, may be used to provide a globally unique means to
identify a tunnel for accounting and auditing purposes.

A summary of the Tunnel-Client-Endpoint 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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
66 for Tunnel-Client-Endpoint.

Length
>= 3Tag
The Tag field is one octet in length and is intended to provide a
means of grouping attributes in the same packet which refer to the
same tunnel. If the value of the Tag field is greater than 0x00
and less than or equal to 0x1F, it SHOULD be interpreted as
indicating which tunnel (of several alternatives) this attribute
pertains. If the Tag field is greater than 0x1F, it SHOULD be
interpreted as the first byte of the following String field.

String
The format of the address represented by the String field depends
upon the value of the Tunnel-Medium-Type attribute.

If Tunnel-Medium-Type is IPv4 (1), then this string is either the
fully qualified domain name (FQDN) of the tunnel client machine,
or it is a "dotted-decimal" IP address. Conformant
implementations MUST support the dotted-decimal format and SHOULD
support the FQDN format for IP addresses.

If Tunnel-Medium-Type is IPv6 (2), then this string is either the
FQDN of the tunnel client machine, or it is a text representation
of the address in either the preferred or alternate form .
Conformant implementations MUST support the preferred form and
SHOULD support both the alternate text form and the FQDN format
for IPv6 addresses.

If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a
tag referring to configuration data local to the RADIUS client
that describes the interface and medium-specific address to use.

This Attribute indicates the address of the server end of the
tunnel. The Tunnel-Server-Endpoint Attribute MAY be included (as
a hint to the RADIUS server) in the Access-Request packet and MUST
be included in the Access-Accept packet if the initiation of a
tunnel is desired. It SHOULD be included in Accounting-Request
packets which contain Acct-Status-Type attributes with values of
either Start or Stop and which pertain to a tunneled session.
This Attribute, along with the Tunnel-Client-Endpoint and Acct-
Tunnel-Connection-ID Attributes , may be used to provide a
globally unique means to identify a tunnel for accounting and
auditing purposes.A summary of the Tunnel-Server-Endpoint 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 | Tag | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
67 for Tunnel-Server-Endpoint.

Length
>= 3

Tag
The Tag field is one octet in length and is intended to provide a
means of grouping attributes in the same packet which refer to the
same tunnel. If the value of the Tag field is greater than 0x00
and less than or equal to 0x1F, it SHOULD be interpreted as
indicating which tunnel (of several alternatives) this attribute
pertains. If the Tag field is greater than 0x1F, it SHOULD be
interpreted as the first byte of the following String field.

String
The format of the address represented by the String field depends
upon the value of the Tunnel-Medium-Type attribute.

If Tunnel-Medium-Type is IPv4 (1), then this string is either the
fully qualified domain name (FQDN) of the tunnel client machine,
or it is a "dotted-decimal" IP address. Conformant
implementations MUST support the dotted-decimal format and SHOULD
support the FQDN format for IP addresses.

If Tunnel-Medium-Type is IPv6 (2), then this string is either the
FQDN of the tunnel client machine, or it is a text representation
of the address in either the preferred or alternate form .
Conformant implementations MUST support the preferred form and
SHOULD support both the alternate text form and the FQDN format
for IPv6 addresses.

If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag
referring to configuration data local to the RADIUS client that
describes the interface and medium-specific address to use.

This Attribute may contain a password to be used to authenticate
to a remote server. It may only be included in an Access-Accept
packet.

A summary of the Tunnel-Password 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 | Tag | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
69 for Tunnel-Password

Length
>= 5

Tag
The Tag field is one octet in length and is intended to provide a
means of grouping attributes in the same packet which refer to the
same tunnel. Valid values for this field are 0x01 through 0x1F,
inclusive. If the value of the Tag field is greater than 0x00 and
less than or equal to 0x1F, it SHOULD be interpreted as indicating
which tunnel (of several alternatives) this attribute pertains;
otherwise, the Tag field SHOULD be ignored.

Salt
The Salt field is two octets in length and is used to ensure the
uniqueness of the encryption key used to encrypt each instance of
the Tunnel-Password attribute occurring in a given Access-Accept
packet. The most significant bit (leftmost) of the Salt field
MUST be set (1). The contents of each Salt field in a given
Access-Accept packet MUST be unique.

String
The plaintext String field consists of three logical sub-fields:
the Data-Length and Password sub-fields (both of which are
required), and the optional Padding sub-field. The Data-Length
sub-field is one octet in length and contains the length of the
unencrypted Password sub-field. The Password sub-field containsthe actual tunnel password. If the combined length (in octets) of
the unencrypted Data-Length and Password sub-fields is not an even
multiple of 16, then the Padding sub-field MUST be present. If it
is present, the length of the Padding sub-field is variable,
between 1 and 15 octets. The String field MUST be encrypted as
follows, prior to transmission:

Construct a plaintext version of the String field by
concatenating the Data-Length and Password sub-fields. If
necessary, pad the resulting string until its length (in
octets) is an even multiple of 16. It is recommended that zero
octets (0x00) be used for padding. Call this plaintext P.

Call the shared secret S, the pseudo-random 128-bit Request
Authenticator (from the corresponding Access-Request packet) R,
and the contents of the Salt field A. Break P into 16 octet
chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
Intermediate values b(1), b(2)...c(i) are required. Encryption
is performed in the following manner ('+' indicates
concatenation):

b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
. .
. .
. .
b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)

The resulting encrypted String field will contain
c(1)+c(2)+...+c(i).

On receipt, the process is reversed to yield the plaintext String.

If more than one set of tunneling attributes is returned by the
RADIUS server to the tunnel initiator, this Attribute SHOULD be
included in each set to indicate the relative preference assigned
to each tunnel. For example, suppose that Attributes describing
two tunnels are returned by the server, one with a Tunnel-Type of
PPTP and the other with a Tunnel-Type of L2TP. If the tunnel
initiator supports only one of the Tunnel-Types returned, it will
initiate a tunnel of that type. If, however, it supports both
tunnel protocols, it SHOULD use the value of the Tunnel-Preference
Attribute to decide which tunnel should be started. The tunnel
having the numerically lowest value in the Value field of this
Attribute SHOULD be given the highest preference. The values
assigned to two or more instances of the Tunnel-PreferenceAttribute within a given Access-Accept packet MAY be identical.
In this case, the tunnel initiator SHOULD use locally configured
metrics to decide which set of attributes to use. This Attribute
MAY be included (as a hint to the server) in Access-Request
packets, but the RADIUS server is not required to honor this hint.

A summary of the Tunnel-Preference 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 | Tag | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type
83 for Tunnel-Preference

Length
Always 6.

Tag
The Tag field is one octet in length and is intended to provide a
means of grouping attributes in the same packet which refer to the
same tunnel. Valid values for this field are 0x01 through 0x1F,
inclusive. If the Tag field is unused, it MUST be zero (0x00).

Value
The Value field is three octets in length and indicates the
preference to be given to the tunnel to which it refers; higher
preference is given to lower values, with 0x000000 being most
preferred and 0xFFFFFF least preferred.

This attribute indicates how many times the Acct-Input-Octets
counter has wrapped around 2^32 over the course of this service
being provided, and can only be present in Accounting-Request
records where the Acct-Status-Type is set to Stop or Interim-
Update.

A summary of the Acct-Input-Gigawords 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

52 for Acct-Input-Gigawords.

Length

6

Value

The Value field is four octets.

This attribute indicates how many times the Acct-Output-Octets
counter has wrapped around 2^32 in the course of delivering this
service, and can only be present in Accounting-Request records
where the Acct-Status-Type is set to Stop or Interim-Update.

A summary of the Acct-Output-Gigawords 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

53 for Acct-Output-Gigawords.

Length

6

Value

The Value field is four octets.

This attribute is included in an Accounting-Request packet to
record the time that this event occurred on the NAS, in seconds
since January 1, 1970 00:00 UTC.

A summary of the Event-Timestamp 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

55 for Event-Timestamp

Length

6

Value

The Value field is four octets encoding an unsigned integer with
the number of seconds since January 1, 1970 00:00 UTC.

This attribute is only present in an Access-Request packet
containing a Framed-Protocol of ARAP.

Only one of User-Password, CHAP-Password, or ARAP-Password needs
to be present in an Access-Request, or one or more EAP-Messages.

A summary of the ARAP-Password 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 | Value1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type

70 for ARAP-Password.

Length

18

Value

This attribute contains a 16 octet string, used to carry the
dial-in user's response to the NAS challenge and the client's own
challenge to the NAS. The high-order octets (Value1 and Value2)
contain the dial-in user's challenge to the NAS (2 32-bit numbers,
8 octets) and the low-order octets (Value3 and Value4) contain the
dial-in user's response to the NAS challenge (2 32-bit numbers, 8
octets).

This attribute is sent in an Access-Accept packet with Framed-
Protocol of ARAP, and includes password information that the NAS
should sent to the user in an ARAP "feature flags" packet.

A summary of the ARAP-Features 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 | Value1 | Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

71 for ARAP-Features.

Length

16Value

The Value field is a compound string containing information the
NAS should send to the user in the ARAP "feature flags" packet.

Value1: If zero, user cannot change their password. If non-zero
user can. (RADIUS does not handle the password changing, just
the attribute which indicates whether ARAP indicates they can.)

Value2: Minimum acceptable password length, from 0 to 8.

Value3: Password creation date in Macintosh format, defined as
32 unsigned bits representing seconds since Midnight GMT
January 1, 1904.

Value4: Password Expiration Delta from create date in seconds.

Value5: Current RADIUS time in Macintosh format.

This attribute is included in an Access-Accept packet with
Framed-Protocol of ARAP to indicate how the ARAP zone list for the
user should be used.

A summary of the ARAP-Zone-Access 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

72 for ARAP-Zone-Access.

Length

6Value

The Value field is four octets encoding an integer with one of the
following values:

1 Only allow access to default zone
2 Use zone filter inclusively
4 Use zone filter exclusively


The value 3 is skipped, not because these are bit flags, but
because 3 in some ARAP implementations means "all zones" which is
the same as not specifying a list at all under RADIUS.

If this attribute is present and the value is 2 or 4 then a
Filter-Id must also be present to name a zone list filter to apply
the access flag to.

This attribute identifies the ARAP Security Module to be used in
an Access-Challenge packet.

A summary of the ARAP-Security 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

73 for ARAP-Security.

Length

6Value

The Value field is four octets, containing an integer specifying
the security module signature, which is a Macintosh OSType.
(Macintosh OSTypes are 4 ascii characters cast as a 32-bit
integer)

This attribute contains the actual security module challenge or
response, and can be found in Access-Challenge and Access-Request
packets.

A summary of the ARAP-Security-Data 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

74 for ARAP-Security-Data.

Length

>=3

String

The String field contains the security module challenge or
response associated with the ARAP Security Module specified in
ARAP-Security.

This attribute MAY be included in an Access-Reject to indicate how
many authentication attempts a user may be allowed to attempt
before being disconnected.

It is primarily intended for use with ARAP authentication.A summary of the Password-Retry 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

75 for Password-Retry.

Length

6

Value

The Value field is four octets, containing an integer specifying
the number of password retry attempts to permit the user.

This attribute is used only in Access-Challenge packets, and
indicates to the NAS whether it should echo the user's response as
it is entered, or not echo it.


A summary of the Prompt 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

76 for Prompt.Length

6

Value

The Value field is four octets.

0 No Echo
1 Echo

This attribute is sent from the NAS to indicate the nature of the
user's connection.

The NAS MAY send this attribute in an Access-Request or
Accounting-Request to indicate the nature of the user's
connection.

A summary of the Connect-Info 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

77 for Connect-Info.

Length

>= 3

Text

The Text field consists of UTF-8 encoded 10646 characters.
The connection speed SHOULD be included at the beginning of the
first Connect-Info attribute in the packet. If the transmit and
receive connection speeds differ, they may both be included in the
first attribute with the transmit speed first (the speed the NAS
modem transmits at), a slash (/), the receive speed, then
optionally other information.For example, "28800 V42BIS/LAPM" or "52000/31200 V90"

More than one Connect-Info attribute may be present in an
Accounting-Request packet to accommodate expected efforts by ITU
to have modems report more connection information in a standard
format that might exceed 252 octets.

This attribute is for use in large distributed authentication
networks based on proxy. It is sent from a RADIUS Proxy Server to
a RADIUS Proxy Client in an Access-Accept to indicate a type of
user profile to be used. It should not be sent to a NAS.

A summary of the Configuration-Token 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

78 for Configuration-Token.

Length

>= 3

String

The String field is one or more octets. The actual format of the
information is site or application specific, and a robust
implementation SHOULD support the field as undistinguished octets.

The codification of the range of allowed usage of this field is
outside the scope of this specification.

This attribute encapsulates Extended Access Protocol packets
so as to allow the NAS to authenticate dial-in users via EAP
without having to understand the EAP protocol.

The NAS places any EAP messages received from the user into one or
more EAP attributes and forwards them to the RADIUS Server as part
of the Access-Request, which can return EAP messages in Access-
Challenge, Access-Accept and Access-Reject packets.

A RADIUS Server receiving EAP messages that it does not understand
SHOULD return an Access-Reject.

The NAS places EAP messages received from the authenticating peer
into one or more EAP-Message attributes and forwards them to the
RADIUS Server within an Access-Request message. If multiple EAP-
Messages are contained within an Access-Request or Access-
Challenge packet, they MUST be in order and they MUST be
consecutive attributes in the Access-Request or Access-Challenge
packet. Access-Accept and Access-Reject packets SHOULD only have
ONE EAP-Message attribute in them, containing EAP-Success or EAP-
Failure.

It is expected that EAP will be used to implement a variety of
authentication methods, including methods involving strong
cryptography. In order to prevent attackers from subverting EAP by
attacking RADIUS/EAP, (for example, by modifying the EAP-Success
or EAP-Failure packets) it is necessary that RADIUS/EAP provide
integrity protection at least as strong as those used in the EAP
methods themselves.

Therefore the Message-Authenticator attribute MUST be used to
protect all Access-Request, Access-Challenge, Access-Accept, and
Access-Reject packets containing an EAP-Message attribute.

Access-Request packets including an EAP-Message attribute without
a Message-Authenticator attribute SHOULD be silently discarded by
the RADIUS server. A RADIUS Server supporting EAP-Message MUST
calculate the correct value of the Message-Authenticator and
silently discard the packet if it does not match the value sent.
A RADIUS Server not supporting EAP-Message MUST return an Access-
Reject if it receives an Access-Request containing an EAP-Message
attribute. A RADIUS Server receiving an EAP-Message attribute that
it does not understand MUST return an Access-Reject.Access-Challenge, Access-Accept, or Access-Reject packets
including an EAP-Message attribute without a Message-Authenticator
attribute SHOULD be silently discarded by the NAS. A NAS
supporting EAP-Message MUST calculate the correct value of the
Message-Authenticator and silently discard the packet if it does
not match the value sent.

A summary of the EAP-Message 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

79 for EAP-Message.

Length

>= 3

String

The String field contains EAP packets, as defined in . If
multiple EAP-Message attributes are present in a packet their
values should be concatenated; this allows EAP packets longer than
253 octets to be passed by RADIUS.

This attribute MAY be used to sign Access-Requests to prevent
spoofing Access-Requests using CHAP, ARAP or EAP authentication
methods. It MAY be used in any Access-Request. It MUST be used
in any Access-Request, Access-Accept, Access-Reject or Access-
Challenge that includes an EAP-Message attribute.

A RADIUS Server receiving an Access-Request with a Message-
Authenticator Attribute present MUST calculate the correct value
of the Message-Authenticator and silently discard the packet if it
does not match the value sent.A RADIUS Client receiving an Access-Accept, Access-Reject or
Access-Challenge with a Message-Authenticator Attribute present
MUST calculate the correct value of the Message-Authenticator and
silently discard the packet if it does not match the value sent.

Earlier drafts of this memo used "Signature" as the name of this
attribute, but Message-Authenticator is more precise. Its
operation has not changed, just the name.

A summary of the Message-Authenticator 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

80 for Message-Authenticator

Length

18

String

When present in an Access-Request packet, Message-Authenticator is
an HMAC-MD5 checksum of the entire Access-Request packet,
including Type, ID, Length and authenticator, using the shared
secret as the key, as follows.

Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)

When the checksum is calculated the signature string should be
considered to be sixteen octets of zero.

For Access-Challenge, Access-Accept, and Access-Reject packets,
the Message-Authenticator is calculated as follows, using the
Request-Authenticator from the Access-Request this packet is in
reply to:

Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)When the checksum is calculated the signature string should be
considered to be sixteen octets of zero. The shared secret is
used as the key for the HMAC-MD5 hash. The is calculated and
inserted in the packet before the Response Authenticator is
calculated.

This attribute is not needed if the User-Password attribute is
present, but is useful for preventing attacks on other types of
authentication. This attribute is intended to thwart attempts by
an attacker to setup a "rogue" NAS, and perform online dictionary
attacks against the RADIUS server. It does not afford protection
against "offline" attacks where the attacker intercepts packets
containing (for example) CHAP challenge and response, and performs
a dictionary attack against those packets offline.

IP Security will eventually make this attribute unnecessary, so it
should be considered an interim measure.

This attribute is sent in an Access-Accept packet with Framed-
Protocol of ARAP, and contains the response to the dial-in
client's challenge.

A summary of the ARAP-Challenge-Response 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 | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

84 for ARAP-Challenge-Response.

Length

10Value

The Value field contains an 8 octet response to the dial-in
client's challenge. The RADIUS server calculates this value by
taking the dial-in client's challenge from the high order 8 octets
of the ARAP-Password attribute and performing DES encryption on
this value with the authenticating user's password as the key. If
the user's password is less than 8 octets in length, the password
is padded at the end with NULL octets to a length of 8 before
using it as a key.

This attribute indicates the number of seconds between each
interim update in seconds for this specific session. This value
can only appear in the Access-Accept message.

A summary of the Acct-Interim-Interval 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

85 for Acct-Interim-Interval.

Length

6

Value

The Value field contains the number of seconds between each
interim update to be sent from the NAS for this session. The value
MUST NOT be smaller than 60. The value SHOULD NOT be smaller than
600, and careful consideration should be given to its impact on
network traffic.

This Attribute contains a text string which identifies the port of
the NAS which is authenticating the user. It is only used in
Access-Request and Accounting-Request packets. Note that this is
using "port" in its sense of a physical connection on the NAS, not
in the sense of a TCP or UDP port number.

Either NAS-Port or NAS-Port-Id SHOULD be present in an Access-
Request packet, if the NAS differentiates among its ports. NAS-
Port-Id is intended for use by NASes which cannot conveniently
number their ports.

A summary of the NAS-Port-Id 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

87 for NAS-Port-Id.

Length

>= 3

Text

The Text field contains the name of the port using UTF-8 encoded
10646 characters.

This Attribute contains the name of an assigned address pool that
SHOULD be used to assign an address for the user. If a NAS does
not support multiple address pools, the NAS should ignore this
Attribute. Address pools are usually used for IP addresses, but
can be used for other protocols if the NAS supports pools for
those protocols.A summary of the Framed-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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

88 for Framed-Pool

Length

>= 3

String

The string field contains the name of an assigned address pool
configured on the NAS.

This Attribute indicates the identifying IPv6 Address of the NAS
which is requesting authentication of the user, and SHOULD be
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-Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type

95 for NAS-IPv6-Address

Length

18

Address

The Address field is 16 octets.

This Attribute indicates the IPv6 interface identifier to be
configured for the user. It MAY be used in Access-Accept packets.
If the Interface-Identifier IPv6CP option has been
successfully negotiated, this Attribute MUST be included in an
Access-Request packet as a hint by the NAS to the server that it
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-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

96 for Framed-Interface-Id

Length

10

Interface-Id

The Interface-Id field is 8 octets.

This Attribute indicates an IPv6 prefix (and corresponding route)
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
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
honor the hint. Since it is assumed that the NAS will plumb a
route corresponding to the prefix, it is not necessary for the
server to also send a Framed-IPv6-Route attribute for the same
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

97 for Framed-IPv6-Prefix

Length

At least 4 and no larger than 20.

Reserved

This field, which is reserved and MUST be present, is always set
to zero.

Prefix-Length

The length of the prefix, in bits. At least 0 and no larger than
128.Prefix

The Prefix field is up to 16 octets in length. Bits outside of
the Prefix-Length, if included, must be zero.

This Attribute indicates the system with which to connect the
user, when the Login-Service Attribute is included. It MAY be
used in Access-Accept packets. It MAY be used in an Access-
Request packet as a hint to the server that the NAS would prefer
to use that host, but the server is not required to honor the
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

98 for Login-IPv6-Host

Length

18Address

The Address field is 16 octets in length. The value
0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD
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 connect
the user to. Other values indicate the address the NAS SHOULD
connect the user to.

This Attribute provides routing information to be configured for
the user on the NAS. It is used in the Access-Accept packet and
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

99 for Framed-IPv6-Route

Length

>=3

Text

The Text field is one or more octets, and its contents are
implementation dependent. The field is not NUL (hex 00)
terminated. It is intended to be human readable and MUST NOT
affect operation of the protocol.

For IPv6 routes, it SHOULD contain a destination prefix optionally
followed by a slash and a decimal length specifier stating how
many high order bits of the prefix to use. That is followed by a
space, a gateway address, a space, and one or more metrics
(encoded in decimal) separated by spaces. Prefixes and addresses
are formatted as described in . For example,
"2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".Whenever the gateway address is the IPv6 unspecified address the
IP address of the user SHOULD be used as the gateway address. The
unspecified address can be expressed in any of the acceptable
formats described in . For example, "2000:0:0:106::/64 :: 1".

This Attribute contains the name of an assigned pool that SHOULD
be used to assign an IPv6 prefix for the user. If a NAS does not
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

100 for Framed-IPv6-Pool

Length

>= 3

String

The string field contains the name of an assigned IPv6 prefix pool
configured on the NAS. The field is not NUL (hex 00) terminated.3. Table of AttributesThe 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 0 0 0-1 95 NAS-IPv6-Address
0-1 0-1 0 0 0-1 96 Framed-Interface-Id
0+ 0+ 0 0 0+ 97 Framed-IPv6-Prefix
0+ 0+ 0 0 0+ 98 Login-IPv6-Host
0 0+ 0 0 0+ 99 Framed-IPv6-Route
0 0-1 0 0 0-1 100 Framed-IPv6-Pool4. References Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels",,, March, 1997.

Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646",, October 1996.

Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming",, June 1999.

Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)",, June
2000.

Rigney, C., "RADIUS Accounting",, June 2000.

Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting
Modifications for Tunnel Protocol Support",, June
2000.

Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",, June 2000.

Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions",, June 2000.

Kent S. and R. Atkinson, "Security Architecture for the
Internet Protocol",, November 1998.

Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs",,, October
1998.

Haskin, D. and E. Allen, "IP Version 6 over PPP",,
December 1998.

Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds",, February 2001.

Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification",, December 1998.

Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels",, March 1999. Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers",, August 2000.

Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture",, July 1998.5. Security ConsiderationsThis document describes the use of RADIUS for the purposes of
authentication, authorization and accounting in IPv6-enabled
networks. In such networks, the RADIUS protocol may run either over
IPv4 or over IPv6. Known security vulnerabilities of the RADIUS
protocol are described in , and .

Since IPSEC is mandatory to implement for IPv6, it is expected
that running RADIUS implementations supporting IPv6 will typically
run over IPSEC. Where RADIUS is run over IPSEC and where
certificates are used for authentication, it may be desirable to
avoid management of RADIUS shared secrets, so as to leverage the
improved scalability of public key infrastructure.

Within RADIUS, a shared secret is used for hiding of attributes such
as User-Password and Tunnel-Password . In addition, the
shared secret is used in computation of the Response Authenticator
, as well as the Message-Authenticator attribute . Therefore,
in RADIUS a shared secret is used to provide confidentiality as well
as integrity protection and authentication. As a result, only use of
IPSEC ESP with a non-null transform can provide security services
sufficient to substitute for RADIUS application-layer security.
Therefore, where IPSEC AH or ESP null is used, it will typically
still be necessary to configure a RADIUS shared secret.

However, where RADIUS is run over IPSEC ESP with a non-null
transform, the secret shared between the NAS and the RADIUS server
MAY NOT be configured. In this case, a shared secret of zero length
MUST be assumed.6. IANA ConsiderationsThis document requires the assignment of six new RADIUS attribute
numbers for the following attributes:

NAS-IPv6-Address
Framed-Interface-Id
Framed-IPv6-Prefix
Login-IPv6-Host
Framed-IPv6-Route
Framed-IPv6-Pool

Seefor the registered list of numbers.7. AcknowledgmentsThe authors would like to acknowledge Jun-ichiro itojun Hagino of IIJ
Research Laboratory, Darran Potter of Cisco and Carl Rigney of Lucent
for contributions to this document.8. Authors' AddressesBernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: +1 425 936 6605
Fax: +1 425 936 7329
EMail: [email protected]


Glen Zorn
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004

Phone: +1 425 471 4861
EMail: [email protected]


Dave Mitton
Circular Logic UnLtd.
733 Turnpike Street #154
North Andover, MA 01845

Phone: 978 683-1814
Email: [email protected] Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.



















Aboba, et al. Standards Track

It is possible that the NAS cannot honor Disconnect-Request or
CoA-Request messages for some reason. The Error-Cause Attribute
provides more detail on the cause of the problem. It MAY be
included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
messages.

A summary of the Error-Cause 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 | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

101 for Error-Cause

Length

6

Value

The Value field is four octets, containing an integer specifying
the cause of the error. Values 0-199 and 300-399 are reserved.
Values 200-299 represent successful completion, so that these
values may only be sent within Disconnect-ACK or CoA-ACK message
and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values400-499 represent fatal errors committed by the RADIUS server, so
that they MAY be sent within CoA-NAK or Disconnect-NAK messages,
and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages.
Values 500-599 represent fatal errors occurring on a NAS or RADIUS
proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK
messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK
messages. Error-Cause values SHOULD be logged by the RADIUS
server. Error-Code values (expressed in decimal) include:

# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request Initiated

"Residual Session Context Removed" is sent in response to a
Disconnect-Request if the user session is no longer active, but
residual session context was found and successfully removed. This
value is only sent within a Disconnect-ACK and MUST NOT be sent
within a CoA-ACK, Disconnect-NAK or CoA-NAK.

"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be
sent by implementations of this specification.

"Unsupported Attribute" is a fatal error sent if a Request contains
an attribute (such as a Vendor-Specific or EAP-Message Attribute)
that is not supported.

"Missing Attribute" is a fatal error sent if critical attributes
(such as NAS or session identification attributes) are missing from a
Request.

"NAS Identification Mismatch" is a fatal error sent if one or more
NAS identification attributes (see.) do not match the
identity of the NAS receiving the Request."Invalid Request" is a fatal error sent if some other aspect of the
Request is invalid, such as if one or more attributes (such as EAP-
Message Attribute(s)) are not formatted properly.

"Unsupported Service" is a fatal error sent if a Service-Type
Attribute included with the Request is sent with an invalid or
unsupported value.

"Unsupported Extension" is a fatal error sent due to lack of support
for an extension such as Disconnect and/or CoA messages. This will
typically be sent by a proxy receiving an ICMP port unreachable
message after attempting to forward a Request to the NAS.

"Administratively Prohibited" is a fatal error sent if the NAS is
configured to prohibit honoring of Request messages for the specified
session.

"Request Not Routable" is a fatal error which MAY be sent by a RADIUS
proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS
proxy was unable to determine how to route the Request to the NAS.
For example, this can occur if the required entries are not present
in the proxy's realm routing table.

"Session Context Not Found" is a fatal error sent if the session
context identified in the Request does not exist on the NAS.

"Session Context Not Removable" is a fatal error sent in response to
a Disconnect-Request if the NAS was able to locate the session
context, but could not remove it for some reason. It MUST NOT be
sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a
Disconnect-NAK.

"Other Proxy Processing Error" is a fatal error sent in response to a
Request that could not be processed by a proxy, for reasons other
than routing.

"Resources Unavailable" is a fatal error sent when a Request could
not be honored due to lack of available NAS resources (memory, non-
volatile storage, etc.).

"Request Initiated" is a fatal error sent in response to a Request
including a Service-Type Attribute with a value of "Authorize Only".
It indicates that the Disconnect-Request or CoA-Request has not been
honored, but that a RADIUS Access-Request including a Service-Type
Attribute with value "Authorize Only" is being sent to the RADIUS
server.

The EAP-Key-Name Attribute, defined in "Diameter Extensible
Authentication Protocol (EAP) Application" , contains the
EAP Session-Id, as described in "Extensible Authentication
Protocol (EAP) Key Management Framework" . Exactly how
this attribute is used depends on the link layer in question.

It should be noted that not all link layers use this name. An
EAP-Key-Name Attribute MAY be included within Access-Request,
Access-Accept, and CoA-Request packets. A summary of the EAP-Key-
Name 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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

102 Length

>=3

String

The String field is one or more octets, containing the EAP
Session-Id, as defined in "Extensible Authentication Protocol
(EAP) Key Management Framework" . Since the NAS operates
as a pass-through in EAP, it cannot know the EAP Session-Id before
receiving it from the RADIUS server. As a result, an EAP-Key-Name
Attribute sent in an Access-Request MUST only contain a single NUL
character. A RADIUS server receiving an Access-Request with an
EAP-Key-Name Attribute containing anything other than a single NUL
character MUST silently discard the attribute. In addition, the
RADIUS server SHOULD include this attribute in an Access-Accept or
CoA-Request only if an EAP-Key-Name Attribute was present in the
Access-Request. Since a NAS will typically only include an EAP-
Key-Name Attribute in an Access-Request in situations where the
attribute is required to provision service, if an EAP-Key-Name
Attribute is included in an Access-Request but is not present in
the Access-Accept, the NAS SHOULD treat the Access-Accept as
though it were an Access-Reject. If an EAP-Key-Name Attribute was
not present in the Access-Request but is included in the Access-
Accept, then the NAS SHOULD silently discard the EAP-Key-Name
Attribute. As noted in Section 6.2.2 of , the
Connectivity Association Key Name (CKN) is derived from the EAP
Session-Id, and, as described in Section 9.3.3 of ,
the CKN is subsequently used in the derivation of the Key
Encrypting Key (KEK) and the Integrity Check Value Key (ICK),
which protect the Secure Association Keys (SAKs) utilized by Media
Access Control Security (MACsec). As a result, for the NAS to
acquire information needed in the MACsec Key Agreement (MKA)
exchange, it needs to include the EAP-Key-Name Attribute in the
Access-Request and receive it from the RADIUS server in the
Access-Accept.

The Chargeable-User-Identity attribute, or CUI, (Type value 89) is a
unique, temporary handle used as means to, for example, correlate
authentication, accounting, and bill post-processing for a particular
chargeable subscriber. The CUI format and use follows guidelines
defined by .

In the scope of this document, the CUI attribute MAY be present in
the Access-Request. The CUI MAY also be present in the Access-
Accept. The CUI MUST be present in the Access-Accept if it was
present in the Access-Request. If the use of the Chargeable-User-
Identity attribute is supported, then the MAG and/or the LMA commits
to include the Chargeable-User-Identity attribute in all subsequent
RADIUS Accounting packets they send for the given user.

This Attribute contains the actual upstream train rate of a
subscriber's synchronized DSL link. It MAY be included in both
Access-Request and Accounting-Request packets.

A summary of the Actual-Data-Rate-Upstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

129 (0x81) for Actual-Data-Rate-Upstream

Vendor-Length

6

Value

This field contains a 4-byte unsigned integer, indicating the
subscriber's actual data rate upstream of a synchronized DSL link.
The rate is coded in bits per second.

This Attribute contains the actual downstream train rate of a
subscriber's synchronized DSL link. It MAY be included in both
Access-Request and Accounting-Request packets.

A summary of the Actual-Data-Rate-Downstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

130 (0x82) for Actual-Data-Rate-Downstream

Vendor-Length

6

Value

This field contains a 4-byte unsigned integer, indicating the
subscriber's actual data rate downstream of a synchronized DSL
link. The rate is coded in bits per second.

This Attribute contains the subscriber's operator-configured
minimum upstream data rate. It MAY be included in Accounting-
Request packets.

A summary of the Minimum-Data-Rate-Upstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

131 (0x83) for Minimum-Data-Rate-Upstream

Vendor-Length

6Value

This field contains a 4-byte unsigned integer, indicating the
subscriber's minimum upstream data rate (as configured by the
operator). The rate is coded in bits per second.

This Attribute contains the subscriber's operator-configured
minimum downstream data rate. It MAY be included in Accounting-
Request packets.

A summary of the Minimum-Data-Rate-Downstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

132 (0x84) for Minimum-Data-Rate-Downstream

Vendor-Length

6

Value

This field contains a 4-byte unsigned integer, indicating the
subscriber's minimum downstream data rate (as configured by the
operator). The rate is coded in bits per second.

This Attribute contains the subscriber's attainable upstream data
rate. It MAY be included in Accounting-Request packets.

A summary of the Attainable-Data-Rate-Upstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

133 (0x85) for Attainable-Data-Rate-Upstream

Vendor-Length

6

Value

This field contains a 4-byte unsigned integer, indicating the
subscriber's actual DSL attainable upstream data rate. The rate
is coded in bits per second.

This Attribute contains the subscriber's attainable downstream
data rate. It MAY be included in Accounting-Request packets.

A summary of the Attainable-Data-Rate-Downstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

134 (0x86) for Attainable-Data-Rate-Downstream

Vendor-Length

6Value

This field contains a 4-byte unsigned integer, indicating the
subscriber's actual DSL attainable downstream data rate. The rate
is coded in bits per second.

This Attribute contains the subscriber's maximum upstream data
rate, as configured by the operator. It MAY be included in
Accounting-Request packets.

A summary of the Maximum-Data-Rate-Upstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

135 (0x87) for Maximum-Data-Rate-Upstream

Vendor-Length

6

Value

This field is a 4-byte unsigned integer, indicating the numeric
value of the subscriber's DSL maximum upstream data rate. The
rate is coded in bits per second.

This Attribute contains the subscriber's maximum downstream data
rate, as configured by the operator. It MAY be included in
Accounting-Request packets.A summary of the Maximum-Data-Rate-Downstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

136 (0x88) for Maximum-Data-Rate-Downstream

Vendor-Length

6

Value

This field is a 4-byte unsigned integer, indicating the numeric
value of the subscriber's DSL maximum downstream data rate. The
rate is coded in bits per second.

This Attribute contains the subscriber's minimum upstream data
rate in low power state, as configured by the operator. It MAY be
included in Accounting-Request packets.

A summary of the Minimum-Data-Rate-Upstream-Low-Power 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

137 (0x89) for Minimum-Data-Rate-Upstream-Low-PowerVendor-Length

6

Value

This field is a 4-byte unsigned integer, indicating the numeric
value of the subscriber's DSL minimum upstream data rate when in
low power state (L1/L2). The rate is coded in bits per second.

This Attribute contains the subscriber's minimum downstream data
rate in low power state, as configured by the operator. It MAY be
included in Accounting-Request packets.

A summary of the Minimum-Data-Rate-Downstream-Low-Power 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

138 (0x8A) for Minimum-Data-Rate-Downstream-Low-Power

Vendor-Length

6

Value

This field is a 4-byte unsigned integer, indicating the numeric
value of the subscriber's DSL minimum downstream data rate. The
rate is coded in bits per second.

This Attribute contains the subscriber's maximum one-way upstream
interleaving delay, as configured by the operator. It MAY be
included in Accounting-Request packets.

A summary of the Maximum-Interleaving-Delay-Upstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

139 (0x8B) for Maximum-Interleaving-Delay-Upstream

Vendor-Length

6

Value

This field is a 4-byte unsigned integer, indicating the numeric
value in milliseconds of the subscriber's DSL maximum one-way
upstream interleaving delay.

This Attribute contains the subscriber's actual one-way upstream
interleaving delay. It MAY be included in Accounting-Request
packets.

A summary of the Actual-Interleaving-Delay-Upstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

140 (0x8C) for Actual-Interleaving-Delay-Upstream

Vendor-Length

6

Value

This field is a 4-byte unsigned integer, indicating the numeric
value in milliseconds of the subscriber's DSL actual upstream
interleaving delay.

This Attribute contains the subscriber's maximum one-way
downstream interleaving delay, as configured by the operator. It
MAY be included in Accounting-Request packets.

A summary of the Maximum-Interleaving-Delay-Downstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

141 (0x8D) for Maximum-Interleaving-Delay-DownstreamVendor-Length

6

Value

This field is a 4-byte unsigned integer, indicating the numeric
value in milliseconds of the subscriber's DSL maximum one-way
downstream interleaving delay.

This Attribute contains the subscriber's actual one-way downstream
interleaving delay. It MAY be included in Accounting-Request
packets.

A summary of the Actual-Interleaving-Delay-Downstream 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

142 (0x8E) for Actual-Interleaving-Delay-Downstream

Vendor-Length

6

Value

This field is a 4-byte unsigned integer, indicating the numeric
value in milliseconds of the subscriber's DSL actual downstream
interleaving delay.

This Attribute describes the encapsulation(s) used by the
subscriber on the DSL access loop. It MAY be present in both
Access-Request and Accounting-Request packets.

A summary of the Access-Loop-Encapsulation 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont'd) |
+-+-+-+-+-+-+-+-+

Vendor-Type

144 (0x90) for Access-Loop-Encapsulation

Vendor-Length

5

Value

This field is a string 3 bytes in length, logically divided into
three 1-byte sub-fields as shown in the following diagram:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Link | Encaps 1 | Encaps 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Valid values for the sub-fields are as follows:

Data Link

0x01 AAL5
0x02 EthernetEncaps 1

0x00 NA - Not Available
0x01 Untagged Ethernet
0x02 Single-Tagged Ethernet

Encaps 2

0x00 NA - Not Available
0x01 PPPoA LLC
0x02 PPPoA Null
0x03 IPoA LLC
0x04 IPoA Null
0x05 Ethernet over AAL5 LLC with FCS
0x06 Ethernet over AAL5 LLC without FCS
0x07 Ethernet over AAL5 Null with FCS
0x08 Ethernet over AAL5 Null without FCS

The presence of this Attribute indicates that the IWF has been
performed with respect to the subscriber's session; note that no
data field is necessary. It MAY be included in both Access-
Request and Accounting-Request packets.

A summary of the IWF-Session Attribute format is shown below. The
fields are transmitted from left to right.

0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | Vendor-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor-Type

254 (0xFE) for IWF-Session

Vendor-Length

24. Table of AttributesThe following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity; note that since none
of the DSL Forum VSAs may be present in the Access-Accept, Access-
Reject or Access-Challenge packets, those columns have been omitted
from the table.

Request Acct-Request # Attribute
0-1 0-1 1 Agent-Circuit-Id
0-1 0-1 2 Agent-Remote-Id
0-1 0-1 129 Actual-Data-Rate-Upstream
0-1 0-1 130 Actual-Data-Rate-Downstream
0 0-1 131 Minimum-Data-Rate-Upstream
0 0-1 132 Minimum-Data-Rate-Downstream
0 0-1 133 Attainable-Data-Rate-Upstream
0 0-1 134 Attainable-Data-Rate-Downstream
0 0-1 135 Maximum-Data-Rate-Upstream
0 0-1 136 Maximum-Data-Rate-Downstream
0 0-1 137 Minimum-Data-Rate-Upstream-Low-Power
0 0-1 138 Minimum-Data-Rate-Downstream-Low-Power
0 0-1 139 Maximum-Interleaving-Delay-Upstream
0 0-1 140 Actual-Interleaving-Delay-Upstream
0 0-1 141 Maximum-Interleaving-Delay-Downstream
0 0-1 142 Actual-Interleaving-Delay-Downstream
0-1 0-1 144 Access-Loop-Encapsulation
0-1 0-1 254 IWF-Session

The following table defines the meaning of the above table entries.

0 This Attribute MUST NOT be present in packet.

0-1 Zero or one instances of this Attribute MAY be present in
packet.5. Security ConsiderationsThe security of these Attributes relies on an implied trust
relationship between the Access Node/DSLAM and the BRAS. The
identifiers that are inserted by the Access Node/DSLAM are
unconditionally trusted; the BRAS does not perform any validity check
on the information received. These Attributes are intended to be
used in environments in which the network infrastructure (the Access
Node/DSLAM, the BRAS, and the entire network in which those two
devices reside) is trusted and secure.As used in this document, the word "trusted" implies that
unauthorized traffic cannot enter the network except through secured
and trusted devices and that all devices internal to the network are
secure and trusted. Careful consideration should be given to the
potential security vulnerabilities that are present in this model
before deploying this option in actual networks.

The Attributes described in this document neither increase nor
decrease the security of the RADIUS protocol. For discussions of
various RADIUS vulnerabilities, see , , ,
and .6. References

If this attribute is present in an Access-Request message, a
RADIUS server implementing this specification MUST treat the
Access-Request as a request for Digest Authentication. When a
RADIUS client receives a (Proxy-)Authorization header, it puts
the request-digest value into a Digest-Response Attribute.
This attribute (which enables the user to prove possession of
the password) MUST only be used in Access-Request packets.Type
103 for Digest-Response.
Length
>= 3
Text
When using HTTP Digest, the text field is 32 octets long and
contains a hexadecimal representation of a 16-octet digest
value as it was calculated by the authenticated client. Other
digest algorithms MAY define different digest lengths. The
text field MUST be copied from request-digest of digest-
response without surrounding quotes.

This attribute describes a protection space component of the
RADIUS server. HTTP-style protocols differ in their definition
of the protection space. See, for
details. It MUST only be used in Access-Request, Access-
Challenge, and Accounting-Request packets.
Type
104 for Digest-Realm
Length
>= 3
Text
In Access-Requests, the RADIUS client takes the value of the
realm directive (realm-value according to ) without
surrounding quotes from the HTTP-style request it wants to
authenticate. In Access-Challenge packets, the RADIUS server
puts the expected realm value into this attribute.

This attribute holds a nonce to be used in the HTTP Digest
calculation. If the Access-Request had a Digest-Method and a
Digest-URI but no Digest-Nonce Attribute, the RADIUS server
MUST put a Digest-Nonce Attribute into its Access-Challenge
packet. This attribute MUST only be used in Access-Request and
Access-Challenge packets.
Type
105 for Digest-Nonce
Length
>= 3Text
In Access-Requests, the RADIUS client takes the value of the
nonce directive (nonce-value in ) without surrounding
quotes from the HTTP-style request it wants to authenticate.
In Access-Challenge packets, the attribute contains the nonce
selected by the RADIUS server.

This attribute enables the RADIUS server to prove possession of
the password. If the previously received Digest-Qop Attribute
was 'auth-int' (without surrounding quotes), the RADIUS server
MUST send a Digest-HA1 Attribute instead of a Digest-Response-
Auth Attribute. The Digest-Response-Auth Attribute MUST only
be used in Access-Accept packets. The RADIUS client puts the
attribute value without surrounding quotes into the rspauth
directive of the Authentication-Info header.
Type
106 for Digest-Response-Auth.
Length
>= 3
Text
The RADIUS server calculates a digest according toand copies the result into this attribute.
Digest algorithms other than the one defined in MAY
define digest lengths other than 32.

This attribute holds a nonce to be used in the HTTP Digest
calculation.


The RADIUS server MAY put a Digest-Nextnonce Attribute into an
Access-Accept packet. If this attribute is present, the RADIUS
client MUST put the contents of this attribute into the
nextnonce directive of an Authentication-Info header in its
HTTP-style response. This attribute MUST only be used in
Access-Accept packets.
Type
107 for Digest-Nextnonce
Length
>= 3
Text
It is recommended that this text be base64 or hexadecimal data.

This attribute holds the method value to be used in the HTTP
Digest calculation. This attribute MUST only be used in
Access-Request and Accounting-Request packets.
Type
108 for Digest-Method
Length
>= 3
Text
In Access-Requests, the RADIUS client takes the value of the
request method from the HTTP-style request it wants to
authenticate.

This attribute is used to transport the contents of the
digest-uri directive or the URI of the HTTP-style request. It
MUST only be used in Access-Request and Accounting-Request
packets.
Type
109 for Digest-URI
Length
>= 3
Text
If the HTTP-style request has an Authorization header, the
RADIUS client puts the value of the uri directive found in the
HTTP-style request Authorization header (known as "digest-uri-
value" in) without surrounding
quotes into this attribute. If there is no Authorization
header, the RADIUS client takes the value of the request URI
from the HTTP-style request it wants to authenticate.

This attribute holds the Quality of Protection parameter that
influences the HTTP Digest calculation. This attribute MUST
only be used in Access-Request, Access-Challenge, and
Accounting-Request packets. A RADIUS client SHOULD insert one
of the Digest-Qop attributes it has received in a previous
Access-Challenge packet. RADIUS servers SHOULD insert at least
one Digest-Qop Attribute in an Access-Challenge packet.
Digest-Qop is optional in order to preserve backward
compatibility with a minimal implementation of .Type
110 for Digest-Qop
Length
>= 3
Text
In Access-Requests, the RADIUS client takes the value of the
qop directive (qop-value as described in ) from the
HTTP-style request it wants to authenticate. In Access-
Challenge packets, the RADIUS server puts a desired qop-value
into this attribute. If the RADIUS server supports more than
one "quality of protection" value, it puts each qop-value into
a separate Digest-Qop Attribute.

This attribute holds the algorithm parameter that influences
the HTTP Digest calculation. It MUST only be used in Access-
Request, Access-Challenge and Accounting-Request packets. If
this attribute is missing, MD5 is assumed.
Type
111 for Digest-Algorithm
Length
>= 3
Text
In Access-Requests, the RADIUS client takes the value of the
algorithm directive (as described in)
from the HTTP-style request it wants to authenticate. In
Access-Challenge packets, the RADIUS server SHOULD put the
desired algorithm into this attribute.

When using the qop-value 'auth-int', a hash of the HTTP-style
message body's contents is required for digest calculation.
Instead of sending the complete body of the message, only its
hash value is sent. This hash value can be used directly in
the digest calculation.

The clarifications described inabout
the hash of empty entity bodies apply to the Digest-Entity-
Body-Hash Attribute. This attribute MUST only be sent in
Access-Request packets.
Type
112 for Digest-Entity-Body-Hash
Length
>= 3Text
The attribute holds the hexadecimal representation of
H(entity-body). This hash is required by certain
authentication mechanisms, such as HTTP Digest with quality of
protection set to 'auth-int'. RADIUS clients MUST use this
attribute to transport the hash of the entity body when HTTP
Digest is the authentication mechanism and the RADIUS server
requires that the integrity of the entity body (e.g., qop
parameter set to 'auth-int') be verified. Extensions to this
document may define support for authentication mechanisms other
than HTTP Digest.

This attribute holds the client nonce parameter that is used in
the HTTP Digest calculation. It MUST only be used in Access-
Request packets.
Type
113 for Digest-CNonce
Length
>= 3
Text
This attribute includes the value of the cnonce-value
without surrounding quotes, taken from the HTTP-style request.

This attribute includes the nonce count parameter that is used
to detect replay attacks. The attribute MUST only be used in
Access-Request packets.
Type
114 for Digest-Nonce-Count
Length
10
Text
In Access-Requests, the RADIUS client takes the value of the nc
directive (nc-value according to ) without surrounding
quotes from the HTTP-style request it wants to authenticate.

This attribute holds the user name used in the HTTP Digest
calculation. The RADIUS server MUST use this attribute only
for the purposes of calculating the digest. In order to
determine the appropriate user credentials, the RADIUS serverMUST use the User-Name (1) Attribute, and MUST NOT use the
Digest-Username Attribute. This attribute MUST only be used in
Access-Request and Accounting-Request packets.
Type
115 for Digest-Username
Length
>= 3
Text
In Access-Requests, the RADIUS client takes the value of the
username directive (username-value according to )
without surrounding quotes from the HTTP-style request it wants
to authenticate.

This attribute holds the opaque parameter that is passed to the
HTTP-style client. The HTTP-style client will pass this value
back to the server (i.e., the RADIUS client) without
modification. This attribute MUST only be used in Access-
Request and Access-Challenge packets.
Type
116 for Digest-Opaque
Length
>= 3
Text
In Access-Requests, the RADIUS client takes the value of the
opaque directive (opaque-value according to ) without
surrounding quotes from the HTTP-style request it wants to
authenticate and puts it into this attribute. In Access-
Challenge packets, the RADIUS server MAY include this
attribute.

This attribute is a placeholder for future extensions and
corresponds to the auth-param parameter defined in. The Digest-Auth-Param is the mechanism
whereby the RADIUS client and RADIUS server can exchange auth-
param extension parameters contained within Digest headers that
are not understood by the RADIUS client and for which there are
no corresponding stand-alone attributes.

Unlike the previously listed Digest-* attributes, the Digest-
Auth-Param contains not only the value but also the parameter
name, since the parameter name is unknown to the RADIUS client.
If the Digest header contains several unknown parameters, thenthe RADIUS implementation MUST repeat this attribute, and each
instance MUST contain one different unknown Digest
parameter/value combination. This attribute MUST ONLY be used
in Access-Request, Access-Challenge, Access-Accept, and
Accounting-Request packets.
Type
117 for Digest-Auth-Param
Length
>= 3
Text
The text consists of the whole parameter, including its name,
the equal sign ('='), and quotes.

This attribute holds the auts parameter that is used in the
Digest AKA calculation. It is only used if the
algorithm of the digest-response denotes a version of AKA
Digest . This attribute MUST only be used in Access-
Request packets.
Type
118 for Digest-AKA-Auts
Length
>= 3
Text
In Access-Requests, the RADIUS client takes the value of the
auts directive (auts-param according to) without surrounding quotes from the HTTP-style
request it wants to authenticate.

When a RADIUS client has asked for a nonce, the RADIUS server
MAY send one or more Digest-Domain attributes in its Access-
Challenge packet. The RADIUS client puts them into the quoted,
space-separated list of URIs of the domain directive of a WWW-
Authenticate header. Together with Digest-Realm, the URIs in
the list define the protection space (see ,) for some HTTP-style protocols. This attribute MUST only
be used in Access-Challenge and Accounting-Request packets.
Type
119 for Digest-Domain
Length
3Text
This attribute consists of a single URI that defines a
protection space component.

This attribute is sent by a RADIUS server in order to notify
the RADIUS client whether it has accepted a nonce. If the
nonce presented by the RADIUS client was stale, the value is
'true' and is 'false' otherwise. The RADIUS client puts the
content of this attribute into a stale directive of the WWW-
Authenticate header in the HTTP-style response to the request
it wants to authenticate. The attribute MUST only be used in
Access-Challenge packets.
Type
120 for Digest-Stale
Length
3
Text
The attribute has either the value 'true' or 'false' (both
values without surrounding quotes).

This attribute is used to allow the generation of an
Authentication-Info header, even if the HTTP-style response's
body is required for the calculation of the rspauth value. It
SHOULD be used in Access-Accept packets if the required quality
of protection (qop) is 'auth-int'.

This attribute MUST NOT be sent if the qop parameter was not
specified or has a value of 'auth' (in this case, use Digest-
Response-Auth instead).

The Digest-HA1 Attribute MUST only be sent by the RADIUS server
or processed by the RADIUS client if at least one of the
following conditions is true:

+ The Digest-Algorithm Attribute's value is 'MD5-sess' or
'AKAv1-MD5-sess'.

+ IPsec is configured to protect traffic between the RADIUS
client and RADIUS server with IPsec (see).

This attribute MUST only be used in Access-Accept packets.Type
121 for Digest-HA1
Length
>= 3
Text
This attribute contains the hexadecimal representation of H(A1)
as described in , Sections,, and.

This attribute is used for the authorization of SIP messages.
The SIP-AOR Attribute identifies the URI, the use of which must
be authenticated and authorized. The RADIUS server uses this
attribute to authorize the processing of the SIP request. The
SIP-AOR can be derived from, for example, the To header field
in a SIP REGISTER request (user under registration), or the
From header field in other SIP requests. However, the exact
mapping of this attribute to SIP can change due to new
developments in the protocol. This attribute MUST only be used
when the RADIUS client wants to authorize SIP users and MUST
only be used in Access-Request packets.
Type
122 for SIP-AOR
Length
>= 3
Text
The syntax of this attribute corresponds either to a SIP URI
(with the format defined in or a tel URI (with the
format defined in ).

The SIP-AOR Attribute holds the complete URI, including
parameters and other parts. It is up to the RADIUS server as
to which components of the URI are regarded in the
authorization decision.4. Diameter CompatibilityThis document defines support for Digest Authentication in RADIUS. A
companion document "Diameter Session Initiation Protocol (SIP)
Application" defines support for Digest Authentication in
Diameter, and addresses compatibility issues between RADIUS and
Diameter.5. Table of AttributesThe following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity.Access- Access- Access- Access- Acct-
Request Accept Reject Challenge Req # Attribute
0-1 0 0 0 0-1 1 User-Name
0-1 0 0 1 0 24 State
1 1 1 1 0-1 80 Message-Authenticator
0-1 0 0 0 0 103 Digest-Response
0-1 0 0 1 0-1 104 Digest-Realm
0-1 0 0 1 0 105 Digest-Nonce
0 0-1 0 0 0 106 Digest-Response-Auth
0 0-1 0 0 0 107 Digest-Nextnonce
1 0 0 0 0-1 108 Digest-Method
0-1 0 0 0 0-1 109 Digest-URI
0-1 0 0 0+ 0-1 110 Digest-Qop
0-1 0 0 0-1 0-1 111 Digest-Algorithm
0-1 0 0 0 0 112 Digest-Entity-Body-Hash
0-1 0 0 0 0 113 Digest-CNonce
0-1 0 0 0 0 114 Digest-Nonce-Count
0-1 0 0 0 0-1 115 Digest-Username
0-1 0 0 0-1 0 116 Digest-Opaque
0+ 0+ 0 0+ 0+ 117 Digest-Auth-Param
0-1 0 0 0 0 118 Digest-AKA-Auts
0 0 0 0+ 0+ 119 Digest-Domain
0 0 0 0-1 0 120 Digest-Stale
0 0-1 0 0 0 121 Digest-HA1
0-1 0 0 0 0 122 SIP-AOR

The following table defines the meaning of the above table entries.

0 This attribute MUST NOT be present in the packet.
0+ Zero or more instances of this attribute MAY be
present in the packet.
0-1 Zero or one instance of this attribute MAY be
present in the packet.

Digest-HA1 MUST be used instead of Digest-Response-Auth if
Digest-Qop is 'auth-int'.

Digest-Response-Auth MUST be used instead of Digest-HA1 if
Digest-Qop is 'auth'.

If Digest-Algorithm is missing, 'MD5' is assumed.

An Access-Challenge MUST contain a State attribute, which is
copied to the subsequent Access-Request. A server receiving
an Access-Request that contains a State attribute MUST
respond with either an Access-Accept or an Access-Reject;
the server MUST NOT respond with an Access-Challenge.6. ExamplesThis is an example selected from the traffic between a softphone (A),
a Proxy Server (B), and an example.com RADIUS server (C). The
communication between the Proxy Server and a SIP Public Switched
Telephone Network (PSTN) gateway is omitted for brevity. The SIP
messages are not shown completely.

The password of user '12345678' is 'secret'. The shared secret
between the RADIUS client and server is 'secret'. To ease testing,
only the last byte of the RADIUS authenticator changes between
requests. In a real implementation, this would be a serious flaw.

A->B

INVITE sip:[email protected] SIP/2.0
From: <sip:[email protected]>
To: <sip:[email protected]>

B->A

SIP/2.0 100 Trying

B->C

Code = Access-Request (1)
Packet identifier = 0x7c (124)
Length = 97
Authenticator = F5E55840E324AA49D216D9DBD069807C
NAS-IP-Address = 192.0.2.38
NAS-Port = 5
User-Name = 12345678
Digest-Method = INVITE
Digest-URI = sip:[email protected]
Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B

C->B

Code = Access-challenge (11)
Packet identifier = 0x7c (124)
Length = 72
Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D
Digest-Nonce = 3bada1a0
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3B->A

SIP/2.0 407 Proxy Authentication Required
Proxy-Authenticate: Digest realm="example.com"
,nonce="3bada1a0",qop=auth,algorithm=MD5
Content-Length: 0

A->B

ACK sip:[email protected] SIP/2.0

A->B

INVITE sip:[email protected] SIP/2.0
Proxy-Authorization: Digest nonce="3bada1a0"
,realm="example.com"
,response="756933f735fcd93f90a4bbdd5467f263"
,uri="sip:[email protected]",username="12345678"
,qop=auth,algorithm=MD5
,cnonce="56593a80,nc="00000001"

From: <sip:[email protected]>
To: <sip:[email protected]>

B->C

Code = Access-Request (1)
Packet identifier = 0x7d (125)
Length = 221
Authenticator = F5E55840E324AA49D216D9DBD069807D
NAS-IP-Address = 192.0.2.38
NAS-Port = 5
User-Name = 12345678
Digest-Method = INVITE
Digest-URI = sip:[email protected]
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Digest-CNonce = 56593a80
Digest-Nonce = 3bada1a0
Digest-Nonce-Count = 00000001
Digest-Response = 756933f735fcd93f90a4bbdd5467f263
Digest-Username = 12345678
SIP-AOR = sip:[email protected]
Message-Authenticator = B6C7F7F8D11EF261A26933D234561A60C->B

Code = Access-Accept (2)
Packet identifier = 0x7d (125)
Length = 72
Authenticator = FFDD74D6470D21CB6FC4D6056BE245D2
Digest-Response-Auth = f847de948d12285f8f4199e366f1af21
Message-Authenticator = 7B76E2F10A7067AF601938BF13B0A62E

B->A

SIP/2.0 180 Ringing

B->A

SIP/2.0 200 OK

A->B

ACK sip:[email protected] SIP/2.0

A second example shows the traffic between a web browser (A), a web
server (B), and a RADIUS server (C).

A->B

GET /index.html HTTP/1.1

B->C

Code = Access-Request (1)
Packet identifier = 0x7e (126)
Length = 68
Authenticator = F5E55840E324AA49D216D9DBD069807E
NAS-IP-Address = 192.0.2.38
NAS-Port = 5
Digest-Method = GET
Digest-URI = /index.html
Message-Authenticator = 690BFC95E88DF3B185F15CD78E469992C->B

Code = Access-challenge (11)
Packet identifier = 0x7e (126)
Length = 72
Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E
Digest-Nonce = a3086ac8
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A

B->A

HTTP/1.1 401 Authentication Required
WWW-Authenticate: Digest realm="example.com",
nonce="a3086ac8",qop=auth,algorithm=MD5
Content-Length: 0

A->B

GET /index.html HTTP/1.1
Authorization: Digest = algorithm=MD5,qop=auth,nonce="a3086ac8"
,nc="00000001",cnonce="56593a80"
,realm="example.com"
,response="a4fac45c27a30f4f244c54a2e99fa117"
,uri="/index.html",username="12345678"

B->C

Code = Access-Request (1)
Packet identifier = 0x7f (127)
Length = 176
Authenticator = F5E55840E324AA49D216D9DBD069807F
NAS-IP-Address = 192.0.2.38
NAS-Port = 5
User-Name = 12345678
Digest-Method = GET
Digest-URI = /index.html
Digest-Realm = example.com
Digest-Qop = auth
Digest-Algorithm = MD5
Digest-CNonce = 56593a80
Digest-Nonce = a3086ac8
Digest-Nonce-Count = 00000001
Digest-Response = a4fac45c27a30f4f244c54a2e99fa117
Digest-Username = 12345678
Message-Authenticator = 237D85C1478C70C67EEAF22A9C456821C->B

Code = Access-Accept (2)
Packet identifier = 0x7f (127)
Length = 72
Authenticator = 6364FA6ED66012847C05A0895607C694
Digest-Response-Auth = 08c4e942d1d0a191de8b3aa98cd35147
Message-Authenticator = 43795A3166492AD2A890AD57D5F97D56

B->A

HTTP/1.1 200 OK
...

<html>
...7. IANA ConsiderationsThe following values from the RADIUS Attribute Types number space
were assigned in . This document requests that the values
in the table below be entered within the existing registry.

Attribute #
--------------- ----
Digest-Response 103
Digest-Realm 104
Digest-Nonce 105
Digest-Response-Auth 106
Digest-Nextnonce 107
Digest-Method 108
Digest-URI 109
Digest-Qop 110
Digest-Algorithm 111
Digest-Entity-Body-Hash 112
Digest-CNonce 113
Digest-Nonce-Count 114
Digest-Username 115
Digest-Opaque 116
Digest-Auth-Param 117
Digest-AKA-Auts 118
Digest-Domain 119
Digest-Stale 120
Digest-HA1 121
SIP-AOR 1228. Security ConsiderationsThe RADIUS extensions described in this document enable RADIUS to
transport the data that is required to perform a digest calculation.
As a result, RADIUS inherits the vulnerabilities of HTTP Digest (see) in addition to RADIUS security vulnerabilities
described in, and.

An attacker compromising a RADIUS client or proxy can carry out man-
in-the-middle attacks even if the paths between A, B and B, C (Figure
2) have been secured with TLS or IPsec.

The RADIUS server MUST check the Digest-Realm Attribute it has
received from a client. If the RADIUS client is not authorized to
serve HTTP-style clients of that realm, it might be compromised.

Diameter reserves AVP Code space 1-255 as RADIUS attribute
compatibility space. The MIP6-Feature-Vector attribute (Type value
124) defined in is of type OctetString and contains a
64-bit flags field of supported mobility capabilities. This document
reserves two new capability bits according to the rules in ,
and reuses the PMIPv6 capability bits defined by . The
following capability flag bits are used or defined in this document:

PMIP6_SUPPORTED (0x0000010000000000)

This capability bit is used as defined in .

IP4_HOA_SUPPORTED (0x0000020000000000)

This capability bit is used as defined in . Assignment
of the IPv4-HoA (Home Address) is defined by .LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000)

This capability bit is used as defined in .

IP4_TRANSPORT_SUPPORTED (0x0000800000000000)

This capability bit is used for negotiation of the IPv4 transport
support between the MAG and AAA. When the MAG sets this flag bit
in the MIP6-Feature-Vector, it indicates the ability of the MAG to
provide IPv4 transport (i.e., IPv4-based encapsulation) for
carrying IP traffic between the MAG and the LMA. If this flag bit
is unset in the returned MIP6-Feature-Vector attribute, the AAA
does not authorize the use of IPv4 transport on the MAG-to-LMA
tunnel.

IP4_HOA_ONLY_SUPPORTED (0x0001000000000000)

This capability bit is used for determination of the authorized
PMIPv6 mobility mode. When this bit is set by the AAA, it
indicates PMIPv6 mobility with IPv4 support has only been
authorized for the MN. As a result, the RADIUS Access-Accept
SHOULD NOT carry the IPv6 Home Network Prefix (IPv6 HNP). When
this bit is set, the PMIP6_SUPPORTED flag MUST also be set and the
IP4_HOA_SUPPORTED flag MUST NOT be set.

To summarize the use of the MIP6-Feature-Vector the following
capability bit combination settings mean:

PMIP6-SUPPORTED bit set - only IPv6 mobility is supported and
authorized.

PMIP6-SUPPORTED and IP4-ONLY-HOA-SUPPORTED bits set - only IPv4
mobility is supported and authorized.

PMIP6-SUPPORTED and IP4-HOA-SUPPORTED bits set - both IPv6 and
IPv4 mobility are supported and authorized.

The MIP6-Feature-Vector attribute is also used on the LMA to the
RADIUS AAA interface. This capability announcement attribute enables
direct capability negotiation between the LMA and the AAA. The
capabilities that are announced by both parties in the MIP6-Feature-
Vector are known to be mutually supported. The LMA may use this
mechanism during authorization of the received PBU against the AAA to
check individual PMIPv6 feature permissions for a particular MN.

If the RADIUS Access-Accept contains a contradicting combination of
the capability flag bits such as both the IP4_HOA_ONLY_SUPPORTED and
the IP4_HOA_SUPPORTED flags being set, then the RADIUS client MUSTtreat the Access-Accept as an Access-Reject and SHOULD log the event.
Similarly, if the RADIUS Access-Request contains a contradicting
combination of the capability flag bits, then the RADIUS server MUST
reply with an Access-Reject message and SHOULD log the event.

The PKM-SS-Cert Attribute is variable length and MAY be
transmitted in the Access-Request message. The Value field is of
type string and contains the X.509 certificate binding a
public key to the identifier of the Subscriber Station.

The minimum size of an SS certificate exceeds the maximum size of
a RADIUS attribute. Therefore, the client MUST encapsulate the
certificate in the Value fields of two or more instances of the
PKM-SS-Cert Attribute, each (except possibly the last) having a
length of 255 octets. These multiple PKM-SS-Cert Attributes MUST
appear consecutively and in order within the packet. Upon
receipt, the RADIUS server MUST recover the original certificate
by concatenating the Value fields of the received PKM-SS-Cert
Attributes in order.

A summary of the PKM-SS-Cert Attribute format is shown below. The
fields are transmitted from left to right.

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 | Len | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

137 for PKM-SS-Cert

Len

> 2

Value

The Value field is variable length and contains a (possibly
complete) portion of an X.509 certificate.

The PKM-CA-Cert Attribute is variable length and MAY be
transmitted in the Access-Request message. The Value field is of
type string and contains the X.509 certificate used by
the CA to sign the SS certificate carried in the PKM-SS-Cert
attribute () in the same message.

The minimum size of a CA certificate exceeds the maximum size of a
RADIUS attribute. Therefore, the client MUST encapsulate the
certificate in the Value fields of two or more instances of the
PKM-CA-Cert Attribute, each (except possibly the last) having a
length of 255 octets. These multiple PKM-CA-Cert Attributes MUST
appear consecutively and in order within the packet. Upon
receipt, the RADIUS server MUST recover the original certificate
by concatenating the Value fields of the received PKM-CA-Cert
Attributes in order.

A summary of the PKM-CA-Cert Attribute format is shown below. The
fields are transmitted from left to right.

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 | Len | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

138 for PKM-CA-Cert

Len

> 2

Value

The Value field is variable length and contains a (possibly
complete) portion of an X.509 certificate.

The PKM-Config-Settings Attribute is of type string . It
is 30 octets in length and consists of seven independent fields,
each of which is conceptually an unsigned integer. Each of the
fields contains a timeout value and corresponds to a Type-Length-
Value (TLV) tuple encapsulated in the IEEE 802.16 "PKM
configuration settings" attribute; for details on the contents of
each field, see Section 11.9.19 of . One
instance of the PKM-Config-Settings Attribute MAY be included in
the Access-Accept message.

A summary of the PKM-Config-Settings Attribute format is shown below.
The fields are transmitted from left to right.

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 | Len | Auth Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Wait Timeout (cont.) | Reauth Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reauth Wait Timeout (cont.) | Auth Grace Time
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Grace Time (cont.) | Op Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Op Wait Timeout (cont.) | Rekey Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rekey Wait Timeout (cont.) | TEK Grace Time
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TEK Grace Time (cont.) | Auth Rej Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Rej Wait Timeout (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

139 for PKM-Config-Settings

Len

30Auth Wait Timeout

The Auth Wait Timeout field is 4 octets in length and corresponds
to the "Authorize wait timeout" field of the 802.16 "PKM
configuration settings" attribute.

Reauth Wait Timeout

The Reauth Wait Timeout field is 4 octets in length and
corresponds to the "Reauthorize wait timeout" field of the 802.16
"PKM configuration settings" attribute.

Auth Grace Time

The Auth Grace Time field is 4 octets in length and corresponds to
the "Authorize grace time" field of the 802.16 "PKM configuration
settings" attribute.

Op Wait Timeout

The Op Wait Timeout field is 4 octets in length and corresponds to
the "Operational wait timeout" field of the 802.16 "PKM
configuration settings" attribute.

Rekey Wait Timeout

The Rekey Wait Timeout field is 4 octets in length and corresponds
to the "Rekey wait timeout" field of the 802.16 "PKM configuration
settings" attribute.

TEK Grace Time

The TEK Grace Time field is 4 octets in length and corresponds to
the "TEK grace time" field of the 802.16 "PKM configuration
settings" attribute.

Auth Rej Wait Timeout

The Auth Rej Wait Timeout field is 4 octets in length and
corresponds to the "Authorize reject wait timeout" field of the
802.16 "PKM configuration settings" attribute.

The PKM-Cryptosuite-List Attribute is of type string and
is variable length; it corresponds roughly to the "Cryptographic-
Suite-List" 802.16 attribute (see Section 11.19.15 of
), the difference being that the RADIUS
Attribute contains only the list of 3-octet cryptographic suite
identifiers, omitting the IEEE Type and Length fields.

The PKM-Cryptosuite-List Attribute MAY be present in an Access-
Request message. Any message in which the PKM-Cryptosuite-List
Attribute is present MUST also contain an instance of the Message-
Authenticator Attribute .

Implementation Note

The PKM-Cryptosuite-List Attribute is used as a building block
to create the 802.16 "Security-Capabilities" attribute
(, Section 11.9.13); since this document only
pertains to PKM version 1, the "Version" sub-attribute in that
structure MUST be set to 0x01 when the RADIUS client constructs
it.

A summary of the PKM-Cryptosuite-List Attribute format is shown
below. The fields are transmitted from left to right.

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 | Len | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

140 for PKM-Cryptosuite-List

Len

2 + 3n < 39, where 'n' is the number of cryptosuite identifiers in
the list.Value

The Value field is variable length and contains a sequence of one
or more cryptosuite identifiers, each of which is 3 octets in
length and corresponds to the Value field of an IEEE 802.16
Cryptographic-Suite attribute.

The PKM-SAID Attribute is of type string . It is 4
octets in length and contains a PKM Security Association
Identifier (, Section 11.9.7). It MAY be
included in an Access-Request message.

A summary of the PKM-SAID Attribute format is shown below. The
fields are transmitted from left to right.

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 | Len | SAID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

141 for PKM-SAID

Len

4

SAID

The SAID field is two octets in length and corresponds to the
Value field of the 802.16 PKM SAID attribute

The PKM-SA-Descriptor Attribute is of type string and is 8 octets
in length. It contains three fields, described below, which
together specify the characteristics of a PKM security
association. One or more instances of the PKM-SA-Descriptor
Attribute MAY occur in an Access-Accept message.A summary of the PKM-SA-Descriptor Attribute format is shown below.
The fields are transmitted from left to right.

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 | Len | SAID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA Type | Cryptosuite |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

142 for PKM-SA-Descriptor

Len

8

SAID

The SAID field is two octets in length and contains a PKM SAID
().

SA Type

The SA Type field is one octet in length. The contents correspond
to those of the Value field of an IEEE 802.16 SA-Type attribute.

Cryptosuite

The Cryptosuite field is 3 octets in length. The contents
correspond to those of the Value field of an IEEE 802.16
Cryptographic-Suite attribute.

The Mobile-Node-Identifier attribute (Type value 145) is of type
String and contains the mobile node identifier (MN-Identifier), see
, in a form of a Network Access Identifier (NAI) .
This identifier and the identifier used for access authentication may
be different; however, there needs to be a mapping between the two
identities as specified in. This attribute
is used on the interface between the MAG and the AAA server. The
Mobile-Node-Identifier attribute is designed for deployments where
the identity used during network access authentication and the
identity used for mobility management is decoupled. It may also be
the case where the MAG does not have means to find out the MN
identity that could be used in subsequent PBU and Proxy Binding
Acknowledgement (PBA) exchanges (e.g., due to identity hiding during
the network access authentication) or when the HAAA wants to assign
periodically changing identities to the MN.

The Mobile-Node-Identifier attribute MAY be returned by the HAAA in
the RADIUS Access-Accept message that completes a successful
authentication and authorization exchange between the MAG and the
HAAA. The MAG MUST use the received MN-Identifier.

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 | Mobile Node Identifier... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
Mobile-Node-Identifier 145.

Length:
In octets, including Type and Length fields (>= 3).

Mobile Node Identifier:
This field is of type String and contains the MN-Identifier
of the MN to be used in the PBU/PBA exchange.

The Service-Selection attribute (Type value 146) is of type UTF-8
text and contains the name of the service or the external network
with which the mobility service for the particular MN SHOULD be
associated . The identifier MUST be unique within the
PMIPv6 Domain when normalized using the selected normalization form
for the particular PMIPv6 Domain deployment. For instance,
uses the Normalization Form KC (NFKC).

The MAG MUST include the Service-Selection attribute in the Access-
Request sent to the AAA if the information was acquired, e.g., by
operator-specific configuration. The AAA MAY include the Service-
Selection attribute in the Access-Accept response message to the MAG
even if it was not included in the Access-Request as a means of
indicating the MN's default service.

The Service Selection mobility option defined in can be
used in PBU/PBA messages between the MAG and LMA. On the LMA-to-AAA
interface, the LMA MAY populate the Service-Selection attribute in
the Access-Request message using the service information found in the
received PBU, if such a mobility option were included. The Service-
Selection identifier should be used to assist the PBU authorization,
the assignment of the MN-HNP, and the IPv4-MN-HoA as described in
and .

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 | Service Identifier... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
Service-Selection 146.

Length:
In octets, including Type and Length fields (>= 3).

Text:
This field is of type UTF-8 text and contains the Service
Identifier with which the MN is associated.

The PMIP6-Home-LMA-IPv6-Address attribute (Type value 147) is of type
IPv6 address and is used to deliver the IPv6 address of the LMA
located in the home network.Before the MAG can initiate Proxy Mobile IPv6 signaling, it must be
aware of the LMA's IP address.

When the LMA is assigned to the MN from the home network, this
attribute MAY be sent by the HAAA to the MAG in the RADIUS Access-
Accept message.

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 | Home LMA IPv6 address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home LMA IPv6 address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home LMA IPv6 address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home LMA IPv6 address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home LMA IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Home-LMA-IPv6-Address 147.

Length:
= 18 octets

Home LMA IPv6 address:
128-bit IPv6 address of the assigned home LMA IPv6 address.

The PMIP6-Visited-LMA-IPv6-Address attribute (Type value 148) is of
type IPv6 address and is used to propose a particular LMA in the
visited network and to authorize the use of the LMA in the visited/
local network.

PMIP6-Visited-LMA-IPv6-Address attribute MAY be included by the MAG
in the RADIUS Access-Request message. The LMA in the visited/local
network may be assigned by the AAA as the result of retrieved
policy profile. If included by the AAA in the RADIUS Access-
Accept sent to the MAG, the use of the LMA in the visited/local
network is authorized and the attribute SHALL carry the IPv6 address
of the LMA assigned for the particular MN. Seehow the MIP6-Feature-Vector attribute and
LOCAL_HOME_AGENT_ASSIGNMENT capability flag is used with the LMA
(Home Agent) assignment.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 | Visited LMA IPv6 address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited LMA IPv6 address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited LMA IPv6 address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited LMA IPv6 address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited LMA IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Visited-LMA-IPv6-Address 148.

Length:
= 18 octets

Visited LMA IPv6 address:
128-bit IPv6 address of the assigned visited LMA IPv6 address.

The PMIP6-Home-LMA-IPv4-Address attribute (Type value 149) is of type
IPv4 address and contains the IPv4 address of the LMA assigned by the
HAAA. The supports Proxy Mobile IPv6 signaling exchange
between MAG and LMA using the IPv4 transport.

When the LMA is located in the home network, this attribute MAY be
sent by the HAAA to the MAG in the RADIUS Access-Accept message.

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 | Home LMA IPv4 address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home LMA IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Home-LMA-IPv4-Address 149.

Length:
= 6 octetsHome LMA IPv4 address:
32-bit IPv4 address of the assigned LMA.

The PMIP6-Visited-LMA-IPv4-Address attribute (Type value 150) is of
type IPv4 address and is used to propose a particular LMA in the
visited network and to authorize the use of the LMA in the visited
network.

PMIP6-Visited-LMA-IPv4-Address attribute MAY be included by the MAG
in the RADIUS Access-Request message. The LMA in the visited/local
network may be assigned by the AAA as the result of retrieved
policy profile. If included by the AAA in the RADIUS Access-
Accept sent to the MAG, the use of the LMA in the visited/local
network is authorized and the attribute SHALL carry the IPv4 address
of the LMA assigned for the particular MN. Seehow the MIP6-Feature-Vector attribute and
LOCAL_HOME_AGENT_ASSIGNMENT capability flag is used with the LMA
(Home Agent) assignment.

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 | Visited LMA IPv4 address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited LMA IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Visited-LMA-IPv4-Address 150.

Length:
= 6 octets

IPv4 LMA address:
32-bit IPv4 address of the assigned LMA.

The PMIP6-Home-HN-Prefix attribute (Type value 151) is of type IPv6
prefix. It contains the Mobile Node - Home Network Prefix (MN-HNP),
which is the IPv6 prefix assigned to the link between the MN and the
MAG. The MN configures its IP interface from its home network
prefix(es). When the LMA is located in the home network, the PMIP6-
Home-HN-Prefix attribute is used to deliver the MN-HNP from the HAAA
to the MAG.The PMIP6-Home-HN-Prefix attribute is also used on the LMA-to-HAAA
interface containing the prefix assigned to the MN. If the LMA
delegates the MN-HNP assignment to the HAAA, the attribute MUST
contain all zeroes in the address of (i.e., '::') the Access-Request
message. The attribute MUST be present in the RADIUS Access-Accept
message if the prior request already included one and SHOULD carry
the MN-HNP the HAAA assigned to the MN.

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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home MN-HNP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home MN-HNP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home MN-HNP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home MN-HNP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Home-HN-Prefix 151.

Length:
= at least 4 and no larger than 20.

Reserved:
Reserved for future use. The bits MUST be set to zero by the
sender and MUST be ignored by the receiver.

Prefix-Length:
The 8-bit unsigned integer indicating the prefix length of
the home network prefix (at least 0 and no larger than 128).
If the home network prefix contains an address of all zeroes
(i.e., '::'), then the Prefix-Length MUST be set to 128.

Home Network Prefix:
The home network prefix for the MN's IPv6 address configuration.
The Prefix field is up to 16 octets in length. Bits outside of
the Prefix-Length, if included, must be zero.

The PMIP6-Visited-HN-Prefix attribute (Type value 152) is of type
IPv6 prefix. It contains the Mobile Node - Home Network Prefix (MN-
HNP), which is the IPv6 prefix assigned to the link between the MNand the MAG. The MN configures its IP interface from its home
network prefix(es). When the LMA is located in the visited network,
the PMIP6-Visited-HN-Prefix attribute is used to deliver the MN-HNP
from the VAAA to the MAG.

The PMIP6-Visited-HN-Prefix attribute is also used on the LMA-to-VAAA
interface containing the IPv6 prefix assigned to the MN. If the LMA
delegates the assignment of the MN-HNP to the VAAA, the attribute
MUST contain an address of all zeroes (i.e., '::') in the RADIUS
Access-Request message. The attribute MUST be present in Access-
Accept message if the prior request already included one and SHOULD
carry the MN-HNP the VAAA assigned to the MN.

The attribute SHOULD NOT be included if the use of LMA in the home
network is authorized (the PMIP6-Home-HN-Prefix and/or PMIP6-Home-
LMA-IPv6-Address attributes are already present). However, if the
VAAA local policy allows both home and visited LMA addresses to be
delivered to the MAG, then this attribute MAY also be included.

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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Visited MN-HNP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited MN-HNP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited MN-HNP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited MN-HNP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Visited-HN-Prefix 152.

Length:
= at least 4 and no larger than 20.

Reserved:
Reserved for future use. The bits MUST be set to zero by the
sender and MUST be ignored by the receiver.

Prefix-Length:
The 8-bit unsigned integer indicating the prefix length of
the Visited MN-HNP (at least 0 and no larger than 128). If
the visited home network prefix contains an address of all zeroes
(i.e., '::'), then the Prefix-Length MUST be set to 128.Visited Home Network Prefix:
The home network prefix for the MN's IPv6 address configuration.
The Prefix field is up to 16 octets in length. Bits outside of
the Prefix-Length, if included, must be zero.

The PMIP6-Home-Interface-ID attribute (Type value 153) is of type
String and contains the MN's interface identifier. The selection of
the interface identifier SHOULD NOT allow the tracking of individual
MNs or users between PMIPv6 mobility sessions for privacy reasons.
This attribute is applicable in network systems and link
technologies, where the network explicitly delivers an interface
identifier to the MN during the link setup. Third Generation
Partnership Project (3GPP) and PPP link technologies are examples of
such.

This attribute MAY be sent by the LMA or the MAG to the HAAA in the
RADIUS Access-Request packet as a proposal. This attribute MAY be
sent by the HAAA to the LMA or to the MAG in an Access-Accept packet;
however, it MUST be present if the prior request already included
one.

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 | Home Interface Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Interface Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Interface Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Home-Interface-ID 153.

Length:
= 10 octets.

Home Interface Identifier:
The 64-bit long interface identifier (8 octets).

The PMIP6-Visited-Interface-ID attribute (Type value 154) is of type
String and contains the MN's interface identifier. The selection of
the interface identifier SHOULD NOT allow the tracking of individual
MNs or users between PMIPv6 mobility session for privacy reasons.This attribute is applicable in network systems and link
technologies, where the network explicitly delivers an interface
identifier to the MN during the link setup. 3GPP and PPP link
technologies are examples of such.

This attribute MAY be sent by the LMA or the MAG to the VAAA in the
RADIUS Access-Request packet as a proposal. This attribute MAY be
sent by the VAAA to the LMA or to the MAG in an Access-Accept packet;
however, it MUST be present if the prior request already included
one.

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 | Visited Interface Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited Interface Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited Interface Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Visited-Interface-ID 154.

Length:
= 10 octets.

Visited Interface Identifier:
The 64-bit long interface identifier (8 octets).

specifies extensions to Proxy Mobile IPv6 protocol that
enable IPv4 home address mobility support to the MN. The PMIP6-Home-
IPv4-HoA attribute (Type value 155) is of type Address and contains
the IPv4 Home Address of the MN. The primary use of this attribute
is to deliver the assigned IPv4-HoA from HAAA to the MAG.

The PMIP6-Home-IPv4-HoA is also used on the LMA-to-HAAA interface.
If the LMA in the home network delegates the assignment of the
IPv4-HoA to the HAAA, the attribute MUST contain an address of all
zeroes (i.e., 0.0.0.0) in the Access-Request message. The attribute
MUST be included in by HAAA in the Access-Accept message if the
previous request included it, and it contains the IPv4-HoA assigned
to the MN.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-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home IPv4 HoA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Home-IPv4-HoA 155.

Length:
= 8 octets

Reserved
The 10-bit field reserved for future use. The value MUST be
initialized to zero by sender and MUST be ignored by the
receiver.

Prefix-Len
The 6-bit unsigned integer indicating the prefix length of the
IPv4 HoA. If the Home IPv4 HoA contains an address of all zeroes
(i.e., '0.0.0.0'), then the Prefix-Len MUST be set to 32.

Home IPv4 HoA:
This field is of type Address and contains the IPv4 home
address of the MN in the home network.

When both the MAG and the LMA are in the visited network, the PMIP6-
Visited-IPv4-HoA attribute (Type value 156) is of type Address and is
used to exchange information between the VAAA and the MAG on the
assignment of the IPv4 Home Address to the MN being present in the
visited network.

The PMIP6-Visited-IPv4-HoA is also used on the LMA-to-VAAA interface.
If the LMA delegates the assignment of the IPv4-HoA to the VAAA, the
attribute MUST contain an address of all zeroes (i.e., 0.0.0.0) in
the RADIUS Access-Request message. The Access-Accept message MUST
have the attribute present if the prior request to the VAAA already
included one.

The attribute SHOULD NOT be included if the use of the LMA in the
home network is authorized (the PMIP6-Home-IPv4-HoA and/or PMIP6-
Home-LMA-IPv4-Address attributes are already present). However, if
the VAAA local policy allows both home and visited LMA addresses to
be delivered to the MAG, then this attribute MAY also be included.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-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Visited IPv4 HoA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Visited-IPv4-HoA 156.

Length:
= 8 octets

Reserved:
The 10-bit field reserved for future use. The value MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.

Prefix-Len:
6-bit unsigned integer indicating the prefix length of the IPv4
HoA. If the Visited IPv4 HoA contains an address of all zeroes
(i.e., '0.0.0.0'), then the Prefix-Len MUST be set to 32.

Visited IPv4 HoA:
This field is of type Address and contains the IPv4 home address
of the MN in the visited network.

The PMIP6-Home-DHCP4-Server-Address (Type value 157) is of type
Address and contains the IPv4 address of the DHCPv4 server in the
home network. The particular DHCP server address is indicated to the
MAG that serves the concerning MN. The HAAA MAY assign a DHCP server
to the MAG in deployments where the MAG acts as a DHCP Relay, as
defined in .

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 | Home DHCPv4 server address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home DHCPv4 server address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Home-DHCP4-Server-Address 157.Length:
= 6 octets.

Home DHCPv4 server address:
This field is of type Address and contains a 4-octet IPv4 address
of the DHCP server.

The PMIP6-Visited-DHCP4-Server-Address attribute (Type value 158) is
of type Address and delivers the IPv4 address of the DHCPv4 server
from the visited network to the MAG. When both the MAG and the LMA
are in the visited network, the VAAA MAY assign a DHCPv4 server to
the MAG in deployments where the MAG acts as a DHCP Relay, as defined
in .

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 | Visited DHCPv4 server address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited DHCPv4 server address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Visited-DHCP4-Server-Address 158.

Length:
= 6 octets

Visited DHCPv4 server address:
This field is of type Address and contains a 4-octet IPv4 address
of the DHCPv4 server.

The PMIP6-Home-DHCP6-Server-Address (Type value 159) is of type IPv6
address and contains the IPv6 address of the DHCPv6 server in the
home network indicated by the HAAA to the MAG that serves the MN.
The HAAA MAY assign a DHCPv6 server to the MAG in deployments where
the MAG acts as a DHCP Relay, as defined in .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 | Home DHCPv6 server address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home DHCPv6 server address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home DHCPv6 server address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home DHCPv6 server address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home DHCPv6 server address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Home-DHCP6-Server-Address 159.

Length:
= 18 octets

Home DHCPv6 server address:
This field is of type Address and contains 16-octet IPv6 address
of the DHCPv6 server.

The PMIP6-Visited-DHCP6-Server-Address attribute (Type value 160) is
of type IPv6 address and contains the IPv6 address of the DHCPv6
server in the visited network indicated by the VAAA to the MAG that
serves the MN. When both MAG and the LMA are located in the visited
network, the VAAA MAY assign a DHCPv6 server to the MAG in
deployments where the MAG acts as a DHCP Relay, as defined in
.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 | Visited DHCPv6 server address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited DHCPv6 server address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited DHCPv6 server address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited DHCPv6 server address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Visited DHCPv6 server address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Visited-DHCP6-Server-Address 160.

Length:
= 18 octets

Visited DHCPv6 server address:
This field is of type Address and contains the 16-octet IPv6
address of the DHCPv6 server.

specifies extensions to Proxy Mobile IPv6 protocol that
enable IPv4 home address mobility support to the MN. The PMIP6-Home-
IPv4-Gateway attribute (Type value 161) is of type Address and
contains the default gateway IPv4 address for the MN. This address
is populated into the PMIPv6 IPv4 Default-Router Address Option
. The address MUST belong to the subnet defined in the
PMIP6-Home-IPv4-HoA attribute.

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 | Home IPv4 default gateway
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Home-IPv4-Gateway 161.

Length:
= 6 octets

Home IPv4 default gateway address:
This field is of type Address and contains a 4-octet IPv4 default
gateway address.

specifies extensions to Proxy Mobile IPv6 protocol that
enable IPv4 home address mobility support to the MN. The PMIP6-
Visited-IPv4-Gateway attribute (Type value 162) is of type Address
and contains the default gateway IPv4 address for the MN. This
address is populated into the PMIPv6 IPv4 Default-Router Address
Option . The address MUST belong to the subnet defined in
the PMIP6-Visited-IPv4-HoA attribute.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 | Visited IPv4 default gateway
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:
PMIP6-Visited-IPv4-Gateway 162.

Length:
= 6 octets

Visited IPv4 default gateway address:
This field is of type Address and contains a 4-octet IPv4 default
gateway address.5. MAG to RADIUS AAA Interface

The Allowed-Called-Station-Id Attribute allows the RADIUS server
to specify the authenticator MAC addresses and/or networks to
which the user is allowed to connect. One or more Allowed-Called-
Station-Id Attributes MAY be included in an Access-Accept, CoA-
Request, or Accounting-Request packet.

The Allowed-Called-Station-Id Attribute can be useful in
situations where pre-authentication is supported (e.g., IEEE
802.11 pre-authentication). In these scenarios, a Called-Station-
Id Attribute typically will not be included within the Access-
Request so that the RADIUS server will not know the network that
the user is attempting to access. The Allowed-Called-Station-Id
enables the RADIUS server to restrict the networks and attachment
points to which the user can subsequently connect.

A summary of the Allowed-Called-Station-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 | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

174

Length

>=3

String

The String field is one or more octets, specifying a Called-
Station-Id that the user MAY connect to; if the Called-Station-Id
that the user connects to does not match one of the Allowed-
Called-Station-Id Attributes, the Network Access Server (NAS) MUST
NOT permit the user to access the network.In the case of IEEE 802, the Allowed-Called-Station-Id Attribute
is used to store the Medium Access Control (MAC) address,
represented as an uppercase ASCII character string in Canonical
format and with octet values separated by a "-", for example,
"00-10-A4-23-19-C0". Where restrictions on both the network and
authenticator MAC address usage are intended, the network name
MUST be appended to the authenticator MAC address, separated from
the MAC address with a ":", for example, "00-10-A4-23-19-C0:AP1".
Where no MAC address restriction is intended, the MAC address
field MUST be omitted, but ":" and the network name field MUST be
included, for example, ":AP1".

Within IEEE 802.11 , the Service Set Identifier
(SSID) constitutes the network name; within IEEE 802.1X
wired networks, the Network-Id Name (NID-Name)
constitutes the network name. Since a NID-Name can be up to 253
octets in length, when used with wired networks,
there may not be sufficient room within the Allowed-Called-
Station-Id Attribute to include both a MAC address and a network
name. However, as the Allowed-Called-Station-Id Attribute is
expected to be used largely in wireless access scenarios, this
restriction is not considered serious.