RFC 4925
Softwire Problem Statement
Softwire Problem Statement 🦋
Okay bestie, here's the title block 💖. This is RFC 4925, "Softwire Problem Statement," from July 2007. It was written by X. Li, Ed. (CERNET), S. Dawkins, Ed. (Huawei), D. Ward, Ed. (Cisco Systems), and A. Durand, Ed. (Comcast). It's Informational 📚, and the title block doesn't say it obsoletes or updates anything 🫶.
Status of This Memo ✨
This memo gives info to the Internet community 🌸. It is not an Internet standard of any kind, so don't treat it like one 🙈. Distribution of this memo is unlimited, so share it with everyone 💅.
Copyright Notice 🎀
Copyright (C) The IETF Trust (2007).
Abstract 🔥
This doc captures the problem statement for the Softwires Working Group 💜. That group is building standards for the discovery, control, and encapsulation methods used to connect IPv4 networks across IPv6-only networks, and IPv6 networks across IPv4-only networks. The standards are meant to encourage multiple, inter-operable vendor implementations, and they get there by identifying existing standard protocols, and extending them where needed, to solve a chosen set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. The doc describes the specific problems ("Hubs and Spokes" and "Mesh") that the Softwires standards will solve. It also names some requirements (and non-requirements) so the problem scope is clear 🦋.
Table of Contents 📋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Hubs and Spokes Problem . . . . . . . . . . . . . . . . . . . 6
2.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Non-Upgradable CPE Router . . . . . . . . . . . . . . . . 9
2.3. Network Address Translation (NAT) and Port Address
Translation (PAT) . . . . . . . . . . . . . . . . . . . . 10
2.4. Static Prefix Delegation . . . . . . . . . . . . . . . . . 10
2.5. Softwire Initiator . . . . . . . . . . . . . . . . . . . . 11
2.6. Softwire Concentrator . . . . . . . . . . . . . . . . . . 11
2.7. Softwire Concentrator Discovery . . . . . . . . . . . . . 12
2.8. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.9. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11.1. Authentication, Authorization, and Accounting
(AAA) . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11.2. Privacy, Integrity, and Replay Protection . . . . . . 13
2.12. Operations and Management (OAM) . . . . . . . . . . . . . 13
2.13. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 13
3. Mesh Problem . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Persistence, Discovery, and Setup Time . . . . . . . . . . 16
3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5. Softwire Encapsulation . . . . . . . . . . . . . . . . . . 17
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. Principal Authors . . . . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 201. Introduction ✨
The Softwires Working Group is standardizing discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks, and IPv6 networks across IPv4-only networks 🧚. The whole goal is to encourage multiple, inter-operable vendor implementations. This doc describes the specific problems ("Hubs and Spokes" and "Mesh") that the Softwires standards will solve. It also lists some requirements (and non-requirements) to better show the problem scope. A few generic assumptions come first:
- Local Area Networks will often support both protocol families so they can handle IPv4-only apps, IPv6-only apps, and dual-stack apps too 💜. Global reachability needs softwire connectivity to transit across parts of the network that don't support both address families. Wide area networks that support one or both address families may be separated by transit networks that don't support all address families. Softwire connectivity is necessary to establish global reachability of both address families 🌈.
- Softwires are used in IP-based networks to forward both unicast and multicast traffic 🦋.
- Softwires are assumed to be long-lived in nature 🕰️.
- Although softwires are long-lived, the setup time of a softwire is expected to be a very small fraction of the total time required for the startup of the Customer Premise Equipment (CPE)/Address Family Border Router (AFBR) 🙈.
- The nodes that actually initiate softwires should support dual-stack (IPv4 and IPv6) functionality 🫶.
- The goal of this effort is to reuse or extend existing technology. The 'time-to-market' requirement for solutions to the stated problems is very strict, so existing, deployed technology must be very strongly considered in our solution selection 🔥.
The solution to the stated problem should address the following points:
- Relation of the softwire protocols to other host mechanisms in the same layer of the network stack. Examples of mechanisms to consider are tunneling mechanisms, VPNs (Virtual Private Networks), mobility, multihoming (SHIM6 (Level 3 Shim for IPv6)),...
- Operational brittleness introduced by softwire, e.g., potential single point of failure or difficulties to deploy redundant systems 💀.
- Effects of softwires on the transport layer. Issues like packet losses, congestion control, and handling of QoS (Quality of Service) reservation, plus usage of on-path protocols such as RSVP (Resource Reservation Protocol) 👑.
The history of IPv4 and IPv6 transition strategies at the IETF is very long and complex 😭. Here's a look at some steps taken to move the effort forward, which led to this document and a few 'working rules' for the work:
- At the IETF 63 "LightWeight Reachability softWires" (LRW) BOF meeting, attendees from several operators requested a very tight timeframe for delivering a solution, based on time-to-market considerations. This problem statement is narrowly scoped to accommodate near-term deployment ⏰.
- At the Paris Softwires interim meeting in October, 2005, participants divided the overall problem space into two separate "sub-problems" to solve, based on network topology. These two problems are referred to as "Hubs and Spokes" (described in Section 2) and "Mesh" (described in Section 3) 🍓.
There are two scenarios that came up when people discussed traversing networks made of differing address families, and they're super common in today's deployments 💅. The main difference between "Spokes and Hubs" and "Mesh" is how many connections and associated routes each IPv4 or IPv6 "island" has to manage. "Hubs and Spokes" is characterized by one connection and an associated static default route, while "Mesh" is characterized by multiple connections and routing prefixes. In general, the two can be categorized as host or LAN connectivity problems and network (or VPN) connectivity problems 🧩. Looking back at the history of multi-address family networking, the clear line between the two scenarios was never clearly illustrated, but they are now the network norm, and both must be solved 🌸. Later, during the solution phase of the Work Group (WG), these problems will be treated as related but separate problem spaces. Similar protocols and mechanisms will be used when possible, but different ones may be selected when necessary to meet the requirements of each problem space ✨.
1.1. Terminology 📖
Address Family (AF) - IPv4 or IPv6. Presently defined values for this field are specified in http://www.iana.org/assignments/address-family-numbers.
Address Family Border Router (AFBR) - The router that interconnects two networks that use different address families.
Customer Premise Equipment (CPE) - Under the scope of this document, this refers to terminal and associated equipment and inside wiring located at a subscriber's premises and connected with a carrier's communication channel(s) at the demarcation point ("demarc"). The demarc is a point established in a building or complex to separate customer equipment from telephone, cable, or other service provider equipment. CPE can be a host or router, depending on the specific characteristics of the access network. The demarc point for IPv4 may or may not be the same as the demarc point for IPv6, so there can be one CPE box acting for IPv4 and IPv6, or two separate ones, one for IPv4 and one for IPv6 🎀.
Home gateway - Existing piece of equipment that connects the home network to the provider network. Usually acts as CPE for one or both address families 🏠.
Softwire (SW) - A "tunnel" that is created on the basis of a control protocol setup between softwire endpoints, with a shared point-to-point or multipoint-to-point state. Softwires are generally dynamic in nature (they may be initiated and terminated on demand), but may be very long-lived 🦋.
Softwire Concentrator (SC) - The node terminating the softwire in the service provider network 👑.
Softwire Initiator (SI) - The node initiating the softwire within the customer network 🧚.
Softwire Transport Header AF (STH AF) - The address family of the outermost IP header of a softwire.
Softwire Payload Header AF (SPH AF) - The address family of the IP headers being carried within a softwire. Note that additional "levels" of IP headers may be present if (for example) a tunnel is carried over a softwire. The key attribute of SPH AF is that it is directly encapsulated within the softwire, and the softwire endpoint will base forwarding decisions on the SPH AF when a packet is exiting the softwire 🔥.
Subsequent Address Family (SAF) - Additional information about the type of Network Layer Reachability Information (e.g., unicast or multicast) 💜.
2. Hubs and Spokes Problem ✨
okay so the "Hubs and Spokes" problem is named after airlines 🛫 where the big companies set up a small number of well connected hubs and then serve the smaller airports from those hubs. bestie, the networking version is giving the exact same energy 💅
Manually configured tunnels (as described in [RFC4213]) can be a sufficient transition mechanism in some situations 🎀. BUT, when NAT traversal is a concern (see Section 2.3), or dynamic IP address configuration is required, you need a different solution 🙈
There are four variant cases of the "Hubs and Spokes" problem, shown in the figures below 🦋
+-------+ +------------+ +--------+
| | |Softwire | | IPv6 |
+---------+ | IPv4 |--|concentrator|--| Network|=>Internet
|v4/v6 |--| | +------------+ +--------+
|Host CPE | | |
+---------+ |Network|
+-------+
_ _ _ _ _ _ __
()_ _ _ _ _ _ __() IPv6 SPH
"softwire"
|--------------||-------------------------|
IPv4-only IPv6 or dual-stackFigure 1: Case 1
Case 1: IPv6 connectivity across an IPv4-only access network (STH) 🌸 The softwire initiator is the host CPE (directly connected to a modem), which is dual-stack. There is no other gateway device. The IPv4 traffic should not traverse the softwire.
+-------+ +-------------+ +--------+
| | | Softwire | | v6 |
+-----+ +------+ | v4 |--| concentrator|--| Network|=>Internet
|v4/v6|--|v4/v6 |--| | +-------------+ +--------+
|Host | |Router| |Network|
+-----+ |v4/v6 | | |
| CPE | +-------+
+------+
_ _ _ _ _ _ __
()_ _ _ _ _ _ __() IPv6 SPH
"softwire"
|--------------||--------------||-------------------------|
Dual-stack IPv4-only IPv6 or dual-stackFigure 2: Case 2
Case 2: IPv6 connectivity across an IPv4-only access network (STH) 💖 The softwire initiator is the router CPE, which is a dual-stack device. The IPv4 traffic should not traverse the softwire.
+-------+ +-------------+ +--------+
| | | Softwire | | v6 |
+------+ +------+ | v4 |--| concentrator|--| Network|=>Internet
|v4/v6 |--|v4 |--| | +-------------+ +--------+
|Host | |Router| |Network|
|v6 CPE| |v4 CPE| | |
+------+ | | +-------+
+------+
_ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH
"softwire"
|-----------------------||-------------------------|
IPv4 only IPv6 or dual-stackFigure 3: Case 3
Case 3: IPv6 connectivity across an IPv4-only access network (STH) 🧚 The CPE is IPv4-only. The softwire initiator is a host, which acts as an IPv6 host CPE. The IPv4 traffic should not traverse the softwire.
+-----+
|v4/v6| +-------+ +------------+ +-------+
|Host | | | |Softwire | | v6 |
+-----+ +------+ | v4 |--|concentrator|--|Network|=>Internet
| |v4 |--| | +------------+ +-------+
|---------|Router| |Network|
| |v4 CPE| +-------+
+---------+ +------+
|Softwire |
|Initiator|
|v6 Router|
| CPE |
+---------+
_ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH
"softwire"
|--------||-----------------------||----------------------|
Dual IPv4 only IPv6 or dual-stack
stackFigure 4: Case 4
Case 4: IPv6 connectivity across an IPv4-only access network (STH) 👑 The routing CPE is IPv4-only. The softwire initiator is a device acting as an IPv6 CPE router inside the home network. The IPv4 traffic should not traverse the softwire.
The converse cases exist too, just swap IPv4 for IPv6 and vice versa in all the figures above 🔁
2.1. Description
okay so picture this 🌈 carriers (or big enterprise networks acting as carriers for their own internal networks) have infrastructure where at least one device on any given path only supports ONE address family. Meanwhile, customers want apps that need the other address family, and that family can't be routed end-to-end. The address family that has to be "crossed" is called the Softwire Transport Header, or STH AF (which could be either IPv4 or IPv6) 🚇
To support apps bound to the other address family (the Softwire Payload Header Address Family, or SPH AF), you need to build a virtual dual-stack infrastructure (end-to-end) 🫶 This is usually done with automatically-established tunnels (Softwires). Now here's the key part 🔥 traffic that can cross the network using its native AF must not be forced onto the softwire path. Only the traffic that would otherwise fail to forward because of the AF mismatch should go inside the softwire. The goal is to avoid overwhelming the softwire concentrator (SC) 💅
A network operator may pick a single address family in one or several parts of the infrastructure, and there are two kinds of reasons for that. Policy reasons (e.g., the traffic on the network is mostly in one address family, or using a single address family keeps Operations and Management (OAM) costs down) 💜 Or technical reasons (e.g., one or more devices can't support both address families) 🤓
There are a few obstacles that may stop both address families from being supported:
a) One or more devices (routers or some other media-specific aggregation point device) used across the infrastructure (core, access) only support one address family. This usually happens because of a lack of vendor support for one of the address families, the (perceived) cost of upgrading, the (perceived) complexity of running both address families natively, operation/management reasons to avoid upgrades (perhaps temporarily), or economic reasons (such as a commercially insignificant amount of traffic in the unsupported address family) 😭
b) The home gateway (CPE router or other equipment at the demarc point) can't be easily upgraded to support both address families. Usually that's because of a lack of vendor support for one of the address families, commercial or operational reasons for skipping the upgrade (operational changes and/or cost may need to be covered by the carrier for all the customers, which can turn into millions of units), or customer reluctance to change or upgrade the CPE router (cost, "not broken, so don't change it") 🙃 Note that the impracticality of systematically upgrading CPE routers is also holding back the deployment of 6to4 based solutions [RFC3056] in IPv4 networks 🍓
2.2. Non-Upgradable CPE Router
Residential and small-office CPE equipment may be limited to supporting only one address family. Often, the owner (a customer or carrier) is unwilling or unable to upgrade it to run in dual stack mode (as shown in Figure 3 and Figure 4) 🥺
When the CPE router can't run in dual-stack mode, the softwire has to be established by a node located behind that CPE router. That can be done either by a regular host in the home running softwire software (Figure 1 or Figure 3), or by a dedicated piece of hardware acting as the "IPv6 router" (Figure 4) 🧸 Such a device is fairly simple in design and only needs one physical network interface. Again, only the traffic of the mismatched AF gets forwarded via the softwire. Traffic that could otherwise be forwarded without a softwire should not be encapsulated ✨
2.3. Network Address Translation (NAT) and Port Address Translation (PAT)
A typical case of a non-upgradable CPE router is a pre-existing IPv4/NAT home gateway, so the softwire solution must support NAT traversal 🦋
Establishing a softwire through NAT or PAT must be supported without an explicit requirement to "autodetect" NAT or PAT presence during softwire setup. Simply enabling NAT traversal could be enough to meet this requirement 🌷
Although the tunneling protocol must be able to traverse NATs, tunneling protocols may have an optional capability to bypass UDP encapsulation if they are not traversing a NAT 🎀
2.4. Static Prefix Delegation
An important characteristic of this problem in IPv4 networks is that the carrier-facing CPE IP address is typically dynamically assigned. (The IP address of the node establishing the softwire behind the CPE router can also be dynamically assigned too 🙈)
Solutions like external dynamic DNS and dynamic NAT port forwarding have been deployed to deal with ever-changing addresses, but it would be simpler if, in IPv6 networks, a static prefix were delegated to customers 🧁 A stable prefix would allow stable addresses to be registered in the DNS and enable solutions like the RFC 3041 [RFC3041] privacy extension or cryptographically generated addresses (CGA) [RFC3972] 🔐
The softwire protocol does not need to define a new method for prefix delegation. However, the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) prefix delegation [RFC3633] must be able to run over a softwire 🛣️
Link-local addresses allocated at both ends of the tunnel are enough for packet forwarding. For management purposes like traceroute, though, global addresses can be allocated using existing protocols such as stateless address auto-configuration [RFC2462] or DHCPv6 [RFC3315] 🔭
The IP addresses of the softwire link itself do not need to be stable. The desire for stability only applies to the delegated prefix. Even if there is a single node attached behind a softwire link, nothing prevents a softwire concentrator from delegating it a /64 prefix 💜
Similarly, in the case of an IPv4 softwire, the address could be provided by means of DHCP [RFC2131]. In the case of an IPv4 softwire, a mechanism should be available to delegate an IPv4 prefix [SUBNET] 🌼
Note about 6to4: This is one of the main differences between Softwires and 6to4. 6to4 addresses will change every time the CPE router gets a new external address, whereas a DHCPv6 delegated prefix through a softwire link could be stable 💀✨
2.5. Softwire Initiator ✨
2.5. Softwire Initiator
okay so in the "Hubs and Spokes" problem, softwires are always started by the customer side 🫶 which means the node that hosts the end of the softwire inside the customer network is called the softwire initiator. it can run on any dual-stack node! as we said earlier, that can be the CPE access device, another dedicated CPE router sitting behind the original CPE access device, or literally any kind of node (host, appliance, sensor, etc.) 💅
the softwire initiator node can change over time, and it may or may not get handed the same IP address for the softwire endpoint 🦋 this is giving nomad energy. softwires should work in the nomadic case (e.g., a user opening up his laptop in various Wi-Fi hot-spots ☕), where the softwire initiator could potentially end up with an IP address of one address family outside its original carrier network and still want to get the other address family addresses from its carrier. iconic, honestly 👑
if and when the IPv4 provider periodically changes the IPv4 address allocated to the gateway, the softwire initiator has to notice in a reasonable amount of time that the tunnel is down and restart it 😭 and this re-establishment should not change the IPv6 prefix and other parameters allocated to the site. bestie, that part is non-negotiable 🌸
2.6. Softwire Concentrator
on the carrier side, softwires get terminated on a softwire concentrator 🧚 a softwire concentrator is usually a dual-stack router connected to the dual-stack core of the carrier.
a carrier may deploy several softwire concentrators (for example, one per POP) for scalability reasons 🌈
softwire concentrators are usually not nomadic and have stable IP addresses. they're the reliable ones in the group chat 💜
it may be the case that one of the address families is not natively supported on the interface facing the core of the carrier. connectivity must then be provided by other tunnels, potentially using the softwire mesh model 🍓
softwire concentrator functionality will be based on existing standards for tunneling, prefix and address allocation, and management. the working group must define a softwire concentrator architecture and the interaction between these protocols, and recommend profiles 📝 these recommendations must take into account the distributed nature of the Softwires Concentrator in the provider network and the impact on core IPv6 networks (for instance: prefix aggregation) ✨ so yeah, lots of homework, but make it make sense 🎀
2.7. Softwire Concentrator Discovery
the softwire initiator must know the DNS name or IP address of the softwire concentrator 🔥 an automated discovery phase may be used to return the IP address(s) or name(s) of the concentrator. alternatively, this info may be configured by the user, or by the provider of the softwire initiator in advance.
the details of this discovery problem are outside the scope of this document, however previous work could be taken into consideration 🦋 examples include: [SERVICE-DIS], [RFC4891], and [TUN-AD]. go read those if you're curious, they're the receipts 🧾
2.8. Scaling
in a "Hubs and Spokes model", a carrier must be able to scale the solution to millions of softwire initiators by adding more hubs (i.e., softwire concentrators) 🌍 millions?! main character energy for real 👑
2.9. Routing
as customer networks are typically attached via a single link to their carrier, the minimum routing requirement is a default route for each of the address families 🛣️ simple, clean, no drama 💅
2.10. Multicast
softwires must support multicast 📡 not optional bestie 🫶
2.11. Security
2.11.1. Authentication, Authorization, and Accounting (AAA)
the softwire protocol must support customer authentication in the control plane, so it can authorize access to the service and provide adequate logging of activity (accounting) 🔐 however, a carrier may decide to turn it off in some circumstances, for instance when the customer is already authenticated by some other means, such as closed networks, cellular networks, etc., to avoid unnecessary overhead. makes sense, no notes 🙅♀️
the protocol should offer mutual authentication in scenarios where the initiator requires identity proof from the concentrator 🪪 two-way vibes 🤝
the softwire solution, at least for "Hubs and Spokes", must be integrable with commonly deployed AAA solutions (although extensions to those AAA solutions may be needed) 🧩
2.11.2. Privacy, Integrity, and Replay Protection
the softwire Control and/or Data plane must be able to provide full payload security (such as IPsec or SSL (Secure Socket Layer)) when desired 🔒 this extra protection must be separable from the tunneling aspect of the softwire mechanism itself. for IPsec, default profiles must be defined. [RFC4891] provides guidelines on this 💖 privacy is literally a whole mood 🌸
2.12. Operations and Management (OAM)
as it is assumed that the softwire may have to go across NAT or PAT, a keepalive mechanism must be defined 💓 such a mechanism is also useful for dead peer detection. however, in some circumstances (i.e., narrowband access, billing per traffic, etc.) the keepalive mechanism may consume unnecessary bandwidth, so turning it on or off, and modifying the periodicity, must be supported as administrative options 🎛️ so the operator gets the controls, babe.
other needed OAM features include:
- Logging 📓
- Usage accounting 🧮
- End-point failure detection (the detection mechanism must operate within the tunnel) 🔍
- Path failure detection (the detection mechanism must operate outside the tunnel) 🛤️
2.13. Encapsulations
IPv6/IPv4, IPv6/UDP/IPv4, and IPv4/IPv6 are on the critical path for "Hubs and Spokes" softwires 🎀 there is no intention to place limits on additional encapsulations beyond those explicitly mentioned in this specification. so, open door energy 🚪✨
3. Mesh Problem ✨
3.1. Description
okay so we use the term "Mesh Problem" to describe the problem of supporting a general routed topology, where a backbone network that doesn't support a particular address family can still be used as part of the path for packets that belong to that address family 🕸️ for example, the path for an IPv4 packet might include a transit network that only supports IPv6. there might (or might not) be other paths the IPv4 packet could take that skip the IPv6 transit network; the actual path chosen is determined by the IPv4 routing procedures. it's giving choose-your-own-adventure 🧭
by saying that the transit network supports only a single address family, we mean that the "core" routers of that network don't maintain routing information for other address families, and they may not even be able to understand the packet headers of other address families 🙈 we do suppose, though, that the core will have "edge routers" or "border routers", which maintain the routing information for both address families and which can parse the headers of both address families. we call these "Address Family Border Routers" (AFBRs) 🦋 the border squad 💪
the following figure shows an AF2-only network connected to AF1-only networks, AF2-only networks, and dual stack networks. note that in addition to paths through the AF2-only core, other paths may also exist between AF1 networks. the AFBRs that support AF1 would use BGP to exchange AF1 routing information between themselves, but that information would not be distributed to other core routers. the AFBRs would also take part in the exchange of AF2 routing information with the core nodes 🌐 picture time:
+----------+ +----------+
|AF1 only | |AF1 only |
| | | |
+----------+ +----------+
| |
| |
Dual-Stack Dual-Stack
"AFBR" "AFBR"
| |
| |
+----------------------------+
| |
+-------+ | | +-------+
|AF2 | | AF2 only | |AF2 |
|only |---| (but also providing |---|only |
+-------+ | transit for AF1) | +-------+
| |
+----------------------------+
| / \ |
| / \ |
Dual-Stack Dual-Stack
"AFBR" "AFBR"
| | |
| | |
+--------+ +--------+
|AF1 and | |AF1 and |
|AF2 | |AF2 |
+--------+ +--------+
Figure 5: Mesh Topologythe situation where a pair of border routers use BGP to exchange routing information that the core routers don't know about is sometimes called, somewhat misleadingly, a "BGP-free core" 🫠 in this sort of scenario, the problems to solve are (a) making sure that the BGP-distributed routing updates for AF1 let a given AFBR, say AFBR1, see that the path for a given AF1 address prefix goes through a second AFBR, say AFBR2, and (b) providing a way for AFBR1 to send AF1 packets through the AF2-only core to AFBR2. of course, sending AF1 packets through an AF2-only core means the AF1 packets have to be encapsulated and sent through "tunnels", and these tunnels are the entities known as "softwires" 🧚♀️
one of the goals of the mesh problem is to provide a solution that does not require changes in any routers other than the AFBRs 🎯 this would let a carrier (or a large enterprise network acting as carrier for its internal resources) with an AF2-only backbone provide AF1 transit services for its clients, without requiring any changes whatsoever to the clients' routers, and without requiring any changes to the core routers. the AFBRs are the only devices that perform dual-stack operations, and the only devices that encapsulate and/or decapsulate the AF1 packets in order to send and/or receive them on softwires 🫶 so the AFBRs are doing all the heavy lifting, iykyk 😭
it may be recognized that this scenario is very similar to the scenario handled by the Layer 3 Virtual Private Network (L3VPN) solution described in RFC 4364 [RFC4364] 💜 the AFBRs correspond to the "Provider Edge Routers" (PE) of RFC 4364. in those L3VPN scenarios, the PEs exchange routing information in an address family (e.g., the VPN-IPv4 address family), but they send VPN data packets through a core which does not have the VPN routing information. however, the softwire problem is NOT focused on the situation in which the border routers maintain multiple private and/or overlapping address spaces 🙅♀️ techniques specifically needed to support multiple address spaces are in the domain of L3VPN, rather than in the domain of Softwires. not our lane, periodt 💅
note that the AFBRs may be multiply connected to the core network, and may also be multiply connected to the client networks. further, the client networks may have "backdoor connections" to each other, through private networks or through the Internet 🕳️ wild, right? it's giving tangled web 🌸
3.2. Scaling ✨
Okay so, in the mesh problem, a backbone that only supports AF2 is gonna need roughly as many AFBRs as there are AF1 networks plugging into it. That's really an upper limit, bestie, because a single AFBR can connect to a bunch of those networks at once 💅.
Each AFBR might have to swap a "full Internet's" worth of routing info with every network it connects to 🌐. If those networks aren't VPNs, the scaling headaches are just the usual ones that any border router providing Internet transit already deals with 😩. (If the AFBRs are also attached to VPNs, the usual L3VPN scaling issues apply too, as discussed in RFC 4364 [RFC4364] and RFC 4365 [RFC4365] 📖.) The number of BGP peering connections can be kept under control with the usual methods, like route reflectors 🦋.
3.3. Persistence, Discovery, and Setup Time 🧚
AFBRs can find each other and grab whatever info they need about one another as a byproduct of trading routing info 🤝. It's basically the same way PE routers discover each other in L3VPNs. This might mean adding new protocol elements or attributes to existing protocols 🛠️.
The softwires that let packets zoom from one AFBR to another should be "always available" ✨. In other words, no extended setup time that would add a noticeable delay to the data packets 🐌🚫.
3.4. Multicast 📣
If the AF2 core doesn't provide native multicast services, multicast between AF1 client networks should still be possible 🔁. It might just mean replicating packets at the AFBRs and unicasting the copies through softwires. If native multicast services are enabled, it should be possible to use them to optimize the multicast flow ⚡.
3.5. Softwire Encapsulation 🎀
The solution to the mesh problem must not require the use of any one encapsulation 🙅. Instead, it must handle a whole variety of encapsulation mechanisms, plus a means for choosing the right one for any particular situation based on policy 🧩.
Specifically, it must allow for at least these encapsulations to be used: Layer 2 Tunneling Protocol version 3 (L2TPv3), IP-in-IP, MPLS (LDP-based and RSVP-TE-based), Generic Routing Encapsulation (GRE), and IPsec 💜. The choice of encapsulation is based on policy, and those policies can depend on the characteristics of the packets, the routes, or the softwire endpoints themselves 👑.
3.6. Security 🔐
In the mesh problem, the routers aren't advertising routes for individual users. So the mesh problem doesn't need the fine-grained authentication that the "Hub and Spoke" problem requires 🙌. There should still be a way to provide various levels of security for the data packets moving over a softwire 🛡️. The softwire solution must support IPsec, and an IPsec profile must be defined (see recommendations in [USEIPSEC]) 🔒.
Security mechanisms for the control protocols are also required, bestie. It must be possible to protect control data from being modified in flight by an attacker, and to prevent an attacker from masquerading as a legit control protocol participant 🚫👻.
Verifying the reachability info that gets exchanged, plus the security of the routing protocols themselves, is outside the scope of the specification 🙅♀️.
4. Security Considerations 🚨
Security considerations specific to the "Hubs and Spokes" and "Mesh" models live in those sections of the document 👀.
💀 Okay, this one is SERIOUS. As with any tunneling protocol, using this protocol may introduce a security issue by circumventing a site security policy implemented as ingress filtering, since these filters will only be applied to STH AF IP headers. Be careful out there!! 🙏
5. Principal Authors 👩💻
These are the principal authors for this document 💖.
Xing Li
CERNET
Room 225 Main Building, Tsinghua University
Beijing 100084
China
Phone: +86 10 62785983
Fax: +86 10 62785933
Email: xing@cernet.edu.cn
Alain Durand
Comcast
1500 Market st
Philadelphia
PA 19102
USA
Email: Alain_Durand@cable.comcast.com
Shin Miyakawa
NTT Communications
3-20-2 TOC 21F, Nishi-shinjuku, Shinjuku
Tokyo
Japan
Phone: +81-3-6800-3262
Fax: +81-3-5365-2990
Email: miyakawa@nttv6.jp
Jordi Palet Martinez
Consulintel
San Jose Artesano, 1
Alcobendas - Madrid
E-28108 - Spain
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
Email: jordi.palet@consulintel.es
Florent Parent
Hexago
2875 boul. Laurier, suite 300
Sainte-Foy, QC G1V 2M2
Canada
Phone: +1 418 266 5533
Email: Florent.Parent@hexago.com
David Ward
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
USA
Phone: +1-408-526-4000
Email: dward@cisco.com
Eric C. Rosen
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA, 01716
USA
Email: erosen@cisco.com6. Contributors 🫶
The authors would like to acknowledge the following contributors, who provided helpful inputs on earlier versions of this document 🌸: Alain Baudot, Hui Deng, Francis Dupont, Rob Evans, Ed Koehler Jr, Erik Nordmark, Soohong Daniel Park, Tom Pusateri, Pekka Savola, Bruno Stevant, Laurent Totain, Bill Storer, Maria (Alice) Dos Santos, Yong Cui, Chris Metz, Simon Barber, Skip Booth, Scott Wainner, and Carl Williams 💕.
The authors would also like to acknowledge the participants in the Softwires interim meeting in Paris, France (October 11-12, 2005). The minutes are at http://bgp.nu/~dward/softwires/InterimMeetingMinutes.htm 📝.
The authors would also like to give a special shoutout and thanks to Mark Townsley 🏆. Without his leadership, persistence, editing skills, and thorough suggestions for the document, we would have not have been successful 🥹.
Tunnel-based transition mechanisms have been under discussion in the IETF for more than a decade 🕰️. Initial work related to softwire can be found in RFC 3053 [RFC3053]. The earlier "V6 Tunnel Configuration" BOF problem statement [GOALS-TUN] is a reasonable pointer to prior work 🔗.
The authors would like to acknowledge the work and support of Dr Jianping Wu of Tsinghua university 🙌.
7. References 📚
7.1. Normative References 💅
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6",
RFC 3041, January 2001.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento,
"IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3972] Aura, T., "Cryptographically Generated Addresses
(CGA)", RFC 3972, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.7.2. Informative References 🦋
[GOALS-TUN] Palet, J., "Goals for Tunneling Configuration", Work
in Progress, February 2005.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T.,
Perkins, C., and M. Carney, "Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3315,
July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for
Dynamic Host Configuration Protocol (DHCP) version 6",
RFC 3633, December 2003.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4365,
February 2006.
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H.
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4
Tunnels", RFC 4891, May 2007.
[SERVICE-DIS] Durand, A., "Service Discovery using NAPTR records in
DNS", Work in Progress, October 2004.
[SUBNET] Johnson, R., "Subnet Allocation Option", Work in
Progress, June 2007.
[TUN-AD] Palet, J. and M, "Analysis of IPv6 Tunnel End-point
Discovery Mechanisms", Work in Progress, January 2005.
[USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of
IPsec", Work in Progress, February 2007.Authors' Addresses 💌
Xing Li (editor)
CERNET
Room 225 Main Building, Tsinghua University
Beijing, 100084
China
Phone: +86 10 62785983
Fax: +86 10 62785933
EMail: xing@cernet.edu.cn
Spencer Dawkins (editor)
Huawei Technologies (USA)
1700 Alma Drive, Suite 100
Plano, TX 75075
US
Phone: +1 972 509 0309
Fax: +1 469 229 5397
EMail: spencer@mcsr-labs.org
David Ward (editor)
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
US
Phone: 1-408-526-4000
EMail: dward@cisco.com
Alain Durand (editor)
Comcast
1500 Market St
Philadelphia, PA 19102
US
EMail: alain_durand@cable.comcast.comFull Copyright Statement ©️
Copyright (C) The IETF Trust (2007) 🩷.
This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth therein, the authors retain all their rights 📜.
This document and the information in it are provided on an "AS IS" basis, and the disclaimer below applies:
THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🧠
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document. It also doesn't say whether any license under such rights might or might not be available, and it hasn't made any independent effort to identify any such rights 🕵️♀️. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📖.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🗂️.
The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org 📬.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society 🫶✨.
📦 where this page comes from
- ietf: rfc4925 2007-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms