Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

IPv6 Support

IPv6 is the next step in the evolution of the Internet Protocol, which provides many more unique addresses than the earlier IPv4, which is currently widely in use but has recently been exhausted. IPv6, which has been under development for more than 10 years, provides improvements over IPv4 in addressing, configuration, and security. Although IPv6 is still an evolving standard, many operating system vendors offer production-quality IPv6 implementations for customers interested in using IPv6 networks.

IPv6 and Steel-Belted Radius Carrier

With few exceptions, Steel-Belted Radius Carrier supports IPv6 addressing wherever IPv4 addressing is supported. You can perform configuration, authentication, and accounting of RADIUS IPv6 attributes per RFC 3162, RADIUS and IPv6 and RFC 6911, RADIUS Attributes for IPv6 Access Networks. The Web GUI and the LDAP configuration interface (LCI) support the configuration of RADIUS IPv6 attributes.

Note: Because many third-party libraries and software development kits (SDKs) do not support IPv6, the Steel-Belted Radius Carrier server must support local IPv4 socket connections.

IPv6 Features

Significant changes from IPv4 to IPv6 include the following:

  • Expanded routing and addressing capabilities—IPv6 increases the IP address size from 32 bits to 128 bits. As a consequence, IPv6 supports more levels of addressing hierarchy, provides a much greater number of available addresses, and simplifies auto-configuration of addresses. As a consequence, address conservation techniques such as network address translation, are not necessary.
  • Improved multicast routing—Multicast routing, which existed in IPv4, has been redefined and improved in IPv6. Multicast addresses now include a Scope field that limits the scope of multicasts, improving scalability. A new Anycast address type allows you to send a message to the nearest single member of a multicast group.
  • Header format simplification—The IPv6 packet header format has been designed to be efficient. The IPv6 header has a fixed length of 40 bytes, divided into eight fields.
  • Improved support for extensions and options—IPv6 uses extension headers, which are inserted between the IPv6 header and the transport header and packet payload, to handle special packet processing requirements. Extension headers provide a flexible means to support authentication, encryption, fragmentation, source routing, network management, and other functions. An IPv6 packet can carry any number of extension headers.
  • Improved datagram sizing and fragmentation—The maximum transmission unit (MTU) describes the maximum size of a datagram that can be transmitted over a network without fragmentation. IPv6 increases the minimum MTU from 576 bytes to 1280 bytes, which makes IPv6 packets more efficient and reduces the need for packet fragmentation. Path MTU discovery enables source routers to determine the appropriate packet size for a route.
  • Quality-of-Service (QoS) functions—Packets belonging to a traffic flow that requires special handling, such as real-time video service, can be labeled by the sender. Because traffic in a particular flow can be identified in the IPv6 header, support for QoS can be implemented even when the payload of a packet is encrypted.
  • Improved privacy and security—IPv6 supports extensions for authentication and data integrity to improve security and privacy of network traffic.

IPv6 Addressing

IPv6 addresses are 128 bits in length, which creates a much larger address space than 32-bit IPv4 addresses. IPv6 addresses identify individual interfaces and sets of interfaces. IPv6 addressing architecture is defined in RFC 2373, IP Version 6 Addressing Architecture.

Address Notation

In full form, IPv6 addresses are written as eight 16-bit hexadecimal blocks separated by colons:

FE80:0000:0000:0000:1232:E4BF:FE1A:8324

IPv6 addresses can be interpreted as having two variable-length fields: an IPv6 prefix and an IPv6 interface identifier.

  • The IPv6 prefix varies from 0 to 128 bits in length and forms the routable network number portion of the IPv6 address. The trailing CIDR notation that may appear after human-readable IPv6 addresses (for example, /64) indicates the bit length of the IPv6 prefix.
  • The IPv6 interface identifier consists of the non-prefix portion of the IPv6 address, if any, and identifies the host interface portion of the address, which identifies an IPv6 interface on the local network. The IPv6 interface identifier is typically generated automatically by the host as a function of a unique hardware identifier, such as an Ethernet MAC address. IPv6 hosts can automatically configure interface addresses by combining the IPv6 prefixes obtained from router advertisements with the IPv6 interface IDs that are determined locally.

For example:

IPv6 Prefix: FEC0:0000:0000:0000:0000:0000:0000:0000/64IPv6 Interface ID:0260:08FF:FEFF:FFFFIPv6 Address:FEC0:0000:0000:0000:0260:08FF:FEFF:FFFF

To simplify address notation, IPv6 accepts abbreviations in address notation. For example, leading zeros in a 16-bit block may be omitted:

FE80:0:0:0:0232:E4BF:FE1A:8324

A double colon (:) can replace a series of consecutive zeros within an address:

FE80::232:E4BF:FE1A:8324

Only one double colon can be used to compress an IPv6 address. If more than one double colon was included in an address, networking devices would not know how many zeros to insert for each double colon when expanding a compressed address to its full 128-bit representation.

