Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)
Extracted elements (31)
A single L2TPv2 session per tunnel is used in the Softwire context because each Softwire carries the information of a single user, unlike general L2TPv2 deployments where one tunnel may carry multiple users each as a separate session.
Address and prefix stability is a design consideration: the SC should provide the same address and prefix to a reconnecting user. When multiple SCs are used for load-balancing, providing the same address across SCs is possible but increases routing table fragmentation; aggregating prefixes near the SC mitigates this.
L2TPv2 always uses UDP encapsulation even when no NAT/NAPT is present because L2TPv2 cannot autodetect NAT/NAPT along the path. UDP bypass and NAT autodetect are listed as optional requirements in RFC 4925 and are not required.
L2TPv2 was chosen as the phase 1 Hub and Spoke protocol because it is widely deployed in broadband services, supports NAT/NAPT traversal via UDP, integrates with AAA/RADIUS, and reuses existing standards — a key design goal of the Softwires WG to favor time-to-market solutions.
If a RADIUS Access-Accept returns a Framed-Interface-Id (RFC 3162), the SC must send it in the IPV6CP Interface-Identifier field. If Framed-IPv6-Prefix is present it must be used in RAs; if absent but Framed-IPv6-Pool is present, the SC must choose a prefix from that pool.
Softwire implementations SHOULD NOT send AVPs not relevant to Softwires (e.g., outgoing-call AVPs), but SHOULD silently ignore them if received. This allows Softwire code to be layered on existing L2TPv2 stacks without breaking compatibility.
When LCP ECHO is used in combination with L2TPv2 HELLO keepalives, LCP ECHO messages SHOULD have a re-emission timer lower than the L2TPv2 HELLO interval (default 60s). Suggested LCP ECHO defaults: 30s interval, 10s minimum, capped at the lesser of the HELLO interval and 60s.
After IPV6CP is completed, the Softwire Initiator MUST send a Router Solicitation to the SC. The SC MUST respond with a Router Advertisement that MUST contain the global IPv6 prefix of the PPP link if Neighbor Discovery is used to configure endpoint addresses.
An SI acting as a router in an IPv6 Softwire MUST include the IA_PD option (RFC 3633) in the DHCPv6 Solicit message to request an IPv6 prefix. The SC SHOULD inject a route for the delegated prefix to forward traffic to the relevant Softwire.
Duplicate Address Detection (RFC 4861) MUST be performed on the Softwire in both DHCPv6 and stateless address autoconfiguration cases for IPv6 endpoint address assignment.
If PPP authentication is chosen, CHAP (RFC 1994) MUST be supported by both the Softwire Initiator and Softwire Concentrator. Other methods (MS-CHAPv1, EAP) MAY additionally be supported.
In IPv6-over-IPv4 scenarios, the Softwire Initiator MUST negotiate IPV6CP as defined in RFC 5072 after the optional authentication phase. For IPv4-over-IPv6 scenarios, the SI MUST negotiate IPCP per RFC 1332.
In the Softwire model, an L2TPv2 packet MUST be carried over UDP. The underlying IP version may be IPv4 or IPv6 depending on the scenario; UDP bypass is not supported because L2TPv2 does not autodetect NAT/NAPT.
IPv4 traffic SHOULD NOT traverse an IPv6-over-IPv4 Softwire; similarly, IPv6 traffic SHOULD NOT traverse an IPv4-over-IPv6 Softwire. The Softwire carries only the address family that is being transitioned.
L2TPv2 AVPs SHOULD NOT be hidden because Softwire establishment messages do not transport sensitive data such as usernames or passwords. The AVP hiding mechanism exists but is unnecessary in this context.
RFC 3193 (Securing L2TP using IPsec / IKEv1) MUST be supported, given that deployed technology must be very strongly considered for this time-to-market solution. IKEv2-based security is noted as a future consideration.
Softwire implementations SHOULD NOT send AVPs that are not relevant to Softwires, but SHOULD ignore them when received. This simplifies building Softwire applications on top of existing L2TPv2 implementations.
The Challenge AVP and Challenge Response AVP usage in L2TP messages is OPTIONAL, but SHOULD be implemented in the SC to enable tunnel authentication and help prevent denial-of-service attacks at tunnel setup.
The SCCRP responder (SC) responding from a different IP address and/or UDP port than those of the SCCRQ is NOT RECOMMENDED, as it will fail through Address-Dependent or Address-and-Port-Dependent NAT filtering.
The SI and SC MUST follow the L2TPv2 operations described in RFC 2661 when performing Softwire establishment, teardown, and OAM. The L2TPv2 compulsory tunneling model does not apply to Softwires and SHOULD NOT be requested or honored.
The SI/SC MUST periodically transmit a keepalive message to detect tunnel or peer failure and maintain NAT/NAPT contexts. L2TPv2 HELLO messages provide this mechanism; implementations SHOULD use L2TPv2 Hello keepalives and MAY additionally use PPP LCP Echo messages.
A Softwire consists of an L2TPv2 Control Connection (Control Channel), a single L2TPv2 Session, and a PPP link negotiated over that session. There is exactly one L2TPv2 session per tunnel in the Softwire environment.
Control Channel establishment uses three messages: SCCRQ (SI→SC), SCCRP (SC→SI), SCCCN (SI→SC). Session establishment uses ICRQ (SI→SC), ICRP (SC→SI), ICCN (SI→SC). Only the incoming call model is used; outgoing or analog calls are not permitted.
Required AVPs for the SCCRQ/SCCRP exchange include: Message Type, Protocol Version, Host Name, Framing Capabilities, and Assigned Tunnel ID. Optional AVPs include Receive Window Size, Challenge, Firmware Revision, Vendor Name, and Challenge Response.
The RADIUS Delegated-IPv6-Prefix attribute (RFC 4818) in the Access-Accept message must be used by the SC for IPv6 prefix delegation. The SC must associate the DHCP DUID of a DHCPv6 request to the tunnel and its authenticated user.
The Softwire Initiator (SI) assumes the role of the L2TP Access Concentrator (LAC) Client, initiating both the L2TP tunnel/session and the PPP link. The Softwire Concentrator (SC) assumes the role of the L2TP Network Server (LNS).
L2TP Tunnel Authentication (Challenge/Challenge Response AVPs) provides authentication at tunnel setup and may limit DoS attacks by authenticating before L2TP and PPP resources are allocated. PPP CHAP provides per-user authentication. L2TPv2 can be secured with IPsec ESP for privacy, integrity, and replay protection.
RFC 3193 (IKEv1-based IPsec for L2TPv2) MUST be supported for deployed interoperability. RFC SW-SEC defines a newer IKEv2-based approach with advantages described in its Section 3.5, which should be considered for future phases.
Softwire establishment follows up to four sequential steps: Step 0 (optional IKEv1 IPsec SA), Step 1 (L2TPv2 tunnel + session), Step 2 (PPP LCP + optional auth + NCP IPV6CP or IPCP), Step 3 (optional DHCPv6 or DHCPv4 for prefix delegation and DNS). Steps 0 and 3 are optional.
Supported encapsulation stacks are: IPv6/PPP/L2TPv2/UDP/IPv4, IPv4/PPP/L2TPv2/UDP/IPv6, IPv4/PPP/L2TPv2/UDP/IPv4, and IPv6/PPP/L2TPv2/UDP/IPv6. UDP encapsulation is always present regardless of NAT/NAPT because L2TPv2 has no autodetect.
The PPP MTU presented to the Softwire Payload Header SHOULD be the link MTU minus the combined sizes of the IP, UDP, L2TPv2, and PPP headers. On a 1500-byte IPv4 link this is typically 1460 bytes; when IPsec ESP is also present, the MTU SHOULD be further reduced.