| F.2. Authentication response | ||
|---|---|---|
 | Appendix F. Supported RADIUS Attribute/Value Pairs for L2TP operation |  |
| F.2. Authentication response | ||
|---|---|---|
| | Appendix F. Supported RADIUS Attribute/Value Pairs for L2TP operation | |
Table F.2. Access-Accept
| AVP | No. | Usage |
| Reply-Message | 18 | Reply message sent on PPP authentication response |
| MS-Primary-DNS-Server | 311/28 | Primary DNS address used in PPP IPCP (Vendor 311 specific) |
| MS-Secondary-DNS-Server | 311/29 | Secondary DNS address used in PPP IPCP (Vendor 311 specific) |
| Framed-Interface-ID | 96 | Peer IPv6 Interface ID expected in PPP IPV6CP |
| Framed-IP-Address | 8 | Peer IPv4 address expected in PPP IPCP (does not support 255.255.255.255 or 255.255.255.254 yet). Maximum localpref used. |
| NAS-IP-Address | 4 | Our end IPv4 address to use in IPCP negotiation. Does not add loopback route. This is non standard. |
| Framed-Route | 22 | May 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-Prefix | 123 | IPv6 prefix to be routed to line. Maximum localpref used. |
| Framed-IPv6-Prefix | 97 | IPv6 prefix to be routed to line. Maximum localpref used. |
| Framed-IPv6-Route | 99 | May 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-Address | 168 | Adds a /128 IPv6 route. |
| User-Name | 1 | Username may be specified - this replaces the username already present and is then used on accounting start and relay L2TP. |
| CHAP-Challenge | 60 | Overwrite relay details: If no length then forces PAP, else forces CHAP and sets challenge. Send before CHAP-Password or User-Password in packet. |
| CHAP-Password | 3 | Overwrite relay details: This replaces the CHAP ID and CHAP response |
| User-Password | 2 | Overwrite relay details: (not, plain text, not encoded). If CHAP, sets a response based on this, else forces PAP using this password. |
| Called-Station-Id | 30 | Called number may be specified - this replaces the number already present |
| Calling-Station-Id | 31 | Calling number may be specified - this replaces the number already present |
| Chargeable-User-Identity | 89 | This is used as the preferred CQM graph name. |
| Class | 25 | Secondary CQM graph name to group sessions allowing group logging or shaping. |
| Session-Timeout | 27 | Absolute limit on session, in seconds |
| Filter-Id | 11 | See filter ID section |
| Framed-MTU | 12 | Set MTU for session |
| Connect-Info | 77 | Text tx/rx speed limit to apply to session (see below) |
| Tunnel-Type | 64 | If specified must be 3 (L2TP), L2TP is assumed. Also allows special 'R' and 'S' types, see below. |
| Tunnel-Medium-Type | 65 | If specified must be 1 (IPv4) or 2 (IPv6), syntax of endpoint is used if this is not specified |
| Tunnel-Server-Endpoint | 67 | Text IPv4 or IPv6 address of endpoint (FQDN is not accepted) |
| Tunnel-Client-Auth-ID | 90 | Hostname to quote on outgoing tunnel, if omitted then configured FireBrick hostname is used |
| Tunnel-Password | 69 | Shared secret to use on outgoing tunnel (encrypted), if omitted then assumed no secret |
| Tunnel-Assignment-ID | 81 | Name of outgoing tunnel shaper/graph. Also groups sessions together in a tunnel as per RFC. Only use valid text graph names. |
| Tunnel-Preference | 83 | Specifies preference order when multiple tagged endpoints sent |
Note that whilst a RADIUS response is normally relatively small it 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-EndPoint 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 a number of numeric values appended (#port, >mintimeout, <maxtimeout, *scale, ?maxqueue).
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, this involves a number of additional parameters in the string prefixed with characters: > min, < max, _ minburst, and \ step. You need to include the Chargeable-User-Identity in the request for speeds to be set.
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).
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 (Prefix 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.
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.
| |  | |
| Appendix F. Supported RADIUS Attribute/Value Pairs for L2TP operation |  | F.3. Accounting Start |