F.2. Authentication response

F.2.1. Accepted authentication

Table F.2. Access-Accept

AVPNo.Usage
Reply-Message18Reply message sent on PPP authentication response
MS-Primary-DNS-Server311/28Primary DNS address used in PPP IPCP (Vendor 311 specific)
MS-Secondary-DNS-Server311/29Secondary DNS address used in PPP IPCP (Vendor 311 specific)
Framed-Interface-ID96Peer IPv6 Interface ID expected in PPP IPV6CP
Framed-IP-Address8Peer IPv4 address expected in PPP IPCP (does not support 255.255.255.255 or 255.255.255.254 yet). Maximum localpref used.
NAS-IP-Address4Our end IPv4 address to in IPCP negotiation. Does not add loopback route. This is non standard.
Framed-Route22May appear more than once. Text format is IPv4-Address/Bits 0.0.0.0 metric. The target IP is ignored but must be valid IPv4 syntax. The metric is used as localpref in routing.
Delegated-IPv6-Prefix123IPv6 prefix to be routed to line. Maximum localpref used.
Framed-IPv6-Prefix97IPv6 prefix to be routed to line. Maximum localpref used.
Framed-IPv6-Route99May appear more than once. Text format is IPv6-Address/Bits :: metric. The target IP is ignored but must be valid IPv6 syntax. The metric is used as localpref in routing. Alternative format IPv6/Bits IPv4-Address metric defines that prefix is to be protocol 41 IPv4 tunneled to specified target via this link.
Framed-IPv6-Address168Adds a /128 IPv6 route.
User-Name1Username may be specified - this replaces the username already present and is then used on accounting start and relay L2TP.
CHAP-Challenge60Overwrite relay details: If no length then forces PAP, else forces CHAP and sets challenge. Send before CHAP-Password or User-Password in packet.
CHAP-Password3Overwrite relay details: This replaces the CHAP ID and CHAP response
User-Password2Overwrite relay details: (not, plain text, not encoded). If CHAP, sets a response based on this, else forces PAP using this password.
Called-Station-Id30Called number may be specified - this replaces the number already present
Calling-Station-Id31Calling number may be specified - this replaces the number already present
Chargeable-User-Identity89This is used as the preferred CQM graph name.
Class25Secondary CQM graph name to group sessions allowing group logging or shaping.
Session-Timeout27Absolute limit on session, in seconds
Filter-Id11See filter ID section
Framed-MTU12Set MTU for session
Connect-Info77Text tx/rx speed limit to apply to session (see below)
Tunnel-Type64If specified must be 3 (L2TP), L2TP is assumed. Also allows special 'R' and 'S' types, see below.
Tunnel-Medium-Type65If specified must be 1 (IPv4) or 2 (IPv6), syntax of endpoint is used if this is not specified
Tunnel-Server-Endpoint67Text IPv4 or IPv6 address of endpoint (FQDN is not accepted)
Tunnel-Client-Auth-ID90Hostname to quote on outgoing tunnel, if omitted then configured FireBrick hostname is used
Tunnel-Password69Shared secret to use on outgoing tunnel (encrypted), if omitted then assumed no secret
Tunnel-Assignment-ID81Name of outgoing tunnel shaper/graph. Also groups sessions together in a tunnel as per RFC. Only use valid text graph names.
Tunnel-Preference83Specifies preference order when multiple tagged endpoints sent

Note that whilst a RADIUS response is normally relatively small in can get larger when multiple tunnel endpoints are included. Fragmented responses are handled but there is an internal limit to the size of response that can be processed - as such we recommend keeping the response to a single un-fragmented packet of up to 1500 bytes. You can use tag 0 for common settings such as Tunnel-Client-Auth-ID or Tunnel-Password when using multiple endpoints in order to reduce the size of the response.

The Tunnel-Type can be special, non-RFC values: 'R' (0x52)or 'S' (0x53) to indicate that the Tunnel-Server-EnPoint is the name or IP of a further RADIUS server to be interrorgated. For 'R' this may respond with any valid authentication response. For 'S' the response will have all IP assignments filtered, and also not allow a Tunnel-Type 'S' response. Only one, tag 0 (untagged), RADIUS referral response will be accepted. The endpoint specified is server name or IP, and can have #port appended for non standard RADIUS auth port.

The Connect-Info response can be a simple number (bits/second) tx rate, or a number followed by a % where this sets a speed based on a percentage of connection line speed. This can be followed by a slash (/) and the same for rx rate if required (default is rx is not limited). It is also possible to set long term shapers where a Chargeable-User-Identity is also included, this involves a number of additional parameters in the string prefixed with characters: > min, < max, _ minburst, and \ step.

Some of the response fields are somewhat unconventional, such as User-Name and User-Password, allowing existing entries to be overwritten. These impact any details passed in a RADIUS accounting start and also impact relayed L2TP connections. Note that these can also impact if a secondary RADIUS request is done (e.g. if far end sends a new CHAP response, for example).

F.2.1.1. Prefix Delegation

The RADIUS authentication response can include Delegated-IPv6-Prefix, Framed-IPv6-Prefix, and Framed-IPv6-Route in order to route native IPv6 prefixes to the line. If there are any native IPv6 routes, or the Framed-IPv6-Interface attribute was specified, then IPV6CP negotiation is started. Framed-IPv6-Route can also be used to added IPv4 tunneled routes to the line. The FE80::/10 link local address negotiated with IPV6CP is not added to the routing for the line.

The client can send a Router solicitation to which the FireBrick will reply advising to use DHCPv6 for addressing. Once a router solicitation is sent, periodic Router Advertisements will then be sent on the connection by the Firebrick.

The client can use DHCPv6 to request an IA_NA (/128 link address), IA_TA (/128 temp link address), IA_PD (Prefic delegation) and DNS servers. Prefixes are delegated based on the order in the DHCPv6 request and the order of Delegated-IPv6-Prefix, Framed-IPv6-Prefix, and then Framed-IPv6-Route, with multiple such entries in the order that they appeared in the RADIUS response. Such prefixes are not split up if a smaller prefix is requested, but the first part of a prefix is delegated.

As you can see, it is possible to send back CHAP-Challenge and CHAP-Password or User-Password to override those received by proxy or negotiation. This is mainly used when relaying the L2TP onwards and changes the proxy authentication field sent. This also overrides the Last LCP Tx proxy setting to show PAP/CHAP or no authentication as having been negotiated.

F.2.2. Rejected authentication

Table F.3. Access-Reject

AVPNo.Usage
Reply-Message18Reply message sent on PPP authentication response

Note that an authentication reject will normally cause the reply message to be sent as an authentication reject message. The reply "Try another" causes the L2TP session to be closed with result/error 2/7 (Try another) without sending an authentication reply on PPP.