RFC 5571
Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)
RFC 5571: Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) 🎀
okay bestie, this one is the Softwire Hub and Spoke framework, and it's giving "how do I get IPv4 across an IPv6-only network" energy 🦋 ✨
- Number: RFC 5571
- Date: June 2009
- Category: Standards Track 👑
- Working group: Network Working Group
- Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates 🌸
The authors are B. Storer, C. Pignataro (Ed.), M. Dos Santos, B. Stevant (Ed.), L. Toutain, and J. Tremblay. Their affiliations are Cisco Systems, TELECOM Bretagne, and Videotron Ltd. 💜
Status of This Memo 🌈
so this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💅 for the standardization state and status, you check the current edition of "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so share away 🫶
Copyright Notice ⭐
copyright is (c) 2009 IETF Trust and the people listed as the document authors, all rights reserved 🔒 this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were on the publication date. the info lives at http://trustee.ietf.org/license-info. read it carefully, bestie, because it covers your rights and restrictions 📜
heads up: this doc might contain stuff from IETF Documents or IETF Contributions that was published or made publicly available before November 10, 2008 😭 the people who own the copyright on some of that material might not have given the IETF Trust permission to allow changes outside the IETF Standards Process. so unless you get a proper license from those copyright holders, you can't modify this doc outside the IETF Standards Process, and you can't make derivative works outside it either. the exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸
Abstract 🧚
this doc describes the framework of the Softwire "Hub and Spoke" solution using the Layer Two Tunneling Protocol version 2 (L2TPv2) 💖 the implementation details in here should be followed so different vendors' implementations can actually talk to each other 🍓
Table of Contents 📖
1. Introduction ....................................................4
1.1. Abbreviations ..............................................5
1.2. Requirements Language ......................................5
1.3. Considerations .............................................6
2. Applicability of L2TPv2 for Softwire Requirements ...............6
2.1. Traditional Network Address Translation (NAT and NAPT) .....6
2.2. Scalability ................................................7
2.3. Routing ....................................................7
2.4. Multicast ..................................................7
2.5. Authentication, Authorization, and Accounting (AAA) ........7
2.6. Privacy, Integrity, and Replay Protection ..................7
2.7. Operations and Management ..................................8
2.8. Encapsulations .............................................8
3. Deployment Scenarios ............................................8
3.1. IPv6-over-IPv4 Softwires with L2TPv2 .......................9
3.1.1. Host CPE as Softwire Initiator ......................9
3.1.2. Router CPE as Softwire Initiator ...................10
3.1.3. Host behind CPE as Softwire Initiator ..............11
3.1.4. Router behind CPE as Softwire Initiator ............12
3.2. IPv4-over-IPv6 Softwires with L2TPv2 ......................14
3.2.1. Host CPE as Softwire Initiator .....................14
3.2.2. Router CPE as Softwire Initiator ...................15
3.2.3. Host behind CPE as Softwire Initiator ..............16
3.2.4. Router behind CPE as Softwire Initiator ............16
4. References to Standardization Documents ........................17
4.1. L2TPv2 ....................................................18
4.2. Securing the Softwire Transport ...........................18
4.3. Authentication, Authorization, and Accounting .............18
4.4. MIB .......................................................18
4.5. Softwire Payload Related ..................................19
4.5.1. For IPv6 Payloads ..................................19
4.5.2. For IPv4 Payloads ..................................19
5. Softwire Establishment .........................................20
5.1. L2TPv2 Tunnel Setup .......................................22
5.1.1. Tunnel Establishment ...............................22
5.1.1.1. AVPs Required for Softwires ...............25
5.1.1.2. AVPs Optional for Softwires ...............25
5.1.1.3. AVPs Not Relevant for Softwires ...........26
5.1.2. Tunnel Maintenance .................................26
5.1.3. Tunnel Teardown ....................................27
5.1.4. Additional L2TPv2 Considerations ...................27
5.2. PPP Connection ............................................27
5.2.1. MTU ................................................27
5.2.2. LCP ................................................27
5.2.3. Authentication .....................................28
5.2.4. IPCP ...............................................28
5.2.4.1. IPV6CP ....................................28
5.2.4.2. IPv4CP ....................................28
5.3. Global IPv6 Address Assignment to Endpoints ...............28
5.4. DHCP ......................................................29
5.4.1. DHCPv6 .............................................29
5.4.2. DHCPv4 .............................................29
6. Considerations about the Address Provisioning Model ............30
6.1. Softwire Endpoints' Addresses .............................30
6.1.1. IPv6 ...............................................30
6.1.2. IPv4 ...............................................31
6.2. Delegated Prefixes ........................................31
6.2.1. IPv6 Prefixes ......................................31
6.2.2. IPv4 Prefixes ......................................31
6.3. Possible Address Provisioning Scenarios ...................31
6.3.1. Scenarios for IPv6 .................................32
6.3.2. Scenarios for IPv4 .................................32
7. Considerations about Address Stability .........................32
8. Considerations about RADIUS Integration ........................33
8.1. Softwire Endpoints ........................................33
8.1.1. IPv6 Softwires .....................................33
8.1.2. IPv4 Softwires .....................................33
8.2. Delegated Prefixes ........................................34
8.2.1. IPv6 Prefixes ......................................34
8.2.2. IPv4 Prefixes ......................................34
9. Considerations for Maintenance and Statistics ..................34
9.1. RADIUS Accounting .........................................35
9.2. MIBs ......................................................35
10. Security Considerations .......................................35
11. Acknowledgements ..............................................36
12. References ....................................................37
12.1. Normative References .....................................37
12.2. Informative References ...................................381. Introduction ✨
okay so the Softwires Working Group picked Layer Two Tunneling Protocol version 2 (L2TPv2) as the phase 1 protocol for the Softwire "Hub and Spoke" solution space 💅 this doc lays out the framework for the L2TPv2 "Hub and Spoke" solution, and the implementation details in here should be followed so different vendors can interoperate 🫶
in the "Hub and Spoke" solution space, a Softwire gets set up to give the home network IPv4 connectivity across an IPv6-only access network, or IPv6 connectivity across an IPv4-only access network 🌈 when L2TPv2 is used in the Softwire context, the voluntary tunneling model applies. the Softwire Initiator (SI) at the home network acts as the L2TP Access Concentrator (LAC) client, starting both the L2TP tunnel/session and the PPP link 🎀 the Softwire Concentrator (SC) at the ISP plays the L2TP Network Server (LNS) role. the terms voluntary tunneling and compulsory tunneling are defined in Section 1.1 of [RFC3193] 🍓 since the L2TPv2 compulsory tunneling model doesn't apply to Softwires, it SHOULD NOT be requested or honored 🙈 this doc calls out all the voluntary tunneling related L2TPv2 attributes that apply to Softwires and spells out how to handle them so implementations don't get confused 💖 it also lists the L2TPv2 attributes specific to the compulsory tunneling model that don't apply to Softwires, and says how to ignore or nullify their effect in the Softwire context 🧚
the SI and SC MUST follow the L2TPv2 operations described in [RFC2661] when they do Softwire establishment, teardown, and Operations, Administration, and Management (OAM) 🔥 with L2TPv2, a Softwire is made of an L2TPv2 Control Connection (also called the Control Channel), a single L2TPv2 Session, and the PPP link negotiated over that Session ✨ to set it up, the SI first starts an L2TPv2 Control Channel to the SC, which accepts the request and terminates the Control Channel 🦋 L2TPv2 supports an optional mutual Control Channel authentication, so both SI and SC can check each other's identity at the very start of the handshake before the Control Channel is established 👑 once the L2TPv2 Control Channel is up between the SI and SC, the SI starts an L2TPv2 Session to the SC 💜 then the PPP/IP link gets negotiated over that L2TPv2 Session between the SI and SC 🌸 after the PPP/IP link is up, it acts as the Softwire between the SI and SC, tunneling IP traffic of one Address Family (AF) across the access network of a different Address Family 🌈
during the life of the Softwire, both SI and SC send L2TPv2 keepalive HELLO messages to keep an eye on the health of the Softwire and the peer L2TP Control Connection Endpoint (LCCE) 🫶 those HELLOs can also refresh the NAT/NAPT (Network Address Translation / Network Address Port Translation) entry at the CPE or at the other end of the access link 🙌 optionally, Link Control Protocol (LCP) ECHO messages can be used as keepalives for the same purposes 💅 if there's a keepalive timeout or an administrative shutdown of the Softwire, either the SI or the SC MAY tear down the Softwire by tearing down the L2TPv2 Control Channel and Session as specified in [RFC2661] 😭
1.1. Abbreviations ✨
Okay bestie, here's the abbreviation cheat sheet 📚💖
- AF: Address Family, IPv4 or IPv6 🌐
- CPE: Customer Premises Equipment 🏠
- LCCE: L2TP Control Connection Endpoint, an L2TP node that lives at either end of an L2TP Control Connection. (See [RFC3931].) 🎀
- LNS: L2TP Network Server, a node that acts as one side of an L2TP tunnel (Control Connection) endpoint. The LNS is the logical termination point of a PPP session that's being tunneled from the remote system by the peer LCCE. (See [RFC2661].) 🦋
- SC: Softwire Concentrator, the node terminating the Softwire in the service provider network. (See [RFC4925].) 👑
- SI: Softwire Initiator, the node initiating the Softwire within the customer network. (See [RFC4925].) 🧚
- SPH: Softwire Payload Header, the IP headers being carried within a Softwire. (See [RFC4925].) 💜
- STH: Softwire Transport Header, the outermost IP header of a Softwire. (See [RFC4925].) 🌸
- SW: Softwire, a shared-state "tunnel" created between the SC and SI. (See [RFC4925].) ✨
1.2. Requirements Language 🫶
Here's the vibe check on the capital-letter words. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in [RFC2119]. Those words are doing real work, so pay attention when you see them 🔥
1.3. Considerations 🌈
Some sections of this document are considerations that aren't required for interoperability and correct operation of Softwire implementations. You can spot these sections because their titles begin with "Considerations". Think of them as the extra-credit bits 💅
2. Applicability of L2TPv2 for Softwire Requirements 🎀
Okay so the Softwire Problem Statement [RFC4925] lists a bunch of "Hub and Spoke" requirements. The sub-sections below show how L2TPv2 handles each one. Let's go through them 💖
2.1. Traditional Network Address Translation (NAT and NAPT) 🦋
A "Hub and Spoke" Softwire must be able to traverse Network Address Translation (NAT) and Network Address Port Translation (NATPT, also referred to as Port Address Translation or PAT) devices [RFC3022]. This matters when the scenario involves a non-upgradable, preexisting IPv4 home gateway doing NAT/NAPT, or some carrier equipment at the other end of the access link doing NAT/NAPT. The L2TPv2 Softwire (that is, the Control Channel and Session) can handle NAT/NAPT traversal because L2TPv2 can run over UDP. It's giving "works through the messy middle" 🙌
Here's the tea: L2TPv2 doesn't detect NAT/NAPT along the path, so it doesn't offer the option of disabling UDP. The UDP encapsulation is there no matter whether NAT/NAPT is present. Both NAT/NAPT "autodetect" and UDP "bypass" are optional requirements in Section 2.3 of [RFC4925]. 🙈
Now, as mentioned in Section 8.1 of [RFC2661] and Section 4 of [RFC3193], an L2TP Start-Control-Connection-Reply (SCCRP) responder (SC) can choose a different IP address and/or UDP port from the ones in the initiator's Start-Control-Connection-Request (SCCRQ) (SI). Whether that works through a NAT/NAPT depends on the NAT/NAPT's Filtering Behavior (see Section 5 of [RFC4787]). Specifically, any IP address and port combination will work with Endpoint-Independent Filtering. Changing the IP address and port will NOT work through Address-Dependent or Address-and-Port-Dependent Filtering. So, responding from a different IP address and/or UDP port is NOT RECOMMENDED. Bestie, don't do it 💀
2.2. Scalability 📈
In the "Hub and Spoke" model, a carrier must be able to scale the solution to millions of Softwire Initiators by adding more hubs (that is, Softwire Concentrators). L2TPv2 is widely deployed in broadband services, and its scalability has been proven in multiple large-scale IPv4 Virtual Private Network deployments. Those deployments scale up to millions of subscribers each. Iconic behavior 👑
2.3. Routing 🛣️
There are no dynamic routing protocols between the SC and SI. A default route from the SI to the SC is used. Simple and clean, no drama 💅
2.4. Multicast 📡
Multicast protocols simply run transparently over L2TPv2 Softwires alongside other regular IP traffic. No extra fuss ✨
2.5. Authentication, Authorization, and Accounting (AAA) 🔐
L2TPv2 supports optional mutual Control Channel authentication, and it leverages the optional mutual PPP per-session authentication. L2TPv2 is well integrated with AAA solutions (such as RADIUS) for both authentication and authorization. Most L2TPv2 implementations on the market support logging of authentication and authorization events. 🧾
L2TPv2 integration with RADIUS accounting (the RADIUS Accounting extension for tunnel [RFC2867]) lets you collect and report L2TPv2 Softwire usage statistics. Main character energy 📊
2.6. Privacy, Integrity, and Replay Protection 🫧
Since L2TPv2 runs over IP/UDP in the Softwire context, IPsec Encapsulating Security Payload (ESP) can be used alongside it. ESP provides per-packet authentication, integrity, replay protection, and confidentiality for both L2TPv2 control and data traffic [RFC3193] and [RFC3948]. Full security, periodt 🔒
For Softwire deployments where full payload security isn't required, you can consider the L2TPv2 built-in Control Channel authentication and the inherited PPP authentication and PPP Encryption Control Protocol. Lowkey a good option when you don't need the whole security package 🩷
2.7. Operations and Management 🛠️
L2TPv2 supports an optional in-band keepalive mechanism. It injects HELLO control messages after a specified period of time has passed since the last data or control message was received on a tunnel (see Section 5.5 of [RFC2661]). If the HELLO control message isn't reliably delivered, the Control Channel and its Session will be torn down. 😭 In the Softwire context, the L2TPv2 keepalive is used to monitor connectivity between the SI and SC, and/or as a refresh mechanism for any NAT/NAPT translation entry along the access link. Multi-tasking queen 👸
LCP ECHO offers a similar way to monitor connectivity status, as described in [RFC1661]. Softwire implementations SHOULD use L2TPv2 Hello keepalives. In addition, they MAY use PPP LCP Echo messages to ensure Dead End Detection and/or to refresh NAT/NAPT translation entries. Combining these two mechanisms can be used as an optimization. Two keepalives are better than one 🙌
The L2TPv2 MIB [RFC3371] supports the complete suite of management operations. That includes configuring the Control Channel and Session, polling Control Channel and Session status and their traffic statistics, and getting notifications of Control Channel and Session UP/DOWN events. Management goals, honestly 🧠
2.8. Encapsulations 🎁
L2TPv2 supports the following encapsulations:
IPv6/PPP/L2TPv2/UDP/IPv4IPv4/PPP/L2TPv2/UDP/IPv6IPv4/PPP/L2TPv2/UDP/IPv4IPv6/PPP/L2TPv2/UDP/IPv6
Note that UDP bypass is NOT supported by L2TPv2, because L2TPv2 doesn't support "autodetect" of NAT/NAPT. That's the one you need to remember 🚫
3. Deployment Scenarios 🗺️
For the "Hub and Spoke" problem space, four scenarios have been identified. In each of these four scenarios, different home equipment plays the role of the Softwire Initiator. This section walks through each scenario with L2TPv2 as the Softwire protocol, plus any other possible protocols involved to complete the solution. It examines the four scenarios for both IPv6-over-IPv4 (Section 3.1) and IPv4-over-IPv6 (Section 3.2) encapsulations. Four scenarios, two directions, we're thriving 🌟
3.1. IPv6-over-IPv4 Softwires with L2TPv2 🩵
The following sub-sections cover IPv6 connectivity (SPH) across an IPv4-only access network (STH) using a Softwire. 🧚♀️
3.1.1. Host CPE as Softwire Initiator 💻
The Softwire Initiator (SI) is the host CPE (directly connected to a modem), and it's dual-stack. There's no other gateway device. The IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 1 👀
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-----------------||----------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 |
E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| host CPE |
R [network] | | [ network ] | |
N | LNS | |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic
PPP o L2TPv2 o UDP o IPv4 (SPH)
Softwire
<------------------>
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|------------------>/64 prefix
RA
|------------------>DNS, etc.
DHCPv6
Figure 1: Host CPE as Softwire InitiatorHere's how the scenario plays out. First, the L2TPv2 Control Channel and Session get established, then PPP LCP negotiation happens (and PPP Authentication, optionally). If those all succeed, the IPv6 Control Protocol (IPV6CP) negotiates IPv6-over-PPP. This also gives the ISP the ability to assign the 64-bit Interface-Identifier to the host CPE, or to check that the two interface identifiers at the two PPP ends are unique [RFC5072]. 🎉
Once IPv6-over-PPP is up, IPv6 Stateless Address Autoconfiguration and Neighbor Discovery run over that link. The LNS can tell the host CPE which prefix to use for stateless address autoconfiguration through a Router Advertisement (RA). Other non-address configuration options (such as DNS [RFC3646], or the addresses of other servers that might be available) can be passed to the host CPE through DHCPv6. Everyone gets their settings, no cap 🫶
3.1.2. Router CPE as Softwire Initiator 🌸
okay so the Softwire Initiator (SI) here is the router CPE, and it's dual-stack 💅 The IPv4 traffic SHOULD NOT traverse the Softwire. Figure 2 shows the whole vibe ✨
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-----------------||---------------------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 | +-----+
E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| CPE |----|v4/v6|
R [network] | | [ network ] | | | host|
N | LNS | |LAC Client| +-----+
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic
PPP o L2TPv2 o UDP o IPv4 (SPH)
Softwire
<------------------>
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|------------------>/64 prefix
RA
|------------------>/48 prefix,
DHCPv6 DNS, etc.
|------->/64 prefix
RA
|-------> DNS, etc.
DHCPv4/v6
Figure 2: Router CPE as Softwire InitiatorSo here's the flow 🦋 After the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) all go through, IPV6CP negotiates IPv6-over-PPP. That also lets the ISP assign the 64-bit Interface-Identifier to the router CPE, or run a uniqueness validation on the two interface identifiers at the two PPP ends [RFC5072]. Once IPv6-over-PPP is up, IPv6 Stateless Address Autoconfiguration / Neighbor Discovery runs over that link, and the LNS can tell the router CPE which prefix to use for stateless address autoconfiguration through a Router Advertisement (RA). DHCPv6 can handle IPv6 Prefix Delegation (e.g., delegating a prefix to be used within the home network [RFC3633]) and pass other non-address configuration options (such as DNS [RFC3646]) to the router CPE 🎀
3.1.3. Host behind CPE as Softwire Initiator 🧚
The CPE is IPv4-only 🙈 The Softwire Initiator (SI) is a dual-stack host sitting behind it, and it acts as an IPv6 host CPE. The IPv4 traffic SHOULD NOT traverse the Softwire. Check out Figure 3.
IPv6 or dual-stack IPv4-only dual-stack
|------------------||----------------------------||----------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....|v4-only|--| host |
R [network] | | [ network ] | CPE | | |
N | LNS | +-------+ |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6
PPP o L2TPv2 o UDP o IPv4 traffic
Softwire (SPH)
<------------------------------>
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|------------------------------>/64 prefix
RA
|------------------------------>DNS, etc.
DHCPv6
Figure 3: Host behind CPE as Softwire InitiatorSame deal as before, but now the ISP can assign the 64-bit Interface-Identifier to the host, or do a uniqueness validation for the two interface identifiers at the two PPP ends [RFC5072] 💖 After the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) succeed, IPV6CP negotiates IPv6-over-PPP. Then IPv6 Stateless Address Autoconfiguration / Neighbor Discovery runs over the IPv6-over-PPP link. The LNS can tell the host which prefix to use for stateless address autoconfiguration through a Router Advertisement (RA), while other non-address configuration options (such as DNS [RFC3646]) can be conveyed to the host via DHCPv6 🌈
3.1.4. Router behind CPE as Softwire Initiator 💜
The CPE is IPv4-only, and the Softwire Initiator (SI) is a dual-stack device behind it that acts as an IPv6 CPE router inside the home network 🏠 The IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 4.
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-------------------------||-------------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv6 ]....|v4/v6|..[IPv4-only]..|v4-only|---| router |
R [network] | | [ network ] | CPE | | | |
N | LNS | +-------+ | |LAC Client|
E +-----+ | +----------+
T |
---------+-----+
|v4/v6|
| host|
_ _ _ _ _ _ _ _ _ _ _ _ _ +-----+
()_ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6
PPP o L2TPv2 o UDP o IPv4 traffic
Softwire (SPH)
<--------------------------->
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|--------------------------->/64 prefix
RA
|--------------------------->/48 prefix,
DHCPv6 DNS, etc.
|----> /64
RA prefix
|----> DNS,
DHCPv6 etc.
Figure 4: Router behind CPE as Softwire InitiatorOnce the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPV6CP negotiates IPv6-over-PPP 🦋 That gives the ISP the option to assign the 64-bit Interface-Identifier to the v4/v6 router, or to run a uniqueness validation for the two interface identifiers at the two PPP ends [RFC5072]. After IPv6-over-PPP is up, IPv6 Stateless Address Autoconfiguration / Neighbor Discovery runs over the link, and the LNS can tell the v4/v6 router which prefix to use for stateless address autoconfiguration through a Router Advertisement (RA). DHCPv6 can be used for IPv6 Prefix Delegation (e.g., delegating a prefix to be used within the home network [RFC3633]), and it can convey other non-address configuration options (such as DNS [RFC3646]) to the v4/v6 router ✨
3.2. IPv4-over-IPv6 Softwires with L2TPv2 🦋
Okay so this next group of sub-sections flips everything around 🔄 They cover IPv4 connectivity (SPH) across an IPv6-only access network (STH) using a Softwire.
3.2.1. Host CPE as Softwire Initiator 🍓
The Softwire Initiator (SI) is the host CPE, which is directly connected to a modem and is dual-stack. There's no other gateway device in the picture. The IPv6 traffic SHOULD NOT traverse the Softwire. Figure 5 is right here 👑
IPv4 or dual-stack IPv6-only dual-stack
|------------------||-----------------||----------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 |
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| host CPE |
R [network] | | [ network ] | |
N | LNS | |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic
PPP o L2TPv2 o UDP o IPv6 (SPH)
Softwire
<------------------>
IPCP: capable of global IP assignment
and DNS, etc.
Figure 5: Host CPE as Softwire InitiatorAfter the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) go through, the IP Control Protocol (IPCP) negotiates IPv4-over-PPP 💅 That also lets the ISP assign a global IPv4 address to the host CPE. A global IPv4 address can also be assigned via DHCP. Other configuration options (such as DNS) can be conveyed to the host CPE via IPCP [RFC1877] or DHCP [RFC2132] 🫶
3.2.2. Router CPE as Softwire Initiator ✨
okay so the Softwire Initiator (SI) here is the router CPE 💅 and it's a dual-stack device, so it's giving both worlds 🌈 the IPv6 traffic SHOULD NOT traverse the Softwire. check Figure 6 🦋
IPv4 or dual-stack IPv6-only dual-stack Home
|------------------||-----------------||-------------------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 | +-----+
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| CPE |--|v4/v6|
R [network] | | [ network ] | | | host|
N | LNS | |LAC Client| +-----+
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic
PPP o L2TPv2 o UDP o IPv6 (SPH)
Softwire
<------------------>
IPCP: capable of global IP assignment
and DNS, etc.
|------------------>
DHCPv4: prefix, mask, PD
private/
|------> global
DHCP IP, DNS,
etc.
Figure 6: Router CPE as Softwire Initiatorso like, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPCP negotiates IPv4-over-PPP 🎀 which also gives the ISP the ability to assign a global IPv4 address to the router CPE. a global IPv4 address can also come from DHCP. other config stuff (like DNS) can get to the router CPE through IPCP [RFC1877] or DHCP [RFC2132]. and for IPv4 Prefix Delegation for the home network, DHCP [SUBNET-ALL] can be used 🍓
3.2.3. Host behind CPE as Softwire Initiator 🧚
the CPE is IPv6-only, and the Softwire Initiator (SI) is a dual-stack host sitting behind that IPv6 CPE. it acts as an IPv4 host CPE 💖 the IPv6 traffic SHOULD NOT traverse the Softwire. see Figure 7 👑
IPv4 or dual-stack IPv6-only dual-stack
|------------------||----------------------------||----------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....|v6-only|--| host |
R [network] | | [ network ] | CPE | | |
N | LNS | +-------+ |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4
PPP o L2TPv2 o UDP o IPv6 traffic
Softwire (SPH)
<------------------------------>
IPCP: capable of global IP assignment
and DNS, etc.
Figure 7: Host behind CPE as Softwire Initiatorin this one, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPCP negotiates IPv4-over-PPP 🌸 which also gives the ISP the ability to assign a global IPv4 address to the host. a global IPv4 address can also be assigned via DHCP. other config options (like DNS) can be conveyed to the host CPE via IPCP [RFC1877] or DHCP [RFC2132] 🫶
3.2.4. Router behind CPE as Softwire Initiator 💜
the CPE is IPv6-only, and the Softwire Initiator (SI) is a dual-stack device behind that IPv6-only CPE, acting as an IPv4 CPE router inside the home network 🔥 the IPv6 traffic SHOULD NOT traverse the Softwire. see Figure 8 🦋
IPv4 or dual-stack IPv6-only dual-stack
|------------------||-------------------------||------------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv4 ]....|v4/v6|..[IPv6-only]..|v6-only|---| router |
R [network] | | [ network ] | CPE | | | |
N | LNS | +-------+ | |LAC Client|
E +-----+ | +----------+
T |
--------+-----+
|v4/v6|
| host|
_ _ _ _ _ _ _ _ _ _ _ _ _ +-----+
()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4
PPP o L2TPv2 o UDP o IPv4 traffic
Softwire (SPH)
<--------------------------->
IPCP: assigns global IP address and DNS, etc.
|--------------------------->
DHCPv4: prefix, mask, PD
private/
|----> global
DHCP IP, DNS,
etc.
Figure 8: Router behind CPE as Softwire Initiatorafter the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPCP negotiates IPv4-over-PPP, which also gives the ISP the ability to assign a global IPv4 address to the v4/v6 router ⭐ a global IPv4 address can also come via DHCP. other config (like DNS) can reach the v4/v6 router through IPCP [RFC1877] or DHCP [RFC2132]. and for IPv4 Prefix Delegation for the home network, DHCP [SUBNET-ALL] can be used 🍓
4. References to Standardization Documents 📚
okay so this section lists and groups documents from the Internet standardization that describe the technologies used to design the framework of the Softwire "Hub and Spoke" solution 🕸️ it's all about reusing as many existing standards as possible, which is honestly so iconic 😭 this list has both Standards Track (Proposed Standard, Draft Standard, and Standard) and Informational documents. the list of documents and their status should only be only used for description purposes.
4.1. L2TPv2
RFC 2661 "Layer Two Tunneling Protocol 'L2TP'" [RFC2661].
- For both IPv4 and IPv6 payloads (SPH), support is complete.
- For both IPv4 and IPv6 transports (STH), support is complete.
4.2. Securing the Softwire Transport 🔐
RFC 3193 "Securing L2TP using IPsec" [RFC3193].
RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948].
- IPsec supports both IPv4 and IPv6 transports.
4.3. Authentication, Authorization, and Accounting 🎟️
RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" [RFC2865].
RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol Support" [RFC2867].
RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868].
RFC 3162 "RADIUS and IPv6" [RFC3162].
4.4. MIB 🗂️
RFC 1471 "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol" [RFC1471].
RFC 1473 "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol" [RFC1473].
RFC 3371 "Layer Two Tunneling Protocol "L2TP" Management Information Base" [RFC3371].
RFC 4087 "IP Tunnel MIB" [RFC4087].
- Both IPv4 and IPv6 transports are supported.
4.5. Softwire Payload Related 🎁
4.5.1. For IPv6 Payloads 💎
RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861].
RFC 4862 "IPv6 Stateless Address Autoconfiguration" [RFC4862].
RFC 5072 "IP Version 6 over PPP" [RFC5072].
RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3315].
RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" [RFC3633].
RFC 3646 "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3646].
RFC 3736 "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6" [RFC3736].
4.5.2. For IPv4 Payloads 🌷
RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" [RFC1332].
RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661].
RFC 1877 "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses" [RFC1877].
RFC 2131 "Dynamic Host Configuration Protocol" [RFC2131].
RFC 2132 "DHCP Options and BOOTP Vendor Extensions" [RFC2132].
DHCP Subnet Allocation "Subnet Allocation Option".
- Work in progress, see [SUBNET-ALL].
5. Softwire Establishment ✨
okay so a Softwire comes together in three steps, and there's an optional glow-up step 0 that can happen first 🎀 (check Figure 9 🦋). First, an L2TPv2 tunnel with a single session gets set up from the SI to the SC. Second, a PPP session runs over that L2TPv2 session and the SI gets an address 💅. Third, the SI can optionally grab extra info through DHCP, like a delegated prefix and DNS servers 🫶
SC SI
| |
|<-------------IKEv1------------->| Step 0
| | IPsec SA establishment
| | (optional)
| |
|<-------------L2TPv2------------>| Step 1
| | L2TPv2 Tunnel establishment
| |
|<--------------PPP-------------->| Step 2
|<-----Endpoint Configuration---->| PPP and Endpoint
| | configuration
| |
|<------Router Configuration----->| Step 3
| | Additional configuration
| | (optional)Figure 9: Steps for the Establishment of a Softwire
Figure 10 is where we zoom in on every single step 🔍✨
SC SI
| |
| | Step 0
|<------------IKEv1-------------->| = IKEv1 (Optional)
| |
| | Step 1
|<------------SCCRQ---------------| -
|-------------SCCRP-------------->| |
|<------------SCCCN---------------| |
|<------------ICRQ----------------| | L2TPv2
|-------------ICRP--------------->| |
|<------------ICCN----------------| -
| |
| | Step 2
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP
|--------Configuration-Ack------->| | LCP
|<-------Configuration-Ack--------| -
| |
|-----------Challenge------------>| - PPP Authentication
|<----------Response--------------| | (Optional - CHAP)
|------------Success------------->| -
| |
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP NCP
|--------Configuration-Ack------->| | (IPV6CP or IPCP)
|<-------Configuration-Ack--------| -
| |
|<------Router-Solicitation-------| - Neighbor Discovery
|-------Router-Advertisement----->| | (IPv6 only)
| | -
| |
| | Step3
| | DHCP (Optional)
|<-----------SOLICIT--------------| -
|-----------ADVERTISE------------>| | DHCPv6
|<---------- REQUEST--------------| | (IPv6 SW, Optional)
|-------------REPLY-------------->| -
| | or
|<---------DHCPDISCOVER-----------| -
|-----------DHCPOFFER------------>| | DHCPv4
|<---------DHCPREQUEST------------| | (IPv4 SW, Optional)
|------------DHCPACK------------->| -Figure 10: Detailed Steps in the Establishment of a Softwire
Quick breakdown of the vibes 💖: step 0 (IPsec) is optional 🙈. Step 1 (L2TPv2) is the stuff in Section 5.1. In step 2, the PPP NCP negotiation uses IPV6CP for IPv6-over-IPv4 Softwires and IPCP for IPv4-over-IPv6 Softwires (see Section 5.2.4) 🌸. In step 3, the optional DHCP negotiation uses DHCPv6 for IPv6-over-IPv4 Softwires and DHCPv4 for IPv4-over-IPv6 Softwires (see Section 5.4) 🧚. And ngl, for IPv6-over-IPv4 Softwires, the DHCPv6 exchange for non-address stuff (like DNS) can use Stateless DHCPv6, which is that two-message Information-Request and Reply dance (see Section 1.2 of [RFC3315] and [RFC3736]) 🦋✨
5.1. L2TPv2 Tunnel Setup 🌈
okay so [RFC2661] originally existed to give private network access to end users who were hanging out on a public network 💜 In the L2TPv2 incoming call model, the end user connects to an L2TP Access Concentrator (LAC). The LAC then starts an L2TPv2 tunnel to an L2TP Network Server (LNS). The LNS then passes the end user's traffic between that tunnel and the private network 🏠
In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) plays the LAC Client role, and the Softwire Concentrator (SC) plays the LNS role 👑
In the Softwire model, an L2TPv2 packet MUST be carried over UDP 🔥 The underlying IP version can be IPv4 or IPv6, depending on which Softwire scenario you're in 🍓
In the next sections, the word "Tunnel" follows the definition from Section 1.2 of [RFC2661], which is: "The Tunnel consists of a Control Connection and zero or more L2TP Sessions" 🫶
5.1.1. Tunnel Establishment 🦋
Figure 11 shows the messages and Attribute Value Pairs (AVPs) used to set up a tunnel between an SI (LAC) and an SC (LNS) 💅 These are only a subset of the ones in [RFC2661], because Softwires only use part of L2TPv2's functionality. The Control Connection Management AVPs that apply to Softwires are grouped into Required AVPs and Optional AVPs for each control message. For each control message, the Required AVPs include all the "MUST be present" AVPs from [RFC2661] for that message, and the Optional AVPs include the "MAY be present" AVPs from [RFC2661] that are used in the Softwire context on that message. Also, in the Softwire environment, the SI always initiates the tunnel 🚀 And L2TPv2 AVPs SHOULD NOT be hidden 🙈
SC SI
|<--------SCCRQ---------|
Required AVPs:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
Optional AVPs:
Receive Window Size
Challenge
Firmware Revision
Vendor Name
|---------SCCRP-------->|
Required AVPs:
Message Type
Protocol Version
Framing Capabilities
Host Name
Assigned Tunnel ID
Optional AVPs:
Firmware Revision
Vendor Name
Receive Window Size
Challenge
Challenge Response
|<--------SCCCN---------|
Required AVPs:
Message Type
Optional AVPs:
Challenge ResponseFigure 11: Control Connection Establishment
Now the session part 🎀 In L2TPv2 in general, one tunnel between a LAC and LNS can carry data for multiple users, with each user getting their own L2TPv2 session inside it. In the Softwire world, though, the tunnel only carries one user's info, so there's only ever one L2TPv2 session per tunnel 👑 Figure 12 shows the messages and AVPs used to set up that session between an SI (LAC) and an SC (LNS). Same deal as before: it's only a subset of [RFC2661], and the Session Management AVPs that apply to Softwires get grouped into Required and Optional AVPs per control message. The Required AVPs include all the "MUST be present" AVPs from [RFC2661] for that message, and the Optional AVPs include the "MAY be present" AVPs from [RFC2661] used in the Softwire context. The SI always initiates the session 🦋 Softwire sessions only use the incoming call model, so no outgoing or analog calls (sessions) are permitted 🚫 And yep, L2TPv2 AVPs SHOULD NOT be hidden 💖
SC SI
|<--------ICRQ---------|
Required AVPs:
Message Type
Assigned Session ID
Call Serial Number
|---------ICRP-------->|
Required AVPs:
Message Type
Assigned Session ID
|<--------ICCN---------|
Required AVPs:
Message Type
(Tx) Connect Speed
Framing TypeFigure 12: Session Establishment
The next sub-sections (5.1.1.1 through 5.1.1.3) go deeper into the Control Connection and Session establishment AVPs (check Figures 11 and 12 for the message flows). They cover which AVPs are required, optional, and not relevant for setting up the L2TPv2 Tunnel of a Softwire 🧚 Any L2TPv2 messages and flows that aren't explicitly described in those sections get handled the way [RFC2661] says 💜
Last but definitely not least: the mechanism for hiding AVP Attribute values, from Section 4.3 of [RFC2661], exists to protect sensitive control message data like usernames, user passwords, or IDs, so they aren't sent in the clear 🔐 Since the AVPs used in L2TP messages for Softwire establishment don't carry that kind of sensitive data, L2TPv2 AVPs SHOULD NOT be hidden ✨🫶
5.1.1.1. AVPs Required for Softwires ✨
Okay bestie, this part is all about the AVPs that [RFC2661] says MUST be in certain messages 👑, and how they actually show up in the softwire context 💅. It basically gathers every Required AVP from the control messages in Section 5.1.1 and adds softwire-specific guidance.
Host Name AVP 🎀
This one is required in SCCRQ and SCCRP messages. It MAY be used to authenticate users, in which case it would contain a user identification. If it's not used to authenticate users, it may be used for logging purposes 📝.
Framing Capabilities AVP 🦋
Both the synchronous (S) and asynchronous (A) bits SHOULD be set to 1. This AVP SHOULD be ignored by the receiver.
Framing Type AVP 🍓
The synchronous bit SHOULD be set to 1 and the asynchronous bit to 0. This AVP SHOULD be ignored by the receiver.
(Tx) Connect Speed AVP 🧚
(Tx) Connect Speed is a required AVP, but it's not meaningful in the Softwire context 🙈. Its value SHOULD be set to 0 and ignored by the receiver.
Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call Serial Number AVP, and Assigned Session ID AVP 💜
As defined in [RFC2661].
5.1.1.2. AVPs Optional for Softwires 🌸
This section covers AVPs that are Optional (not required by [RFC2661]) but still show up in the softwire context. It pulls together all the Optional AVPs from the control messages in Section 5.1.1 and gives softwire-specific tips.
Challenge AVP and Challenge Response AVP 🔐
These aren't required, but they're necessary to implement tunnel authentication. Tunnel authentication happens right at the start of L2TPv2 tunnel creation, so it can be really helpful in preventing denial-of-service (DoS) attacks 🛡️. See Section 5.1.1 of [RFC2661].
The usage of these AVPs in L2TP messages is OPTIONAL, but they SHOULD be implemented in the SC 🫶.
Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP 🌈
As defined in [RFC2661].
5.1.1.3. AVPs Not Relevant for Softwires 🙅♀️
L2TPv2 specifies a ton of AVPs that are allowed for a given message but are totally irrelevant to Softwires 💀. They can be irrelevant because they don't apply to the Softwire establishment flow (for example, they're only used in the Outgoing Call establishment message exchange, while Softwires only use the Incoming Call message flow), or because they're Optional AVPs that just aren't used. The L2TPv2 AVPs that DO matter for Softwires were covered in Sections 5.1.1, 5.1.1.1, and 5.1.1.2 ✨.
Softwire implementations SHOULD NOT send AVPs that aren't relevant to Softwires. However, they SHOULD ignore them when they're received. This keeps things simple when you're building Softwire applications on top of existing L2TPv2 implementations 🧩.
5.1.2. Tunnel Maintenance 💓
Periodically, the SI/SC MUST transmit a message to the peer to detect tunnel or peer failure and to maintain NAT/NAPT contexts. The L2TPv2 HELLO message gives you a simple, low-overhead way to do this 🫧.
The default values specified in [RFC2661] for L2TPv2 HELLO messages could result in a dead-end detection time of 83 seconds 😬. Although these retransmission timers and counters SHOULD be configurable (see Section 5.8 of [RFC2661]), those values may not be adapted for every situation, like when quicker dead-end detection is required, or when the NAT/NAPT context needs to be refreshed more frequently. In those cases, the SI/SC MAY use LCP ECHO messages (Echo-Request and Echo-Reply codes) described in [RFC1661] together with L2TPv2 HELLO. When they're used, LCP ECHO messages SHOULD have a re-emission timer lower than the value for L2TPv2 HELLO messages 🏃♀️.
The default value recommended in Section 6.5 of [RFC2661] for the HELLO message retransmission interval is 60 seconds ⏰. When used, a set of suggested values (included here only for guidance) for the LCP ECHO message request interval is a default of 30 seconds, a minimum of 10 seconds, and a maximum of the lesser of the configured L2TPv2 HELLO retransmission interval and 60 seconds 🌷.
5.1.3. Tunnel Teardown 🫡
Either the SI or SC can tear down the session and the tunnel. This is done as specified in Section 5.7 of [RFC2661], by sending a StopCCN control message 🛑. There's no action specific to Softwires in this case, so nothing extra to see here 💅.
5.1.4. Additional L2TPv2 Considerations 🧠
In the Softwire "Hub and Spoke" framework, L2TPv2 is layered on top of UDP, as part of an IP-in-IP tunnel. Section 8.1 of [RFC2661] describes L2TP over UDP/IP 🎀. That means the UDP guidelines in [RFC5405] apply, since they cover UDP tunneling scenarios carrying IP-based traffic. Section 3.1.3 of [RFC5405] says that, for this case, specific congestion control mechanisms for the tunnel are not necessary 🦋. Also, Section 3.2 of [RFC5405] gives message size guidelines for the encapsulating (outer) datagrams, including the recommendation to implement Path MTU Discovery (PMTUD) 📏.
5.2. PPP Connection 🔌
This section describes the PPP negotiations between the SI and SC in the Softwire context ✨.
5.2.1. MTU 📦
The MTU of the PPP link presented to the SPH SHOULD be the link MTU minus the size of the IP, UDP, L2TPv2, and PPP headers together 🧮. On an IPv4 link with an MTU equal to 1500 bytes, this could typically mean a PPP MTU of 1460 bytes. When the link is managed by IPsec, this MTU SHOULD be lowered to take the ESP encapsulation into account (see [SW-SEC]) 🔒. The value for the MTU may also vary according to the size of the L2TP header, as defined by the leading bits of the L2TP message header (see [RFC2661]). Additionally, see [RFC4623] for a detailed discussion of fragmentation issues 🧩.
5.2.2. LCP 🤝
Once the L2TPv2 session is established, the SI and SC start the PPP connection by negotiating LCP as described in [RFC1661]. The Address-and-Control-Field-Compression configuration option (ACFC) [RFC1661] MAY be rejected 🙅♀️.
5.2.3. Authentication 🗝️
After completing LCP negotiation, the SI and SC MAY optionally perform authentication. If authentication is chosen, Challenge Handshake Authentication Protocol (CHAP) [RFC1994] authentication MUST be supported by both the Softwire Initiator and Softwire Concentrator 💖. Other authentication methods, such as Microsoft CHAP version 1 (MS-CHAPv1) [RFC2433] and Extensible Authentication Protocol (EAP) [RFC3748], MAY be supported 🌟.
A detailed discussion of Softwire security is contained in [SW-SEC] 🔥. Go read it, it's serious stuff 😭.
5.2.4. IPCP 🌐
The only Network Control Protocol (NCP) negotiated in the Softwire context is IPV6CP (see Section 5.2.4.1) for IPv6 as SPH, and IPCP (see Section 5.2.4.2) for IPv4 as SPH 💅.
5.2.4.1. IPV6CP 🧚♀️
In the IPv6-over-IPv4 scenarios (see Section 3.1), after the optional authentication phase, the Softwire Initiator MUST negotiate IPV6CP as defined in [RFC5072]. IPV6CP gives you a way to negotiate a unique 64-bit Interface-Identifier to be used for address autoconfiguration at the local end of the link 🪪.
5.2.4.2. IPv4CP 🎀
In the IPv4-over-IPv6 scenarios (see Section 3.2), a Softwire Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to get an IPv4 address from the SC 🏠. IPCP MAY also be used to get DNS information, as described in [RFC1877] 🗺️.
5.3. Global IPv6 Address Assignment to Endpoints 🌍
In several scenarios defined in Section 3.1, global IPv6 addresses are expected to be allocated to Softwire endpoints (on top of the Link-Local addresses autoconfigured using the IPV6CP negotiated interface identifier) 💫. The Softwire Initiator assigns global IPv6 addresses using the IPV6CP negotiated interface identifier and Stateless Address Autoconfiguration [RFC4862], and/or Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] (as described in Section 5 of [RFC5072]), and/or DHCPv6 [RFC3315] 🫶.
The Softwire Initiator of an IPv6 Softwire MUST send a Router Solicitation message to the Softwire Concentrator after IPV6CP is completed. The Softwire Concentrator MUST answer with a Router Advertisement. This message MUST contain the global IPv6 prefix of the PPP link if Neighbor Discovery is used to configure addresses of Softwire endpoints 🧭.
If DHCPv6 is available for address delegation, the M bits of the Router Advertisement SHOULD be set. The Softwire Initiator MUST then send a DHCPv6 Request to configure the address of the Softwire endpoint 📬.
Duplicate Address Detection ([RFC4861]) MUST be performed on the Softwire in both cases 🔍.
5.4. DHCP 📮
The Softwire Initiator MAY use DHCP to get additional information, such as delegated prefixes and DNS servers 🌷.
5.4.1. DHCPv6 ❄️
In the scenarios in Section 3.1, if the SI supports DHCPv6, it SHOULD send a Solicit message to verify whether more information is available 👀.
If an SI establishing an IPv6 Softwire acts as a router (that is, in the scenarios in Sections 3.1.2 and 3.1.4), it MUST include the Identity Association for Prefix Delegation (IA_PD) option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix 🙌.
When delegating an IPv6 prefix to the SI by returning a DHCPv6 Advertise message with the IA_PD and IP_PD Prefix options [RFC3633], the SC SHOULD inject a route for this prefix in the IPv6 routing table, so traffic gets forwarded to the relevant Softwire 🚀.
Configuration of DNS MUST be done as specified in [RFC3646] and transmitted according to [RFC3315] and [RFC3736]. In general, all DHCPv6 options MUST be transmitted according to [RFC3315] and [RFC3736] 📜.
5.4.2. DHCPv4 🧃
An SI establishing an IPv4 Softwire MAY send a DHCP request containing the Subnet Allocation option [SUBNET-ALL]. This practice isn't common, but it may be used to connect IPv4 subnets using Softwires, as defined in Sections 3.2.2 and 3.2.4 🌈.
One Subnet-Request suboption MUST be configured with the 'h' bit set to '1', since the SI is expected to perform the DHCP server function 🧑💻. The 'i' bit of the Subnet-Request suboption SHOULD be set to '0' the first time a prefix is requested, and to '1' on subsequent requests if a prefix has been allocated. The Prefix length suboption SHOULD be 0 by default. If the SI is configured to support only specific prefix lengths, it SHOULD specify the longest (smallest) prefix length it supports 🎯.
If the SI was previously assigned a prefix from that same SC, it SHOULD include the Subnet-Information suboption with the prefix it was previously assigned. The 'c' and 's' bits of the suboption SHOULD be set to '0' 🔁.
In the scenarios in Section 3.2, when delegating an IPv4 prefix to the SI, the SC SHOULD inject a route for this prefix in the IPv4 routing table, so traffic gets forwarded to the relevant Softwire 🛣️.
6. Considerations about the Address Provisioning Model 🏡
This section describes how a Softwire Concentrator may manage delegated addresses for Softwire endpoints and for subnets behind the Softwire Initiator 🗂️. One common practice is to aggregate endpoints' addresses and delegated prefixes into one prefix routed to the SC. The main benefit is that it eases the routing scheme by isolating succeeding route injections on the SC (when delegating new prefixes for the SI) ✨.
6.1. Softwire Endpoints' Addresses 💌
6.1.1. IPv6 🌐
okay so a Softwire Concentrator should hand out globally routable addresses to Softwire endpoints 💖 but if the endpoints are just chilling in a private network with zero global connectivity, Unique Local Addresses (ULAs) [RFC4193] are a valid look too ✨ Either way, a single /64 should be assigned to the Softwire so both endpoints can get addressed 🎀
global addresses or ULAs must be assigned to endpoints when the scenario "Host CPE as Softwire Initiator" (described in Section 3.1.1) is considered to be deployed 🫶 for every other scenario, link-local addresses may also be used 🧚
6.1.2. IPv4 🦋
a Softwire Concentrator may provide either globally routable or private IPv4 addresses 💅 when the endpoints use IPv4 private addresses [RFC1918], it is not recommended to delegate an IPv4 private prefix to the SI, because that can lead to a nested-NAT situation 🙈 nested NAT is a whole mess, bestie 💀
the endpoints of the PPP link use host addresses (i.e., /32), negotiated using IPCP 🌸
6.2. Delegated Prefixes 🍓
6.2.1. IPv6 Prefixes 🌈
delegated IPv6 prefixes should be of global scope if the IPv6 addresses assigned to endpoints are global ✨ using ULAs is not recommended when the subnet is connected to the global IPv6 Internet 😭 when you're using IPv6 ULAs on the endpoints, the delegated IPv6 prefix may be either of global or ULA scope 💜
delegated IPv6 prefixes are between /48 and /64 in length 👑 when an SI receives a prefix shorter than 64, it can assign different /64 prefixes to each of its interfaces 🔥 an SI receiving a single /64 is expected to perform bridging if more than one interface is available (e.g., wired and wireless) 🫧
6.2.2. IPv4 Prefixes 💖
delegated IPv4 prefixes should be routable within the address space used by assigned IPv4 addresses 🌷 delegating non-routable IPv4 prefixes (i.e., private IPv4 prefix over public IPv4 addresses or another class of private IPv4 addresses) is not recommended as a practice for provisioning, and address translation should be considered in these cases 🙃 the prefix length is between /8 and /30 🎀
6.3. Possible Address Provisioning Scenarios 🧩
this section summarizes the different scenarios for address provisioning with the considerations given in the previous sections 💅
6.3.1. Scenarios for IPv6 🌸
this table describes the possible combinations of IPv6 address scope for endpoints and delegated prefixes 📊
+------------------+-----------------------+------------------------+
| Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 |
| Address | Prefix | Prefix |
+------------------+-----------------------+------------------------+
| Link Local | Possible | Possible |
| | | |
| ULA | Possible | Possible |
| | | |
| Global | Possible | Possible, but Not |
| | | Recommended |
+------------------+-----------------------+------------------------+
Table 1: Scenarios for IPv66.3.2. Scenarios for IPv4 🦋
this table describes the possible combinations of IPv4 address scope for endpoints and delegated prefixes 💜
+-------------+-----------------+-----------------------------------+
| Endpoint | Delegated | Delegated Private IPv4 Prefix |
| IPv4 | Public IPv4 | |
| Address | Prefix | |
+-------------+-----------------+-----------------------------------+
| Private | Possible | Possible, but Not Recommended |
| IPv4 | | when using NAT (cf. |
| | | Section 6.1.2) |
| | | |
| Public IPv4 | Possible | Possible, but NAT usage is |
| | | recommended (cf. Section 6.2.2) |
+-------------+-----------------+-----------------------------------+
Table 2: Scenarios for IPv47. Considerations about Address Stability 🦋
a Softwire can provide stable addresses even if the underlying addressing scheme changes, which is the opposite of automatic tunneling ✨ a Softwire Concentrator should always provide the same address and prefix to a reconnecting user 💖 however, if the goal of the Softwire service is to give a roaming user a temporary address, it may be provisioned to provide only a temporary address 🌙
the address and prefix are expected to change when reconnecting to a different Softwire Concentrator 🔄 however, an organization providing a Softwire service may provide the same address and prefix across different Softwire Concentrators, at the cost of a more fragmented routing table 🧩 the routing fragmentation issue may be limited if the prefixes are aggregated in a location topologically close to the SC 🫶 this would be the case, for example, if several SCs are put in parallel for load-balancing purposes 💅
8. Considerations about RADIUS Integration 🔐
the Softwire Concentrator is expected to act as a client to a AAA server, for example, a RADIUS server 🙌 during the PPP authentication phase, the RADIUS server may return additional information in the form of attributes in the Access-Accept message 🎁
the Softwire Concentrator may include the Tunnel-Type and Tunnel-Medium-Type attributes [RFC2868] in the Access-Request messages to provide a hint of the type of Softwire being configured 💡
8.1. Softwire Endpoints 🧚
8.1.1. IPv6 Softwires 🌈
if the RADIUS server includes a Framed-Interface-Id attribute [RFC3162], the Softwire Concentrator must send it to the Softwire Initiator in the Interface-Identifier field of its IPV6CP Configuration Request message 🫧
if the Framed-IPv6-Prefix attribute [RFC3162] is included, that prefix must be used in the router advertisements sent to the SI 📡 if Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC must choose a prefix from that pool to send RAs 🎀
8.1.2. IPv4 Softwires 💖
if the Framed-IP-Address attribute [RFC2865] is present, the Softwire Concentrator must provide that address to the Softwire Initiator during IPCP address negotiation 🌸 that means when the Softwire Initiator requests an IP address from the Softwire Concentrator, the address provided should be the Framed-IP-Address 💜
8.2. Delegated Prefixes 🍓
8.2.1. IPv6 Prefixes 👑
if the attribute Delegated-IPv6-Prefix [RFC4818] is present in the RADIUS Access-Accept message, it must be used by the Softwire Concentrator for the delegation of the IPv6 prefix 🔥 since the prefix delegation is performed by DHCPv6 and the attribute is linked to a username, the SC must associate the DHCP Unique Identifier (DUID) of a DHCPv6 request to the tunnel it came from and its user 🫶
interaction between RADIUS, PPP, and the DHCPv6 server may follow the mechanism proposed in [RELAY-RAD] 🧠 in this case, during the Softwire authentication phase, PPP collects the RADIUS attributes for the user, such as Delegated-IPv6-Prefix 📥 a specific DHCPv6 relay is assigned to the Softwire 🔗 the DHCPv6 relay fills in these attributes in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option before forwarding the DHCPv6 requests to the DHCPv6 server 🚀
8.2.2. IPv4 Prefixes 🌷
RADIUS does not define an attribute for the delegated IPv4 prefix 🙃 attributes indicating an IPv4 prefix and its length (for instance, the combination of the Framed-IP-Address and Framed-IP-Netmask attributes [RFC2865]) may be used by the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator 🎀 the Softwire Concentrator must add a corresponding route with the Softwire Initiator as next-hop 🛣️
as this practice had been used, including the Framed-IP-Netmask attribute along with the Framed-IP-Address attribute tells the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator 🧃 (e.g., in the IPv4-over-IPv6 scenarios where the Softwire Initiator is a router, see Sections 3.2.2 and 3.2.4), since the SC should forward packets destined to any IPv4 address in the prefix to the SI 📦
9. Considerations for Maintenance and Statistics 📊
existing protocol mechanics for conveying adjunct or accessory information for logging purposes, including L2TPv2 and RADIUS methods, can include informational text saying that the behavior is according to the Softwire "Hub and Spoke" framework (following the implementation details specified in this document) 📝
9.1. RADIUS Accounting 🧾
RADIUS Accounting for L2TP and PPP is documented (see Section 4.3) 📚
when deploying Softwire solutions, operators may have difficulty telling apart the address family of the traffic reported in accounting information from RADIUS 🤔 this problem and some potential solutions are described in [SW-ACCT] 💡
9.2. MIBs 🧮
MIB support for L2TPv2 and PPP is documented (see Section 4.4) 📖 also, see [RFC4293] 🌟
10. Security Considerations 🔥
okay bestie, this section is seriously important, so read it carefully 🚨
one design goal of the "Hub and Spoke" problem is to very strongly consider the reuse of already deployed protocols (see [RFC4925]) 🔁 another design goal is a solution with very high scaling properties 📈 L2TPv2 [RFC2661] is the phase 1 protocol used in the Softwire "Hub and Spoke" solution space, and the L2TPv2 security considerations apply to this document (see Section 9 of [RFC2661]) 🛡️
the L2TPv2 Softwire solution adds the following considerations:
- L2TP Tunnel Authentication (see Sections 5.1.1 and 9.1 of [RFC2661]) provides authentication at tunnel setup 🔐 it may be used to limit DoS attacks by authenticating the tunnel before L2TP and PPP resources are allocated 🚫
- In a Softwire environment, L2TPv2 AVPs do not transport sensitive data, so the L2TPv2 AVP hiding mechanism is not used (see Section 5.1.1) 🙈
- PPP CHAP [RFC1994] provides basic user authentication 🧁 other authentication protocols may additionally be supported (see Section 5.2.3) 🎀
L2TPv2 can also be secured with IPsec to provide privacy, integrity, and replay protection 🔒 currently, there are two different solutions for securing L2TPv2 with IPsec:
- Securing L2TPv2 using IPsec "version 2" (IKEv1) is specified in [RFC3193], [RFC3947], and [RFC3948] 📜 when L2TPv2 is used in the Softwire context, the voluntary tunneling model applies 🪄 [RFC3193] describes the interaction between IPsec and L2TPv2, and is deployed 🚀 [RFC3193] MUST be supported, given that deployed technology must be very strongly considered [RFC4925] for this 'time-to-market' solution ⏰
- [SW-SEC] also specifies a new (incompatible) solution for securing L2TPv2 with IPsec "version 3" (IKEv2) 🆕 Section 3.5 of [SW-SEC] describes the advantages of using IKEv2, and this solution needs to be considered for future phases 🔮
additional discussion of Softwire security is contained in [SW-SEC] 📚✨
11. Acknowledgements ✨
okay so the authors gave a huge shoutout to everyone who helped make this doc happen 🫶 first up: Florent Parent, Jordi Palet Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, Francis Dupont, Ralph Droms, Hemant Singh, and Alain Durand. literally the dream team 💖
they also thanked everyone who showed up to the Softwires interim meetings in Hong Kong, China, and Barcelona, Spain 🌏 the minutes for the China University - Hong Kong meeting (February 23-24, 2006) live at <http://www.ietf.org/proceedings/06mar/isoftwire.html> 📝 and the minutes for the Polytechnic University of Catalonia - Barcelona meeting (September 14-15, 2006) are at <http://www.ietf.org/proceedings/06nov/isoftwire.html> 🎀 there's also a Softwires auxiliary page at <http://bgp.nu/~dward/softwires/> with extra meeting info if you want to dig deeper 🕵️♀️
and during and after the IETF Last Call, Jari Arkko, David Black, Lars Eggert, Pasi Eronen, and Dan Romascanu dropped super useful comments and discussion 🔥 they really did the most, no cap 👑
12. References 📚
12.1. Normative References
These are the must-reads, bestie 💅
[RFC1332] McGregor, G., "The PPP Internet Protocol Control
Protocol (IPCP)", RFC 1332, May 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S.
Booth, "Securing L2TP using IPsec", RFC 3193,
November 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two
Tunneling Protocol "L2TP" Management Information Base",
RFC 3371, August 2002.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for
Dynamic Host Configuration Protocol (DHCP) version 6",
RFC 3633, December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP) Service for IPv6", RFC 3736,
April 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
Attribute", RFC 4818, April 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007.12.2. Informative References
these ones are more like bonus reading 🧚 totally worth a look if you're curious
[RELAY-RAD] Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option",
Work in Progress, February 2006.
[RFC1471] Kastenholz, F., "The Definitions of Managed Objects for
the Link Control Protocol of the Point-to-Point
Protocol", RFC 1471, June 1993.
[RFC1473] Kastenholz, F., "The Definitions of Managed Objects for
the IP Network Control Protocol of the Point-to-Point
Protocol", RFC 1473, June 1993.
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control
Protocol Extensions for Name Server Addresses",
RFC 1877, December 1995.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998.
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867,
June 2000.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
Holdrege, M., and I. Goyret, "RADIUS Attributes for
Tunnel Protocol Support", RFC 2868, June 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
March 2005.
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006.
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-
to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623,
August 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP",
BCP 127, RFC 4787, January 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, December 2007.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage
Guidelines for Application Designers", BCP 145,
RFC 5405, November 2008.
[SUBNET-ALL] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp,
"Subnet Allocation Option", Work in Progress,
March 2009.
[SW-ACCT] Stevant, B., Toutain, L., Dupont, F., and D. Binet,
"Accounting on Softwires", Work in Progress,
April 2009.
[SW-SEC] Yamamoto, S., Williams, C., Parent, F., and H. Yokota,
"Softwire Security Analysis and Requirements", Work
in Progress, May 2009.Authors' Addresses 🦋
here's where you can find the crew who wrote this, bestie 💜
Bill Storer
Cisco Systems
170 W Tasman Dr
San Jose, CA 95134
USA
EMail: bstorer@cisco.com
Carlos Pignataro (editor)
Cisco Systems
7200 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
USA
EMail: cpignata@cisco.com
Maria Alice Dos Santos
Cisco Systems
170 W Tasman Dr
San Jose, CA 95134
USA
EMail: mariados@cisco.com
Bruno Stevant (editor)
TELECOM Bretagne
2 rue de la Chataigneraie CS17607
Cesson Sevigne, 35576
France
EMail: bruno.stevant@telecom-bretagne.eu
Laurent Toutain
TELECOM Bretagne
2 rue de la Chataigneraie CS17607
Cesson Sevigne, 35576
France
EMail: laurent.toutain@telecom-bretagne.eu
Jean-Francois Tremblay
Videotron Ltd.
612 Saint-Jacques
Montreal, QC H3C 4M8
Canada
EMail: jf@jftremblay.comthat's the whole doc, bestie 🎀 you did amazing, no cap 💖
📦 where this page comes from
- ietf: rfc5571 2009-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms