IPv6 Support
IPv6 is the next step in the evolution of the Internet Protocol, currently implemented as Internet Protocol Version 4 (IPv4). 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. The SBR Administrator (configuration application) 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.
IPv6 Prefix: FEC0:0000:0000:0000:0000:0000:0000:0000/64
IPv6 Interface ID: 0260:08FF:FEFF:FFFF
IPv6 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 wild cards are used, as the abbreviations become ambiguous in the presence of wild cards. The following prefixes are equivalent:
Canonical form: 2001:1c44:820d:eea0:0260:08ff:feff:ffff/64
With wild cards: 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 wild cards are used, as the abbreviations become ambiguous in the presence of wild cards. The following interface IDs are equivalent:
64-bit interface ID: 0260:08ff:0000:0000
With wild cards: 02??:08ff:*:*
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.
Prior to the adoption of Classless Inter-Domain Routing (CIDR), the IPv4 address space is divided into five address classes, as shown in Table 15.
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:
Start of address range: 199.100.10.0
End of address range: 199.100.10.255
As a wild carded 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 wild carded 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 SBR Administrator.
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 by the SBR Administrator.
Table 16 presents a summary of IPv6 support in Steel-Belted Radius Carrier.
RADIUS IPv6 Attributes
All RADIUS attributes defined in RFC 3162, RADIUS and IPv6, 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 17 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.
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 NAD 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 NAD.
The NAS-IPv6-Address attribute may be specified by the NAD 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 NAD.
Steel-Belted Radius Carrier allows zero or one 128-bit IPv6 address to be specified for each NAD. 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:ffff
RADIUS 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 it is recommended that the RADIUS server honor the hint if this attribute is suggested by the NAD. This is typically accomplished with echo attributes.
The Framed-Interface-Id attribute may be specified by the NAD 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:ffff
RADIUS 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 NAD and overridden by the RADIUS server. In any case, the v is expected to be able to plumb the routes implied by the Framed-IPv6-Prefix attributes and these need not be repeated in separate Framed-IPv6-Route attributes.
The Framed-IPv6-Prefix attribute may be specified by the NAD 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/10
RADIUS 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 NAD and overridden by the RADIUS server.
The Login-IPv6-Host attribute may be specified by the NAD 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 NAD should select the login host for the user.
- 128-bits set to 1 indicates that the NAD 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:ffff
RADIUS 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 NAD managed pool (as opposed to a RADIUS server managed pool) from which the NAD should assign an IPv6 prefix to the user. The Framed-IPv6-Pool attribute may not be suggested by the NAD and is always determined by the RADIUS server.
The Framed-IPv6-Pool attribute may be specified by the NAD 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 NAD 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-pool
RADIUS 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 NAD. The NAD 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 NAD and is always determined by the RADIUS server.
The Framed-IPv6-Route attribute may be specified by the NAD 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 1
RADIUS attribute: 63 32 32 30 30 30 3a 30 3a 30 ... 39 3a 61 39 39 38 20 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 on the settings in the radius.ini file, refer to the Steel-Belted Radius 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.
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 host names. 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 host name.
