| Appendix F. Supported L2TP Attribute/Value Pairs | ||
|---|---|---|
 |  | |
| Appendix F. Supported L2TP Attribute/Value Pairs | ||
|---|---|---|
| | | |
This appendix details the L2TP protocol messages supported, and the attribute/value pairs (AVPs) which are sent and expected for each message.
Table F.1. SCCRQ
| AVP | No. | Incoming | Outgoing |
| Message Type | 0 | Value 1 | Value 1 |
| Protocol Version | 2 | Mandatory, value 1 expected | Value 1 |
| Framing Capabilities | 3 | Ignored | Value 3 |
| Bearer Capabilities | 4 | Ignored | Not sent |
| Tie Breaker | 5 | Ignored as FireBrick only accepts connections for inbound calls | Not sent |
| Firmware Revision | 6 | Ignored | FireBrick s/w version string |
| Host Name | 7 | Used to select which incoming L2TP configuration applies. | As per config/RADIUS request |
| Vendor Name | 8 | Ignored | FireBrick Ltd |
| Assigned Tunnel ID | 9 | Mandatory | Mandatory, our tunnel ID |
| Receive Window Size | 10 | Accepted, assumed 4 if not present or less than 4 is specified | Value 4 |
| Challenge | 11 | Accepted if a configured secret is defined, a response is sent in the SCCRP | Not sent at present |
Table F.2. SCCRP
| AVP | No. | Incoming | Outgoing |
| Message Type | 0 | Value 2 | Value 2 |
| Protocol Version | 2 | Value 1 expected | Value 1 |
| Framing Capabilities | 3 | Ignored | Value 3 |
| Bearer Capabilities | 4 | Ignored | Not sent |
| Firmware Revision | 6 | Ignored | FireBrick s/w ID number |
| Host Name | 7 | Logged as hostname for tunnel | Configured hostname, if defined |
| Vendor Name | 8 | Ignored | FireBrick Ltd |
| Assigned Tunnel ID | 9 | Expected as far end ID | Mandatory, our tunnel ID |
| Receive Window Size | 10 | Accepted, assimed 4 if not present or less than 4 | Not sent, assume 4 |
| Challenge | 11 | Accepted if a configured secret is defined, a response is sent in the SCCCN | Not sent at present |
| Challenge Response | 13 | Not expected at present | Sent if SCCRQ contained a challenge and we have a secret defined |
Table F.3. SCCCN
| AVP | No. | Incoming | Outgoing |
| Message Type | 0 | Value 3 | Value 3 |
| Challenge Response | 13 | Not expected | Sent if was challenged |
Table F.4. StopCCN
| AVP | No. | Incoming | Outgoing |
| Message Type | 0 | Value 4 | Value 4 |
| Result Code | 1 | Ignored (logged) | Sent as appropriate for tunnel close |
| Assigned Tunnel ID | 9 | Expected, see note | Sent if a tunnel has been allocated |
Note that a StopCCN may not have a zero tunnel ID in the header. If this is the case the source IP, port and assigned tunnel are used to identify the tunnel.
If an unknown tunnel ID is received on any any incoming packet a StopCCN is generated (once per 10 seconds) with header tunnel ID 0 and specified assigned tunnel ID.
Always responded to. Sent periodically if no other messages sent.
Table F.6. ICRQ
| AVP | No. | Incoming | Outgoing |
| Message Type | 0 | Value 10 | Value 10 |
| Assigned Session ID | 14 | Mandatory | Mandatory, our session ID |
| Call Serial Number | 15 | Accepted and passed on if relaying | Passed on incoming value |
| Bearer Type | 18 | Ignored | Not sent |
| Called Number | 21 | Accepted, used in RADIUS and passed on if relaying | Passed on incoming value |
| Calling Number | 22 | Accepted, used in RADIUS and passed on if relaying | Passed on incoming value |
| Sub-Address | 23 | Ignored | Not sent |
| Physical Channel ID | 25 | Ignored | Not sent |
Table F.7. ICRP
| AVP | No. | Incoming | Outgoing |
| Message Type | 0 | Value 11 | Value 11 |
| Assigned Session ID | 14 | Mandatory | Mandatory |
Table F.8. ICCN
| AVP | No. | Incoming | Outgoing |
| Message Type | 0 | Value 12 | Value 12 |
| Framing Type | 19 | Ignored | 1 |
| Tx Connect Speed | 24 | Accepted, used in RADIUS and passed on if relaying | Passed on incoming value |
| Initial Received LCP CONFREQ | 26 | Ignored | Not sent |
| Last Sent LCP CONFREQ | 27 | Accepted, used in RADIUS and passed on if relaying | Passed on incoming value |
| Last Received LCP CONFREQ | 28 | Accepted, used in RADIUS and passed on if relaying | Passed on incoming value |
| Proxy Authen Type | 29 | Accepted, used in RADIUS and passed on if relaying | Passed on incoming value |
| Proxy Authen Name | 30 | Accepted, used in RADIUS and passed on if relaying | Passed on incoming value |
| Proxy Authen Challenge | 31 | Accepted, used in RADIUS and passed on if relaying | Passed on incoming value |
| Proxy Authen ID | 32 | Accepted, used in RADIUS and passed on if relaying | Passed on incoming value |
| Proxy Authen Response | 33 | Accepted, used in RADIUS and passed on if relaying | Passed on incoming value |
| Private Group ID | 37 | Ignored | Not sent |
| Rx Connect Speed | 38 | Accepted, used in RADIUS and passed on if relaying | Passed on incoming value |
| Sequencing Required | 39 | Accepted on honoured | Not sent |
Not supported, ignored.
Not supported, ignored.
Not supported, ignored.
Table F.12. CDN
| AVP | No. | Incoming | Outgoing |
| Message Type | 0 | Value 14 | Value 14 |
| Result Code | 1 | Ignored (logged) | Sent as appropriate for tunnel close |
| Q.931 Cause Code | 12 | Ignored | Not sent |
| Assigned Session ID | 14 | Expected, see note | Sent if assigned |
Note that a CDN may have a zero session ID in the header. If this is the case the tunnel ID and assigned session ID are used to identify the session.
If an unknown session ID on a known tunnel ID is received on any any incoming packet a CDN is generated with header session ID 0 and specified assigned session ID.
Not supported, ignored.
Not supported, ignored.
The L2TP and PPP specifications are clear that the HDLC framing bytes are not sent or received within the L2TP packet. However, BT send type bytes (FF03) on the start of all PPP frames. This is silently discarded. Also, BT will not process packets if these type bytes are not included in outgoing packets. Sending the HDLC framing can be controlled in the config and on a per session basis using a Filter-Id in RADIUS authentication response.
BT sometimes negotiate incorrect MRUs on behalf of the LNS. Where the L2TP proxy details indicate and incorrect MRU has been negotiated then LCP negotiation is restarted and the correct MRU negotiates. This helps avoid various issues with fragmentation on some services on the internet when the broadband fully supports 1500 byte MTU. This is also relevant where the FB6000 is deliberately configured to use a smaller MRU for example when the L2TP connection is remote via a 1500 MTU link.
There are options using Filter-Id from RADIUS to force LCP restart. However this does confuse some ppp implementations as it is after authentication is complete. This can be useful where BT have provided an incorrect MRU for the end user (another bug). There is also an option to forward 1500 byte packets rather than fragmenting them. When enabled ICMP is still generated for DF and IPv6.
IP over LCP is a non standard coding of PPP packets for IPv4 and IPv6. The coding uses the LCP code (C021) instead of the IPv4 (0021) or IPv6 (0057) code. The first byte which would normally be the LCP type is 0x4X (IPv4) or 0x6X (IPv6). The FireBrick assumes any such LCP codes are IPv4/IPv6 when received, and using a RADIUS response can send IP packets using LCP. This is specifically to bypass any carrier IP specific shaping or DPI.
| | | |
| Appendix E. VLANs : A primer |  | Appendix G. Supported RADIUS Attribute/Value Pairs for L2TP operation |