In networks that support IPv4 and IPv6 nodes, IPv4 addresses can be embedded in the last four bytes of the address. An IPv4 address of 192.168.1.12 can be represented in IPv6 format as ::192.168.1.12, where :: represents a string of zeroes to pad the address to 128 bits.

Address Prefixes

Like IPv4 addresses, IPv6 addresses are composed of a routable network number, known as the IPv6 prefix, and a host identifier, known as the IPv6 interface ID. IPv6 does not support address classes; IPv6 uses Classless Inter-Domain Routing with variable length network numbers, or prefixes, meaning that an IPv6 prefix is specified by supplying a bit length in conjunction with the address.

IPv6 prefixes are written as an IPv6 address, followed by a slash and the bit length of the prefix portion of the address. The prefix can be 0–128 bits in length, but the prefix is always written in terms of a 128-bit address. When writing prefixes, the trailing bits of the address comprising the interface ID are sometimes dropped so that the prefix can be abbreviated. The following prefixes are equivalent, assuming that the interface ID portion of the address may be ignored:

Canonical form: 2001:1c44:820d:eea0:0260:08ff:feff:ffff/64

Abbreviated form: 2001:1c44:820d:eea0::/64

In many cases, the interface ID portion of the address contains relevant information. A hierarchy of prefixes may reflect the assignment and reassignment of blocks of addresses to progressively smaller organizations. For example, in a typical hierarchy, the largest service providers are assigned the largest blocks of addresses and hence the shortest prefixes, called Top Level Aggregator Identifiers (TLA IDs). The large service providers reassign blocks of addresses to smaller service providers by adding a few more bits after the TLA ID; these added bits are known as Next Level Aggregator IDs. The smaller service providers again reassign smaller blocks of addresses to end user organizations by again adding a few more bits after the NLA ID. These added bits are known as Site Level Aggregator IDs. The hierarchy continues in this way until the prefix is exhausted, leaving only the trailing bits that correspond to the non-routable IPv6 interface ID.

Steel-Belted Radius Carrier accepts all equivalent forms of IPv6 prefixes and recognizes them as being equivalent. The following prefixes are related by hierarchy, but only the canonical and abbreviated forms are equivalent:

Canonical form: 2001:1c44:820d:eea0:0260:08ff:feff:ffff/64

Abbreviated form: 2001:1c44:820d:eea0::/64

Site level prefix: 2001:1c44:820d::/48

Next level prefix: 2001:1c44:8200::/40

Top level prefix: 2001:1c00::/24

IPv6 prefixes should always be written out in full and unabbreviated form when wildcards are used, as the abbreviations become ambiguous in the presence of wildcards. The following prefixes are equivalent:

Canonical form: 2001:1c44:820d:eea0:0260:08ff:feff:ffff/64

With wildcards: 2001:1c*:??0d:eea0:*:*:*:*/64

Address Interface IDs

Because the overall size of the IPv6 address is fixed, a longer address prefix means a shorter interface ID. For example, a 48-bit prefix implies an 80-bit interface ID:

Canonical prefix: 2001:1c44:820d:eea0:0260:08ff:0000:0000/48

Abbreviated prefix: 2001:1c44:820d::/48

48-bit interface ID: eea0:0260:08ff:0000:0000

Though the interface ID portion of an IPv6 address can be 0–128 bits in length, the RADIUS standard assumes 64-bit interface IDs. Steel-Belted Radius Carrier uses a convention that all interface IDs are written as a series of four unabbreviated hexadecimal fields regardless of how they are entered:

64-bit interface ID: 0260:08ff:0000:0000

IPv6 interface IDs should always be written out in full and unabbreviated form when wildcards are used, as the abbreviations become ambiguous in the presence of wildcards. The following interface IDs are equivalent:

64-bit interface ID: 0260:08ff:0000:0000

With wildcards: 02??:08ff:*:*

Note: The use of wildcards in IPv6 interface IDs is a Steel-Belted Radius Carrier feature. Wildcards in IPv6 interface IDs are not known to be documented or prohibited by any IPv6 standards at this time.

IPv6 Network Numbers

In very specific cases, such as check list processing, Steel-Belted Radius Carrier recognizes both IPv4 and IPv6 addresses as representing entire ranges of addresses. Steel-Belted Radius Carrier extends the concept of IPv4 network numbers to IPv6 as a means of representing a range of network addresses. Using this concept of network numbers means you cannot specify a valid network address that also happens to be a network number.

Before the adoption of Classless Inter-Domain Routing (CIDR), the IPv4 address space is divided into five address classes, as shown in Table 22.

Table 22: IPv4 Address Classes

Class

Address Range

Description

A

0.0.0.0 – 127.255.255.255

1-bit class, 7-bit network, 24-bit host

B

128.0.0.0 – 191.255.255.255

2-bit class, 14-bit network, 16-bit host

C

192.0.0.0 – 223.255.255.255

3-bit class, 21-bit network, 8-bit host

D

224.0.0.0 – 239.255.255.255

4-bit class, 28-bit multicast group

E

240.0.0.0 – 247.255.255.255

5-bit class, 27-bit reserved

Within an IPv4 address class, each network is identified by a network number that consists of the leading class bits and the network bits that follow. Network numbers are typically written as IP addresses with trailing zero bits; for example, the network number corresponding to the class C address 199.100.10.24 would typically be written as 199.100.10.0.

Each network represents a potential physical interconnection of a maximum number of hosts determined by the number of host bits. Thus, the physical network identified by the network number 199.100.10.0 might connect up to 256 hosts identified by the addresses 199.100.10.0 through 199.100.10.255 inclusive. (In practice, host addresses such as 199.100.10.0 are avoided to prevent confusion between host addresses and network numbers.) Thus, it is reasonable to interpret a network number as the entire range of addresses sharing the same network portion of the address:

Network number: 199.100.10.0

Start of address range: 199.100.10.0

End of address range: 199.100.10.255

As a wildcarded address: 199.100.10.*

To see how the concept of network numbers can be extended to IPv6 addresses, consider that IPv6 addresses can contain embedded IPv4 addresses. The IPv6 address ::ffff:199.100.10.0 can therefore be interpreted as the range ::ffff:199.100.10.0 through ::ffff:199.100.10.255 inclusive.

The IPv6 address space is not divided into classes, because IPv6 was designed with CIDR in mind. Constructing an arbitrary definition of IPv6 network numbers that both resembles IPv4 and scales well across all possible IPv6 addresses is difficult. However, since large portions of the IPv6 address space have not yet been defined and since the RADIUS specification concerns itself only with 64-bit interface IDs, we can consider arbitrarily assigning special meaning to all IPv6 addresses ending in 64 bits of zero. This represents a fraction (1/264) of the IPv6 address space, where the addresses have arbitrarily been assigned special meaning overriding their true meaning. The cases where this arbitrary definition would cause trouble are expected to be extremely rare, and it should be possible to avoid them.

Steel-Belted Radius Carrier artificially defines the concept of IPv6 network numbers as IPv6 addresses ending in 64 bits of zero, where the network number is interpreted as the entire range of IPv6 addresses sharing the same 64-bit prefix as the network number:

Network number: 2001:1c44:820d:eea0:0000:0000:0000:0000

Start of address range: 2001:1c44:820d:eea0:0000:0000:0000:0000

End of address range: 2001:1c44:820d:eea0:ffff:ffff:ffff:ffff

As a wildcarded address: 2001:1c44:820d:eea0:*:*:*:*

IPv6 Support in Steel-Belted Radius Carrier

In general, IPv6 support in Steel-Belted Radius Carrier parallels IPv4 support, both in terms of IPv6 network transport and in terms of RADIUS IPv6 attributes. When IPv6 networking is not supported by an operating system (either because the operating system cannot support IPv6 or because the IPv6 stack for the operating system has not been configured), Steel-Belted Radius Carrier recognizes IPv6 addresses and attributes, but does not use IPv6 transport mechanisms.

Socket interfaces in Steel-Belted Radius Carrier are both IPv4- and IPv6-capable. By default, IPv4 support is enabled and IPv6 support is disabled in Steel-Belted Radius Carrier. You must explicitly enable IPv6 support (by modifying settings in the [IPv6] section of the radius.ini file) before you can use IPv6 networking. Steel-Belted Radius Carrier recognizes IPv6 attributes whether or not IPv6 networking is enabled.

With few exceptions, IPv6 addresses may be configured wherever you can configure IPv4 addresses in configuration files and in the Web GUI.

Similarly, IPv6 RADIUS attributes can be configured wherever IPv4 RADIUS attributes can be configured. All IPv6 attributes are defined in the radius.dct file to allow inclusion in all standards-conforming dictionaries. IPv6 attributes are correctly interpreted and fully validated by the LDAP Configuration Interface (LCI) and Web GUI.

Table 23 presents a summary of IPv6 support in Steel-Belted Radius Carrier.

Table 23: IPv6 Feature Matrix

Feature

Supported?

Comments

Server networking

Yes

IPv6 networking must be explicitly enabled. IPv6 attributes can be processed even if IPv6 networking is not enabled. IPv6 network traffic is limited to the RADIUS authentication/accounting ports (typically 1645, 1646, 1812, and 1813). IPv6 addresses can be configured in the [Interfaces] section of the proxy.ini file. IPv6 link local and site local addressing is deprecated.

Server DNSv6

Yes

DNSv6 must be explicitly enabled. Both IPv6 and IPv4 network connections are supported with remote DNSv6 servers. Only IPv4 network connections are supported with remote DNS servers.

Server logs

Yes

The diagnostic logging and tracing of IPv6 network connections and IPv6 attributes are fully supported. Only RFC 3162 and RFC 6911 attributes have been tested.

LCI networking

Yes

If IPv6 networking is enabled, IPv6 addresses can be configured in the [LDAPAddresses] section of the radius.ini file.

LCI inputs

Partial

In most cases, IPv6 values can be supplied wherever IPv4 inputs can be specified.

Attributes

Yes

Basic IPv6 attributes defined in RFC 3162, and RFC 6911 and listed in radius.dct are supported as native types or as regular text strings, as appropriate. Only RFC 3162 and RFC 6911 attributes have been tested.

Check lists

Partial

IPv6 attributes can appear in check lists, and IPv6 address values can contain network numbers similar to IPv4 address values. IPv6 prefix values and IPv6 interface values cannot be masked or wildcarded. Only RFC 3162 and RFC 6911 attributes have been tested.

Return lists

Yes

IPv6 attributes can appear within return lists, and IPv6 values can be assigned. Only RFC 3162 and RFC 6911 attributes have been tested.

Attribute value pools

Yes

IPv6 attributes can appear in attribute value pools, and IPv6 values can be assigned to implement round-robin return list processing. Only RFC 3162 attributes have been tested.

Attribute filtering

Yes

IPv6 attributes can appear in filter rules, and IPv6 values can be assigned. Only RFC 3162 attributes have been tested.

Service type mapping

Yes

IPv6 attributes can appear in a service type mapping, and IPv6 values can be wildcarded similar to IPv4 values. Reliable string comparison of regular expressions requires all values to be expressed in canonical form. Only RFC 3162 attributes have been tested.

Attribute mapping

Yes

IPv6 attributes can appear in an attribute mapping, and IPv6 values can be wildcarded similar to IPv4 values. Reliable string comparison of regular expressions requires all values to be expressed in canonical form. Only RFC 3162 attributes have been tested.

Class attribute

Partial

The RADIUS Class attribute cannot contain any IPv6 attributes or structured attributes. You can configure IPv6 addresses in the [Hosts] section of the spi.ini file to process class attributes originating from IPv6 network connections.

DHCP

No

The use of IPv6 networking to communicate with any DHCP server is not supported. The allocation of IPv6 addresses obtained from any DHCP server is not supported.

IP address pools

No

The allocation of IPv6 addresses from an SBR-managed IP address pool is supported through the Framed-IPv6-Prefix. For more information on using the managed IPv6 address pools, see SBR Carrier Reference Guide.

However, RFC 3162 provides an attribute, Framed-IPv6-Pool, that allows the NAS to implement an IPv6 address pool.

Networking for authentication

Yes

IPv6 addresses can be configured in the [Addresses] section of the radius.ini file. IPv6 network traffic is limited to the RADIUS authentication/accounting ports (typically 1645, 1646, 1812, and 1813). Proxying to another RADIUS server is not supported. IPv6 link local and site local addressing is deprecated.

Authentication logs

Yes

IPv6 attributes are fully supported. Only RFC 3162 and RFC 6911 attributes have been tested.

Local User authentication

Yes

IPv6 attributes are fully supported. Only RFC 3162 and RFC 6911 attributes have been tested.

Authenticate-Only requests

Yes

IPv6 attributes are fully supported. Only RFC 3162 and RFC 6911 attributes have been tested.

Pass-through authentication

Partial

IPv6 attributes are fully supported. However, because many third-party libraries do not support IPv6, IPv6 networking is not necessarily supported with external services. Only RFC 3162 attributes have been tested. Third-party software may not support IPv6 networking or attributes.

External authentication
(for example, LDAP or SQL)

Partial

IPv6 attributes are fully supported. However, because many third-party libraries do not support IPv6, IPv6 networking is not necessarily supported with external services such as LDAP and SQL. Only RFC 3162 and RFC 6911 attributes have been tested. Third-party software may not support IPv6 networking or attributes.

EAP-TTLS authentication

Yes

IPv6 attributes are fully supported. Only RFC 3162 and RFC 6911 attributes have been tested.

Directed authentication

Yes

IPv6 attributes are fully supported. Only RFC 3162 attributes have been tested.

Networking for accounting

Yes

IPv6 addresses can be configured in the [Addresses] section of the radius.ini file.

Accounting logs

Yes

IPv6 attributes are fully supported. Only RFC 3162 and RFC 6911 attributes have been tested.

External accounting
(for example, SQL)

Partial

IPv6 attributes are fully supported. However, because many third-party libraries do not support IPv6, IPv6 networking is not necessarily supported with external services such as SQL. Only RFC 3162 and RFC 6911 attributes have been tested. Third-party software may not support IPv6 networking or attributes.

Directed accounting

Yes

IPv6 attributes are fully supported. Only RFC 3162 attributes have been tested.

Spooled accounting

Yes

IPv6 attributes are fully supported. Only RFC 3162 attributes have been tested.

