Softwire Workgroup RFCs

Browse Softwire Workgroup RFCs by Number

RFC4925 - Softwire Problem Statement: This 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. This memo provides information for the Internet community.
RFC5512 - The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute: In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.; The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS-TRACK]
RFC5543 - BGP Traffic Engineering Attribute: This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information.; The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. [STANDARDS-TRACK]
RFC5549 - Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop: Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) or VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. [STANDARDS-TRACK]
RFC5565 - Softwire Mesh Framework: The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. [STANDARDS-TRACK]
RFC5566 - BGP IPsec Tunnel Encapsulation Attribute: The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops. Currently, support for Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), and IP in IP tunnel types are defined. This document defines support for IPsec tunnel types. [STANDARDS-TRACK]
RFC5571 - Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2): This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. [STANDARDS-TRACK]
RFC5619 - Softwire Security Analysis and Requirements: This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets. [STANDARDS-TRACK]
RFC5640 - Load-Balancing for Mesh Softwires: Payloads transported over a Softwire mesh service (as defined by BGP Encapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows. It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering the Softwire can only be interpreted by the ingress and egress routers. Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two Tunneling Protocol - Version 3 (L2TPv3) over IP or Generic Routing Encapsulation (GRE) encapsulation to what would be achieved without such encapsulation. [STANDARDS-TRACK]
RFC5969 - IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification: This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism. [STANDARDS-TRACK]
RFC6333 - Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion: This document revisits the dual-stack model and introduces the Dual- Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). [STANDARDS-TRACK]
RFC6334 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite: This document specifies a DHCPv6 option that is meant to be used by a Dual-Stack Lite Basic Bridging BroadBand (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). [STANDARDS-TRACK]
RFC6519 - RADIUS Extensions for Dual-Stack Lite: Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-Stack Lite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic Host Configuration Protocol (DHCP). This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and the Network Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server. [STANDARDS-TRACK]
RFC6674 - Gateway-Initiated Dual-Stack Lite Deployment: Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual- Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures. GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded Context Identifier that uniquely identifies the end-system to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. [STANDARDS-TRACK]
RFC6908 - Deployment Considerations for Dual-Stack Lite: This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture.
RFC6930 - RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd): The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs.
RFC7040 - Public IPv4-over-IPv6 Access Network: This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses. Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments. Future deployments of similar scenarios should use Lightweight 4over6. Public 4over6 follows the Hub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network. The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay. Public 4over6 aims to provide uninterrupted IPv4 services to users, like Internet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network.
RFC7596 - Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture: Dual-Stack Lite (DS-Lite) (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called "Lightweight 4over6", which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs.
RFC7597 - Mapping of Address and Port with Encapsulation (MAP-E): This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports.
RFC7598 - DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients: This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network.
RFC7599 - Mapping of Address and Port using Translation (MAP-T): This document specifies the solution architecture based on "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation (NAT64) for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network.
RFC7600 - IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd): This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers. The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end. Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set.
RFC7856 - Softwire Mesh Management Information Base (MIB): This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing a softwire mesh.
RFC7870 - Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs): This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects for Address Family Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite).
RFC8026 - Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism: In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option, whereby a single instance of Customer Premises Equipment (CPE) can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4-in-IPv6 services by providing a prioritization mechanism.
RFC8114 - Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network: This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to customers serviced by Dual-Stack Lite (DS-Lite).
RFC8115 - DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes: This document defines a Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast IPv4 service continuity solutions, which is used to carry the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses.
RFC8389 - Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E): This memo defines a portion of the Management Information Base (MIB) for Mapping of Address and Port with Encapsulation (MAP-E) for use with network management protocols.
RFC8513 - A YANG Data Model for Dual-Stack Lite (DS-Lite): This document defines a YANG module for the Dual-Stack Lite (DS-Lite) Address Family Transition Router (AFTR) and Basic Bridging BroadBand (B4) elements.
RFC8638 - IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks: During the transition to IPv6, there are scenarios where a backbone network internally running one IP address family (referred to as the internal IP or I-IP family) connects client networks running another IP address family (referred to as the external IP or E-IP family). In such cases, the I-IP backbone needs to offer both unicast and multicast transit services to the client E-IP networks.; This document describes a mechanism for supporting multicast across backbone networks where the I-IP and E-IP protocol families differ. The document focuses on the IPv4-over-IPv6 scenario, due to lack of real-world use cases for the IPv6-over-IPv4 scenario.
RFC8658 - RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P): IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 coexistence period. DHCPv6 options have been defined to configure clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting (AAA) server, which utilizes the Remote Authentication Dial In User Service (RADIUS) protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly.; This document defines new RADIUS attributes to carry softwire configuration parameters based on Address plus Port from a AAA server to a Broadband Network Gateway. Both unicast and multicast attributes are covered.
RFC8675 - A YANG Data Model for Tunnel Interface Types: This document specifies the initial version of a YANG module "iana-tunnel-type", which contains a collection of IANA-maintained YANG identities used as interface types for tunnel interfaces. The module reflects the "tunnelType" registry maintained by IANA. The latest revision of this YANG module can be obtained from the IANA website.; Tunnel type values are not directly added to the Tunnel Interface Types YANG module; they must instead be added to the "tunnelType" IANA registry. Once a new tunnel type registration is made by IANA for a new tunneling scheme or even an existing one that is not already listed in the current registry (e.g., LISP, NSH), IANA will update the Tunnel Interface Types YANG module accordingly.; Some of the IETF-defined tunneling techniques are not listed in the current IANA registry. It is not the intent of this document to update the existing IANA registry with a comprehensive list of tunnel technologies. Registrants must follow the IETF registration procedure for interface types whenever a new tunnel type is needed.
RFC8676 - YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires: This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and Customer Premises Equipment for the Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms.