Softwires Configuration Overview
Tunneling Services for IPv4-to-IPv6 Transition Overview
Junos OS enables service providers to transition to IPv6 by using softwire encapsulation and decapsulation techniques. A softwire is a tunnel that is created between softwire customer premises equipment (CPE). A softwire CPE can share a unique common internal state for multiple softwires, making it a very light and scalable solution. When you use softwires, you need not maintain an interface infrastructure for each softwire, unlike a typical mesh of generic routing encapsulation (GRE) tunnels that requires you to do so. A softwire initiator at the customer end encapsulates native packets and tunnels them to a softwire concentrator at the service provider. The softwire concentrator decapsulates the packets and sends them to their destination. A softwire is created when a softwire concentrator receives the first tunneled packet of a flow and prepares the packet for flow processing. The softwire exists as long as the softwire concentrator is providing flows for routing. A flow counter is maintained; when the number of active flows is 0, the softwire is deleted. Statistics are kept for both flows and softwires.
Softwire addresses are not specifically configured under any physical or virtual interface. The number of established softwires does not affect throughput, and scalability is independent of the number of interfaces. Scalability is only limited to the number of flows that the services DPC or PIC can support.
This topic contains the following sections:
6to4 Overview
Basic 6to4
6to4 is an Internet transition mechanism for migrating from IPv4 to IPv6, a system that enables IPv6 packets to be transmitted over an IPv4 network (generally the IPv4 Internet) without the need to configure explicit tunnels. 6to4 is described in RFC 3056, Connection of IPv6 Domains via IPv4 Clouds. 6to4 is especially relevant during the initial phases of deployment to full, native IPv6 connectivity, because IPv6 is not required on nodes between the host and the destination. 6to4 is intended only as a transition mechanism and is not meant to be used permanently.
6to4 is supported on Multiservices 100, 400, and 500 PICs on M Series routers and on MX Series routers equipped with Multiservices DPCs and on MX240, MX480, and MX960 routers with the MX-SPC3 services card. 6rd is not supported on MX Series routers with MS-MPCs or MS-MICs.
6to4 can be used by an individual host or by a local IPv6 network. When used by a host, 6to4 must have a global IPv4 address connected, and the host is responsible for the encapsulation of outgoing IPv6 packets and the decapsulation of incoming 6to4 packets. If the host is configured to forward packets for other clients, often a local network, it is then a router.
There are two kinds of 6to4 virtual routers: border routers and relay routers.
A 6to4 border router is an IPv6 router supporting a 6to4 pseudointerface, and is normally the border router between an IPv6 site and a wide-area IPv4 network.
A relay router is a 6to4 router configured to support transit routing between 6to4 addresses and pure native IPv6 addresses.
In order for a 6to4 host to communicate with the native IPv6 Internet, the host’s IPv6 default gateway must be set to a 6to4 address that contains the IPv4 address of a 6to4 relay router. To avoid the need for users to set this up manually, the Anycast address of 192.88.99.1 has been allocated to send packets to a 6to4 relay router. When processed by 6to4 with the subnet and hosts fields set to zero, this IPv4 address (192.88.99.1) becomes the IPv6 address 2002:c058:6301::. To ensure BGP routing propagation, a short prefix of 192.88.99.0/24 has been allocated for routes pointed at 6to4 relay routers that use this Anycast IP address. We recommend that providers who want to provide 6to4 service to their clients or peers advertise the Anycast prefix like any other IP prefix, and route the prefix to the provider’s 6to4 relay.
Packets from the IPv6 Internet to 6to4 systems must be sent to a 6to4 relay router by normal IPv6 routing methods. The specification states that such relay routers must only advertise 2002::/16 and not subdivisions of it to prevent the embedding of IPv4 routes into the routing tables of IPv6 routers. From the 6to4 relay router the packets can then be sent over the IPv4 Internet to the destination.
6to4 Anycast
Router 6to4 requires that 6to4 routers and relays are managed and configured cooperatively. In particular, 6to4 sites must configure a relay router to carry the outbound traffic, which becomes the default IPv6 router (except for 2002::/16). The objective of the Anycast variant, defined in RFC 3068, An Anycast Prefix for 6to4 Relay Routers, is to avoid the need for such configuration. Removing this configuration makes the solution available for small or domestic users, even those with a single host or simple home gateway instead of a border router. Removing this configuration is achieved by defining 192.88.99.1 as the default IPv4 address for a 6to4 relay, and 2002:c058:6301:: as the default IPv6 router prefix (well-known prefix) for a 6to4 site.
RFC 6343, Advisory Guidelines for 6to4 Deployment, published in August 2011, identifies a wide range of problems associated with the use of unmanaged 6to4 Anycast relay routers.
6to4 Provider-Managed Tunnels
A solution to many problems associated with unmanaged Anycast 6to4 is presented in IETF informational draft draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-02, 6to 4 Provider-Managed Tunnels (PMT). That document, a work in progress, proposes a solution that providers can implement to exercise greater control over the routing of 6to4 traffic.
Anycast 6to4 implies a default configuration for the user site. It does not require any particular user action. It does require an IPv4 Anycast route to be in place to a relay at 192.88.99.1. Traffic does not necessarily return to the same 6to4 gateway because of the well-known 6to4 prefix used and advertised by all 6to4 traffic.
6to4 provider-managed tunnels (PMTs) facilitate the management of 6to4 tunnels using an Anycast configuration. 6to4 PMT enables service providers to improve 6to4 operation when network conditions provide suboptimal performance or break normal 6to4 operation. 6to4 PMT provides a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 prefix translation that controls the flow of return traffic.
The 6to4 managed tunnel model behaves like a standard 6to4 service between the customer IPv6 host or gateway and the 6to4 PMT relay (within the provider domain). The 6to4-PMT relay shares properties with 6rd (RFC5969) by decapsulating and forwarding embedded IPv6 flows, within an IPv4 packet, to the IPv6 Internet. The model provides an additional function that translates the source 6to4 prefix to a provider assigned prefix that is not found in 6rd (RFC5969) or traditional 6to4 operation. The 6to4-PMT relay provides a stateless (or stateful) mapping of the 6to4 prefix to a provider-supplied prefix by mapping the embedded IPv4 address in the 6to4 prefix to the provider prefix.
DS-Lite Softwires—IPv4 over IPv6
When an ISP begins to allocate new subscriber home IPv6 addresses and IPv6-capable equipment, dual-stack lite (DS-Lite) provides a method for the private IPv4 addresses behind the IPv6 customer edge WAN equipment to reach the IPv4 network. DS-Lite enables IPv4 customers to continue to access the Internet using their current hardware by using a softwire initiator, referred to as a Basic Bridging Broadband (B4), at the customer edge to encapsulate IPv4 packets into IPv6 packets and tunnel them over an IPv6 network to a softwire concentrator, referred to as an Address Family Transition Router (AFTR), for decapsulation. DS-Lite creates the IPv6 softwires that terminate on the services PIC. Packets coming out of the softwire can then have other services such as NAT applied on them.
DS-Lite is supported on MS-DPCs and MS-100, MS-400, and MS-500 MultiServices PICS. Starting in Junos OS release 20.2R1, DS-Lite is supported Next Gen Services on MX240, Mx480 and MX960 routers with the MX-SPC3.Starting in Junos OS release 17.4R1, DS-Lite is supported on MX Series routers with MS-MPCs and MS-MICs. Starting in Junos OS release 18.2R1, DS-lite is supported on AMS interfaces.Starting in Junos OS release 19.2R1, DS-Lite is supported on MX Virtual Chassis and MX Broadband Network Gateway (BNG) routers.
IPv6 Provider Edge , or MPLS-enabled IPv6, is available for ISPs with MPLS-enabled networks. These networks now can use Multiprotocol BGP (MP-BGP) to provide connectivity between the DS-Lite B4 and AFTR (or any two IPv6 nodes). DS-Lite properly handles encapsulation and decapsulation despite the presence of additional MPLS header information.
For more information on DS-Lite softwires, see the IETF draft Dual Stack Lite Broadband Deployments Following IPv4 Exhaustion.
The most recent IETF draft documentation for DS-Lite uses new terminology:
The term softwire initiator has been replaced by B4.
The term softwire concentrator has been replaced by AFTR.
The Junos OS documentation generally uses the original terms when discussing configuration in order to be consistent with the command-line interface (CLI) statements used to configure DS-Lite.
6rd Softwires—IPv6 over IPv4
6rd softwire flow is shown in Figure 1.
Junos OS supports a 6rd softwire concentrator on a services DPC or PIC to facilitate rapid deployment of IPv6 service to subscribers on native IPv4 customer edge WANs. IPv6 packets are encapsulated in IPv4 packets by a softwire initiator at the customer edge WAN. These packets are tunneled to a softwire concentrator residing on an MS-DPC or MX-SPC3 (branch relay). A softwire is created when IPv4 packets containing IPv6 destination information are received at the softwire concentrator, which decapsulates IPv6 packets and forwards them for IPv6 routing. All of these functions are performed in a single pass of the services PIC.
In the reverse path, IPv6 packets are sent to the services DPC where they are encapsulated in IPv4 packets corresponding to the proper softwire and sent to the customer edge WAN.
The softwire concentrator creates softwires as the IPv4 packets are received from the customer edge WAN side or IPv6 packets are received from the Internet. A 6rd softwire on the Services DPC is identified by the 3-tuple containing the service set ID, customer edge softwire initiator IPv4 address, and softwire concentrator IPv4 address. IPv6 flows are also created for the encapsulated IPv6 payload, and are associated with the specific softwire that carried them in the first place. When the last IPv6 flow associated with a softwire ends, the softwire is deleted. This simplifies configuration and there is no need to create or manage tunnel interfaces.
6rd is supported on Multiservices 100, 400, and 500 PICs on M Series routers, and on MX Series routers equipped with Multiservices DPCs. 6rd is not supported on MX Series routers with MS-MPCs or MS-MICs.
Junos OS supports inline 6rd and 6to4 on Modular Port Concentrator (MPC) line cards.
For more information on 6rd softwires, see RFC 5969, IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification.
See Also
Configuring Softwire Rules
You configure softwire rules to instruct the router how
to direct traffic to the addresses specified for 6rd or DS-Lite softwire
concentrators. Softwire rules do not perform any filtration of the
traffic. They do not include a from statement, and the
only option in the then statement is to specify the address
of the 6rd or DS-Lite softwire concentrator.
Softwire rules are supported on Multiservices 100, 400, and 500 PICs on M Series routers, and on MX Series routers equipped with Multiservices DPCs. Starting in Junos OS release 17.4R1, softwire rules for DS-Lite are supported on MX Series routers with MS-MPCs and MS-MICs.Starting in Junos OS release 19.2R1, softwire rules for DS-Lite are supported on MX Virtual Chassis and MX Broadband Network Gateway (BNG) routers.
You can create a softwire rule consisting of one or more terms and associate a particular 6rd or DS-Lite softwire concentrator with each term. You can include the softwire rule in service sets along with other services rules.
To configure a softwire rule:
See Also
Configuring Service Sets for Softwire
You must include softwire rules or a softwire rule set in a service set to enable softwire processing. You must include a stateful firewall rule for DS-Lite.
Softwire rules are supported on Multiservices 100, 400, and 500 PICs on M Series routers, and on MX Series routers equipped with Multiservices DPCs. Starting in Junos OS release 17.4R1, softwire rules for DS-Lite are supported on MX Series routers with MS-MPCs and MS-MICs.Starting in Junos OS release 19.2R1, softwire rules for DS-Lite are supported on MX Virtual Chassis and MX Broadband Network Gateway (BNG) routers.
To configure service sets for softwire:
For further information, see “Configuring Service Rules.”
See Also
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.