Networking for proxy

Yes

IPv6 addresses can be configured in the [Interfaces] section of the proxy.ini file.

Note: This feature cannot be configured using the GUI.

Proxy authentication

Yes

IPv6 attributes are fully supported.

Proxy accounting

Yes

IPv6 attributes are fully supported.

Master SNMP agent

Yes

The use of IPv6 networking to communicate with an IPv6 capable SNMP management station or SNMP subagent is supported.

SNMP subagent

Yes

IPv6 networking, IPv6 trap variables, and IPv6 MIB objects are supported. IPv6 addresses are reported as IPv4 MIB objects possessing the value 255.255.255.255.

Networking for plug-ins

 

Steel-Belted Radius Carrier does not control the networking of back-end servers with its plug-ins. IPv6 networking is generally a hidden detail of third-party back-end server configuration.

Plug-in APIs

Yes

IPv6 features and parameters are exposed in the new plug-in APIs. The older plug-in APIs are deprecated but still functional. You should upgrade to the new plug-in APIs to gain access to IPv6 features.

IPv6 APIs can be invoked even if IPv6 networking is not enabled.

Plug-in attributes

Yes

Basic IPv6 attributes defined in RFC-3162, RFC 6911 and listed in radius.dct are supported as native types or as regular text strings, as appropriate.

Oracle plug-ins

Yes

IPv6 attributes are fully supported, but the required third-party software may not support IPv6 connectivity.

LDAP plug-in

Yes

IPv6 attributes are fully supported, but the required third-party software may not support IPv6 connectivity.

PEAP plug-in

Yes

IPv6 attributes are fully supported, but the required third party software may not support IPv6 connectivity.

TLS plug-in

Yes

IPv6 attributes are fully supported, but the required third-party software may not support IPv6 connectivity.

TTLS plug-in

Yes

IPv6 attributes are fully supported, but the required third-party software may not support IPv6 connectivity.

JDBC plug-in

Partial

(Linux only) IPv6 attributes are fully supported, but the required third-party software may not support IPv6 connectivity.

RADIUS IPv6 Attributes

All RADIUS attributes defined in RFC 3162, RADIUS and IPv6 and RFC 6911, RADIUS Attributes for IPv6 Access Networks, are supported in Steel-Belted Radius Carrier as native types or as regular text strings. All forms of attribute processing, such check list processing, return list processing, attribute echoing/deleting/merging, are supported. However, IPv6 prefix values and IPv6 interface values cannot be masked or wildcarded in check list processing.

Third-party plug-ins that have not been upgraded to support IPv6 should be able to process IPv6 attributes as opaque hexadecimal strings.

Table 24 lists the attribute number, and the number of times an attribute can appear in an Access-Request, Access-Accept, Access-Reject, Access-Challenge, and Accounting-Request packets for each type of IPv6 RADIUS attribute.

Table 24: IPv6-Specific RADIUS Attributes

Attribute

Attr Num

Acc-Req

Acc-
Accept

Acc-
Rej

Acc-
Chall

Acct- Req

NAS-IPv6-Address

95

0-1

0

0

0

0-1

Framed-Interface-Id

96

0-1

0-1

0

0

0-1

Framed-IPv6-Prefix

97

0+

0+

0

0

0+

Login-IPv6-Host

98

0+

0+

0

0

0+

Framed-IPv6-Route

99

0

0+

0

0

0+

Framed-IPv6-Pool

100

0

0-1

0

0

0-1

Framed-IPv6-Address

168

0+

0+

0

0

0+

DNS-Server-IPv6-Address

169

0+

0+

0

0

0+

Route-IPv6-Information

170

0+

0+

0

0

0+

Delegated-IPv6-Prefix-Pool

171

0+

0+

0

0

0+

Stateful-IPv6-Address-Pool

172

0+

0+

0

0

0+

NAS-IPv6-Address

The NAS-IPv6-Address attribute is similar in function to the NAS-IP-Address attribute. Either attribute is sufficient to identify the IP address of the requesting NAS to the RADIUS server. If both attributes appear in the same RADIUS Access-Request packet, Steel-Belted Radius Carrier processes the NAS-IPv6-Address attribute for the purpose of identifying the NAS.

The NAS-IPv6-Address attribute may be specified by the NAS in access and accounting request packets. Zero or one NAS-IPv6-Address attributes may be specified. If present, the fixed length NAS-IPv6-Address attribute contains the complete 128-bit IPv6 address of the requesting NAS.

Steel-Belted Radius Carrier allows zero or one 128-bit IPv6 address to be specified for each NAS. The server authentication logic validates these addresses on extraction from the database and compares them with NAS-IPv6-Address attributes when they are received in access and accounting request packets. The server accounting logic writes these addresses to the accounting logs in a human readable format.

Example

Human readable:fe80::260:8ff:feff:ffffRADIUS attribute:5f 12 fe 80 00 00 00 00 00 00 02 60 08 ff fe ff ff ff

Framed-Interface-Id

The Framed-Interface-Id attribute specifies the IPv6 interface ID to be assigned to a user. When combined with a Framed-IPv6-Prefix attribute, a single Framed-Interface-Id attribute forms one or more complete IPv6 addresses to be assigned to the user.

In general, the user is assigned the number of addresses equal to the number of Framed-IPv6-Prefix attributes, where the addresses have the same Framed-Interface-Id value and different Framed-IPv6-Prefix values.

It is possible to assign complete IPv6 addresses using only Framed-IPv6-Prefix attributes (for example, without specifying any Framed-Interface-Id attribute). For example, in the case of PPP, it can be quite difficult to automatically generate a unique IPv6 interface ID for a given network segment, so we recommend that the RADIUS server honor the hint if this attribute is suggested by the NAS. This is typically accomplished with echo attributes.

The Framed-Interface-Id attribute may be specified by the NAS in Access- and Accounting-Request packets, and by the RADIUS server in Access-Accept packets. Zero or one Frame-Interface-Id attributes may be specified. If present, the fixed length Framed-Interface-Id attribute contains the 64-bit interface ID to be assigned to the user.

Steel-Belted Radius Carrier allows zero or one 64-bit interface ID to be specified for each local user. The server authentication logic validates this interface ID on extraction from the database and includes the Framed-Interface-Id attribute in Access-Accept packets if none is received in the Access-Request packets.

Example

Human readable:260:8ff:feff:ffffRADIUS attribute:60 0a 02 60 08 ff fe ff ff ff

Framed-IPv6-Prefix

The Framed-IPv6-Prefix attribute specifies the IPv6 networks to be assigned to a user. When combined with a Framed-Interface-ID attribute, a single Framed-IPv6-Prefix attribute forms one or more complete IPv6 addresses to be assigned to the user.

In general, the user is assigned the number of addresses equal to the number of Framed-IPv6-Prefix attributes, where the addresses have the same Framed-Interface-Id value, but different Framed-IPv6-Prefix values.

It is possible to assign complete IPv6 addresses using only Framed-IPv6 Prefix attributes (that is, without specifying any Framed-Interface-Id attribute). For example, the Framed-IPv6-Prefix attributes may be suggested by the NAS and overridden by the RADIUS server. In any case, the NAS is expected to be able to plumb the routes implied by the Framed-IPv6-Prefix attributes and these routes need not be repeated in separate Framed-IPv6-Route attributes.

The Framed-IPv6-Prefix attribute may be specified by the NAS in Access- and Accounting-Request packets, and by the RADIUS server in Access-Accept packets. Zero or more Framed-IPv6-Prefix attributes may be specified. If present, the variable-length Framed-IPv6-Prefix attribute contains an IPv6 prefix from 0 to 128 bits in length. Extra bits beyond the actual prefix length must be set to 0.

Steel-Belted Radius Carrier allows zero or more variable-length IPv6 prefixes to be specified for each local user or attribute profile. The server authentication logic validates these prefixes on extraction from the database and includes the proper number of Framed-IPv6-Prefix attributes in Access-Accept packets if none are received in the access request packets. The server accounting logic writes these prefixes to the accounting logs in a human readable format.

Example

Human readable:fe80::260:8ff:feff:ffff/10RADIUS attribute:61 14 00 0a fe 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00(8-bit type) (8-bit length)(8-bit zero) (8-bit prefix length) (128-bit IPv6 prefix)

Login-IPv6-Host

The Login-IPv6-Host attributes specify the IPv6 addresses of the systems with which the user is connected when the Login-Service attribute is also included. The Login-IPv6-Host attribute may be suggested by the NAS and overridden by the RADIUS server.

The Login-IPv6-Host attribute may be specified by the NAS in access and accounting request packets, and by the RADIUS server in Access-Accept packets. Zero or more Login-IPv6-Host attributes may be specified. If present, the fixed length Login-IPv6-Host attribute contains the complete 128-bit IPv6 address of the login host, or a special value:

  • 128-bits set to 0 indicates that the NAS should select the login host for the user.
  • 128-bits set to 1 indicates that the NAS should allow the user to select the login host.
  • Other values indicate the actual 128-bit IPv6 address of the login host.

Steel-Belted Radius Carrier allows zero or more 128-bit IPv6 addresses (including special values) to be specified for each local user or attribute profile. The server authentication logic validates these addresses (including special values) on extraction from the database and includes the proper number of Login-IPv6-Host attributes in Access-Accept packets if none are received in the access request packets. The server accounting logic writes these addresses to the accounting logs in a human readable format.

Example

Human readable:fe80::260:8ff:feff:ffffRADIUS attribute:62 12 fe 80 00 00 00 00 00 00 02 60 08 ff fe ff ff ff

Framed-IPv6-Pool

