Network Working Group X. Li, Ed. Request for Comments: 4925 CERNET Category: Informational S. Dawkins, Ed. Huawei D. Ward, Ed. Cisco Systems A. Durand, Ed. Comcast July 2007 Softwire Problem Statement Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).
AbstractThis document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope.
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 . . . . . . . . . . . . . . . . . . 20
o Operational brittleness introduced by softwire, e.g., potential single point of failure or difficulties to deploy redundant systems. o Effects of softwires on the transport layer. Issue like packet losses, congestion control, and handling of QoS (Quality of Service) reservation and 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 we list out some steps we have taken to further the effort and it has lead to the creation of this document and a few 'working rules' for us to accomplish our work: o At the IETF 63 "LightWeight Reachability softWires" (LRW) BOF meeting, attendees from several operators requested a very tight timeframe for the delivery of a solution, based on time-to-market considerations. This problem statement is narrowly scoped to accommodate near-term deployment. o 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). As stated, there are two scenarios that emerged when discussing the traversal of networks composed of differing address families. The scenarios are quite common in today's network deployments. The primary difference between "Spokes and Hubs" and "Mesh" is how many connections and associated routes are managed by each IPv4 or IPv6 "island". "Hubs and Spokes" is characterized with one connection and associated static default route, and "Mesh" is characterized by multiple connections and routing prefixes. In general, the two can be categorized as host or LAN connectivity and network (or VPN) connectivity problems. Looking at the history of multi-address family networking, the clear delineation of 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 protocols and mechanisms may be selected when necessary to meet the requirements of each given problem space.
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, thus 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 act 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).
RFC4213]) can be a sufficient transition mechanism in some situations. However, cases where Network Address Translation (NAT) traversal is a concern (see Section 2.3), or dynamic IP address configuration is required, another solution is necessary. There are four variant cases of the "Hubs and Spokes" problem which are shown in the following figures. +-------+ +------------+ +--------+ | | |Softwire | | IPv6 | +---------+ | IPv4 |--|concentrator|--| Network|=>Internet |v4/v6 |--| | +------------+ +--------+ |Host CPE | | | +---------+ |Network| +-------+ _ _ _ _ _ _ __ ()_ _ _ _ _ _ __() IPv6 SPH "softwire" |--------------||-------------------------| IPv4-only IPv6 or dual-stack Case 1: IPv6 connectivity across an IPv4-only access network (STH). 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. Figure 1: Case 1
+-------+ +-------------+ +--------+ | | | 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-stack Case 2: IPv6 connectivity across an IPv4-only access network (STH). Softwire initiator is the router CPE, which is a dual-stack device. The IPv4 traffic should not traverse the softwire. Figure 2: Case 2 +-------+ +-------------+ +--------+ | | | Softwire | | v6 | +------+ +------+ | v4 |--| concentrator|--| Network|=>Internet |v4/v6 |--|v4 |--| | +-------------+ +--------+ |Host | |Router| |Network| |v6 CPE| |v4 CPE| | | +------+ | | +-------+ +------+ _ _ _ _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH "softwire" |-----------------------||-------------------------| IPv4 only IPv6 or dual-stack Case 3: IPv6 connectivity across an IPv4-only access network (STH). The CPE is IPv4-only. Softwire initiator is a host, which act as an IPv6 host CPE. The IPv4 traffic should not traverse the softwire. Figure 3: Case 3
+-----+ |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 stack Case 4: IPv6 connectivity across an IPv4-only access network (STH). The routing CPE is IPv4-only. Softwire initiator is a device acting as an IPv6 CPE router inside the home network. The IPv4 traffic should not traverse the softwire. Figure 4: Case 4 The converse cases exist, replacing IPv4 by IPv6 and vice versa in the above figures.
forwarded within the softwire. The goal is to avoid overwhelming the softwire concentrator (SC). A network operator may choose to enable a single address family in one or several parts of this infrastructure for policy reasons (i.e., traffic on the network is dominant in one of the address families, a single address family is used to lower Operations and Management (OAM) cost, etc.) or for technical reasons (i.e., because one or more devices are not able to support both address families). There are several obstacles that may preclude support for both address families: a) One or more devices (routers or some other media-specific aggregation point device) being used across the infrastructure (core, access) that supports only one address family. Typically the reasons for this situation include a lack of vendor support for one of the address families, the (perceived) cost of upgrading them, 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 with the non-supported address family). b) The home gateway (CPE router or other equipment at the demarc point), cannot be easily upgraded to support both address families. Typically the reason for this is the lack of vendor support for one of the address families, commercial or operational reasons for not carrying out the upgrade (i.e., operational changes and/or cost may need to be supported by the carrier for all the customers, which can turn into millions of units), or customer reluctance to change/ upgrade CPE router (cost, "not broken, so don't change it"). Note that the impracticality of systematic upgrades of the CPE routers is also hindering the deployment of 6to4 based solutions [RFC3056] in IPv4 networks. Figure 3 and Figure 4). When the CPE router cannot run in dual-stack mode, a softwire will have to be established by a node located behind that CPE router. This can be accomplished 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 requires one physical network
interface. Again, only the traffic of the mismatched AF will be forwarded via the softwire. Traffic that can otherwise be forwarded without a softwire should not be encapsulated. 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, but for management purpose like traceroute, 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 to delegate 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 in order 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, where a DHCPv6 delegated prefix through a softwire link could be stable.
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, prefixes, and addresses allocation, management. The working group must define a softwire concentrator architecture and 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). SERVICE-DIS], [RFC4891], and [TUN-AD].
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., in order to avoid unnecessary overhead. The protocol should offer mutual authentication in scenarios where the initiator requires identity proof from the concentrator. 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). RFC4891] provides guidelines on this.
+----------+ +----------+ |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 Topology The situation in which a pair of border routers use BGP to exchange routing information that is not known to the core routers is sometimes known, somewhat misleadingly, as a "BGP-free core". In this sort of scenario, the problems to be solved are (a) to make sure that the BGP-distributed routing updates for AF1 allow a given AFBR, say AFBR1, to see that the path for a given AF1 address prefix is through a second AFBR, say AFBR2, and (b) to provide a way in which AFBR1 can send AF1 packets through the AF2-only core to AFBR2. Of course, sending AF1 packets through an AF2-only core requires the AF1 packets to be encapsulated and sent through "tunnels"; 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 allow a carrier (or large enterprise networks acting as carrier for their internal resources) with an AF2-only backbone to 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. 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 which are specifically needed to support multiple address spaces are in the domain of L3VPN, rather than in the domain of Softwires. Note that the AFBRs may be multiply connected to the core network, and also may 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. RFC4364] and RFC 4365 [RFC4365].) The number of BGP peering connections can be controlled through the usual methods, e.g., use of route reflectors.
The softwires needed to allow packets to be sent from one AFBR to another should be "always available", i.e., should not require any extended setup time that would impart an appreciable delay to the data packets. USEIPSEC]). Security mechanisms for the control protocols are also required. 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 legitimate control protocol participant. The verification of the reachability information exchanged and issues surrounding the security of routing protocols themselves is outside the scope of the specification.
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: firstname.lastname@example.org 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: email@example.com Eric C. Rosen Cisco Systems 1414 Massachusetts Avenue Boxborough, MA, 01716 USA Email: firstname.lastname@example.org
The authors would also like to acknowledge the participants in the Softwires interim meeting in Paris, France (October 11-12, 2005) (minutes are at http://bgp.nu/~dward/softwires/InterimMeetingMinutes.htm). The authors would also like to express a special acknowledgement 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] a reasonable pointer to prior work. The authors would like to acknowledge the work and support of Dr Jianping Wu of Tsinghua university. [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. [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.
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and 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 regarding 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 or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from 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 or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.