The Framed-IPv6-Pool attribute specifies the name of a NAS managed pool (as opposed to a RADIUS server managed pool) from which the NAS should assign an IPv6 prefix to the user. The Framed-IPv6-Pool attribute may not be suggested by the NAS and is always determined by the RADIUS server.

The Framed-IPv6-Pool attribute may be specified by the NAS in Accounting-Request packets, and by the RADIUS server in Access-Accept packets. Zero or one Framed-IPv6-Pool attributes may be specified. If present, the variable-length Framed-IPv6-Pool attribute contains the name of a NAS managed pool in human readable text. The text is not NULL terminated.

Steel-Belted Radius Carrier allows zero or one variable length pool name to be specified for each local user. The server authentication logic validates the pool name on extraction from the database and includes the proper number of Framed-IPv6-Pool attributes in Access-Accept packets. The server accounting logic writes these pool names to the accounting logs in a human readable format.

Example

Human readable:ipv6-poolRADIUS attribute:64 0b 69 70 76 36 2d 70 6f 6f 6c

Framed-IPv6-Route

The Framed-IPv6-Route attribute specifies the IPv6 routing information to be configured for the user on the NAS. The NAS is expected to be able to plumb the routes specified by the Framed-IPv6-Route attributes in addition to those that may already be implied by separate Framed-IPv6-Prefix attributes. The Framed-IPv6-Route attribute may not be suggested by the NAS and is always determined by the RADIUS server.

The Framed-IPv6-Route attribute may be specified by the NAS in accounting request packets, and by the RADIUS server in Access-Accept packets. Zero or more Framed-IPv6-Route attributes may be specified. If present, the variable-length Framed-IPv6-Route attribute contains IPv6 routing information in human readable text. The text is not NULL terminated. The format of the text (destination prefix, gateway address, metrics) is described in RFC-3162.

Steel-Belted Radius Carrier allows zero or more variable-length IPv6 routes to be specified for each local user or attribute profile. The server authentication logic validates these routes on extraction from the database and includes the proper number of Framed-IPv6-Route attributes in Access-Accept packets. The server accounting logic writes these routes to the accounting logs in a human readable format.

Example

Human readable:2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1RADIUS attribute:63 32 32 30 30 30 3a 30 3a 30 ... 39 3a 61 39 39 38 20 31

Framed-IPv6-Address

The Framed-IPv6-Address attribute is a single-value attribute indicating the IPv6 address of the user. The Framed-IPv6-Address attribute may be specified by the NAS in Access-Request and Accounting-Request packets, and by the RADIUS server in Access-Accept packets. This attribute may be used in an Access-Request packet as a hint by the NAS to the RADIUS server that it would prefer this IPv6 address, but the RADIUS server is not required to honor the hint.

SBR Carrier allows zero or one 128-bit IPv6 address to be specified for each user on the NAS. The server authentication logic validates these addresses on extraction from the database and compares them with the Framed-IPv6-Address attributes when they are received in access and accounting request packets. The server accounting logic writes these addresses to the accounting logs in a human readable format. The sessions are created with a single instance of the Framed-IPv6-Address.

The length of the Framed-IPv6-Address attribute must be 18 bytes.

Note: You cannot define multiple instances of Framed-IPv6-Address attributes in a return list. The Framed-IPv6-Address attribute can appear only once in a return list.

Example

Human readable: fe80::260:8ff:feff:ffffRADIUS attribute: 5f 12 fe 80 00 00 00 00 00 00 02 60 08 ff fe ff ff ff(8-bit type) (8-bit length) (128-bit IPv6 address)

DNS-Server-IPv6-Address

The DNS-Server-IPv6-Address attribute contains the IPv6 address of a DNS server. This attribute may be included multiple times in Access-Accept packets through the return list when the intention is for a NAS to announce more than one DNS server address to an RG/host. The DNS-Server-IPv6-Address attribute may be used in an Access-Request packet as a hint by the NAS to the RADIUS server regarding the DNS IPv6 address, but the RADIUS server is not required to honor the hint. The format of the Address field is the same as that of the corresponding field in the NAS-IPv6-Address attribute.

The length of the DNS-Server-IPv6-Address attribute must be 18 bytes.

Example

Human readable: 2007::1RADIUS attribute: 20 07 00 00 00 00 00 00 00 00 00 00 00 00 00 01 (8-bit type) (8-bit length) (128-bit IPv6 address)

Route-IPv6-Information

The Route-IPv6-Information attribute specifies a prefix for the user on the NAS, which is announced using the Route Information option. This attribute is used in the Access-Accept packet and can appear multiple times. The Route-IPv6-Information attribute may be used in an Access-Request packet as a hint by the NAS to the RADIUS server, but the RADIUS server is not required to honor the hint.

The length of the Route-IPv6-Information attribute ranges from 4 bytes through 20 bytes.

Example

Human readable: 2006::1/64RADIUS attribute: 00 40 20 06 00 00 00 00 00 00 00 00 00 00 00 00 00 01

Delegated-IPv6-Prefix-Pool

The Delegated-IPv6-Prefix-Pool attribute contains the name of an assigned pool that should be used to select an IPv6 delegated prefix for the user on the NAS. If a NAS does not support prefix pools, the NAS must ignore this attribute. This attribute may be used in an Access-Request packet as a hint by the NAS to the RADIUS server regarding the pool, but the RADIUS server is not required to honor the hint.

The length of the Delegated-IPv6-Prefix-Pool attribute ranges from 3 bytes through 255 bytes.

Example

Human readable: IPv6_Prefix_POOL_2RADIUS attribute: 49 50 76 36 5f 50 72 65 66 69 78 5f 50 4f 4f 4c 5f 32

Stateful-IPv6-Address-Pool

The Stateful-IPv6-Address-Pool attribute contains the name of an assigned pool that should be used to select an IPv6 address for the user on the NAS. If a NAS does not support address pools, the NAS must ignore this attribute. The Stateful-IPv6-Address-Pool attribute may be used in an Access-Request packet as a hint by the NAS to the RADIUS server regarding the pool, but the RADIUS server is not required to honor the hint.

The length of the Stateful-IPv6-Address-Pool attribute ranges from 3 bytes through 255 bytes.

Example

Human readable: IPv6_POOL_1RADIUS attribute: 49 50 76 36 5f 50 4f 4f 4c 5f 31

Enabling IPv6 Networking

To enable IPv6 networking in Steel-Belted Radius Carrier, you must modify the radius.ini file and then restart your Steel-Belted Radius Carrier server. For information about the settings in the radius.ini file, refer to the SBR Carrier Reference Guide.

Steel-Belted Radius Carrier can process IPv6 attributes even if IPv6 networking is not enabled, provided that the IPv6 attributes are described in the RADIUS dictionary files.

Configuring IPv6 Scope IDs

Some types of IPv6 addresses require an IPv6 scope ID to avoid address ambiguity. In some cases, the Steel-Belted Radius Carrier server can select a scope ID automatically. You can specify the scope ID explicitly for IPv6 link local and site local addresses.

The [IPv6] section of the radius.ini file can specify how scope IDs are selected for each IPv6 address type that is recognized by the server. If the parameter value is 0, the Steel-Belted Radius Carrier server selects a scope ID automatically. If the parameter value is not 0, then the Steel-Belted Radius Carrier server uses that value as the scope ID when establishing network connections involving that IPv6 address type.

Note: You can use the output of the ifconfig -a shell command on Solaris platforms to determine the proper host specific scope ID for an address type. The scope ID is identical to the interface index on which the address type is supported and on which the desired destinations are reachable. On Solaris platforms, the server accepts traditional interface names, such as hme0, instead of numeric scope IDs.

Configuring IPv6 Addresses for RADIUS Client Connections

You can configure the [Addresses] section of the radius.ini file if you want to specify the local address or addresses on which Steel-Belted Radius Carrier listens for RADIUS client connections. By default, Steel-Belted Radius Carrier automatically discovers and configures all available IPv4 interfaces on the local host. If IPv6 is enabled, Steel-Belted Radius Carrier discovers and configures both IPv4 and IPv6 interfaces.

You can configure Steel-Belted Radius Carrier to configure IPv4 automatically by entering AutoConfigureIPv4 in the [Addresses] section. Similarly, you can configure Steel-Belted Radius Carrier to configure IPv6 automatically by entering AutoConfigureIPv6 in the [Addresses] section. If you configure specific IPv4 or IPv6 addresses, Steel-Belted Radius Carrier listens for RADIUS traffic on only those interfaces.

The IPv6 unspecified address :: allows connections on any IPv6 address or IPv4 address, with IPv4 connections represented as IPv6 IPv4 mapped addresses.

Configuring DNSv6 Support

Enabling Domain Name Service Version 6 (DNSv6) support lets Steel-Belted Radius Carrier communicate with a DNSv6 server to resolve hostnames. By default, Steel-Belted Radius Carrier uses DNS unless IPv6 is enabled and DNSv6 support is configured by means of the DynamicNameResolution parameter in the [IPv6] section of the radius.ini file.

  • If DynamicNameResolution is set to 0, Steel-Belted Radius Carrier uses IPv4 DNS, which means it does not query DNSv6 services.
  • If DynamicNameResolution is set to 1, Steel-Belted Radius Carrier uses IPv6 DNS (DNSv6), which means it does not query IPv4 DNS services and ignores IPv4-specific information returned by DNSv6 services.
  • If DynamicNameResolution is set to 2, Steel-Belted Radius Carrier queries DNSv6 services for IPv6-specific information, and then queries IPv4 DNS services for IPv4 specific information if DNSv6 fails to resolve a hostname.

 

 

Modified: 2017-09-27