Softwire Mesh Framework
Extracted elements (28)
IPv4-over-IPv6 is an emerging requirement that had not previously received significant attention. Service providers building IPv6-only backbone cores need to carry legacy IPv4 traffic without native IPv4 support in their P routers.
Manual configuration of point-to-point tunnels is explicitly excluded from the framework because N dual-stack AFBRs would require N² tunnels, creating an unacceptable O(N²) provisioning problem.
Multipoint-to-point tunnels are sufficient for layer-3 transit services; the egress AFBR need not know which ingress router encapsulated a given packet, mirroring native IP forwarding semantics. Point-to-point tunnels are allowed but not required.
Softwires do not form a routing overlay: routing adjacencies are not maintained over softwires, and routing control packets are not sent through them. Backbone routing adjacencies use the native I-IP technology.
The framework terminologically distinguishes I-IP (Internal IP, the transit core protocol) from E-IP (External IP, the client-side protocol). E-IP is IPv4 if and only if I-IP is IPv6, and vice versa, so the two are always complementary.
The Softwire Mesh Framework addresses the need for single-protocol transit networks to carry traffic of the opposite protocol. An IPv4-only core must provide IPv6 transit and vice versa, achieved by tunneling E-IP packets across the I-IP core using softwires between Address Family Border Routers (AFBRs).
BGP messages exchanged between AFBRs run natively over I-IP and are NOT tunneled through softwires or any other mechanism. IBGP sessions use the transit core's native network layer.
The framework accommodates MPLS (LDP-based and RSVP-TE-based), L2TPv3, GRE, IP-in-IP, and IPsec as tunneling technologies. No single technology is mandated; choice is a matter of deployment policy. Most can carry MPLS packets, so MPLS in the core is not presupposed.
When the transit core spans multiple Autonomous Systems, the softwire remote endpoint is not the BGP next hop, breaking the core selection procedure. Solutions include AS-boundary AFBRs, multi-hop EBGP, or preserving next hops at ASBRs, possibly requiring stacked encapsulations.
A packet decided to travel via softwire MUST be sent through a softwire whose remote endpoint address is the same as the BGP next hop address provided by routing.
A Route Reflector MUST NOT change the address family of a BGP next hop when reflecting routes that carry E-IP NLRI over I-IP sessions.
If a BGP capability is defined for the case where an E-IP NLRI has an I-IP next hop (as required for cross-family encoding such as RFC 5549), all AFBRs in a given transit core MUST advertise that capability.
If IPsec-protected tunnels are required, the tunnel type SHOULD be negotiated by the tunnel endpoints using the procedures in RFC 5566, which allows both IPsec tunnel mode and transport mode.
If the path between tunnel endpoints is not adequately secure and a control protocol is used to set up tunnels, the control protocol MUST have an authentication mechanism that MUST be used at setup time. BGP's MD5 authentication (RFC 2385) is deemed satisfactory.
Since softwires are set up dynamically as a byproduct of routing, key distribution MUST be done automatically via IKEv2 (RFC 4306). If no PKI is available, the IPsec Tunnel Authenticator sub-TLV from RFC 5566 MUST be used and validated before establishing an SA.
The MTU of a softwire's path SHOULD be large enough so that (a) no packet will need to be fragmented before encapsulation, and (b) no encapsulated packet will need fragmentation while in transit.
When a BGP speaker sends an update for an E-IP NLRI over an I-IP BGP session and advertises itself as the next hop, it MUST specify the next hop address in the I-IP family, unless explicitly overridden by policy.
When IPsec is used to secure softwires, it MUST provide authentication and integrity. Implementations MUST support ESP with null encryption (RFC 4303) or AH (RFC 4302); ESP with encryption MAY be supported.
When using ESP, the tunnel tail MUST verify that the source IP address on any packet received on a given SA matches the expected address, per RFC 4301 Section 5.2 step 4.
AFBR class membership for tunnel-technology selection can be advertised as BGP communities or extended communities via RFC 5512, allowing policies such as 'use L2TPv3 to class X routers and GRE to class Y routers'.
For E-IP multicast over an I-IP core using PIM, an AFBR translates E-IP PIM Join/Prune messages to I-IP and inserts an RPF Vector (RFC 5496) identifying the egress AFBR as an I-IP address, since core routers hold no E-IP routes.
For GRE (without options) and L2TPv3 softwires, signaling is BGP-based as specified in RFC 5512 (BGP Encapsulation SAFI and Tunnel Encapsulation Attribute). IP-in-IP and GRE without options require no signaling; MPLS uses LDP or RSVP-TE; IPsec uses IKEv2.
The Address Family Border Router (AFBR) is the PE router that handles both I-IP (the transit core's protocol) and E-IP (the client networks' protocol). Only AFBRs need to support both address families; P routers support only I-IP and CE routers support only E-IP.
Use of labeled IPv4 or labeled IPv6 address families is OPTIONAL and allows the egress AFBR to associate an MPLS label with each IP prefix, enabling demultiplexing and performance enhancement at the egress.
When the core supports mLDP, each E-IP SSM (S,G) tree can be mapped one-to-one onto a P2MP LSP rooted at the upstream AFBR. The original (S,G) is algorithmically encoded into the mLDP FEC identifier and must be standardized.
Cryptographic techniques cannot prevent flooding/DoS attacks on tunnel receiving endpoints; applying crypto to spoofed packets increases processing cost and trades one attack vector for another. Non-cryptographic ingress filtering or address segregation is recommended within a single domain.
Encapsulation headers must appear in the clear to be processed by P routers, making them vulnerable to spoofing and replay attacks. An unauthorized node could send encapsulated packets to a receiving endpoint, causing policy violations by bypassing authorized ingress filtering.
Non-cryptographic defenses include giving tunnel endpoints distinct addresses known to border routers for ingress filtering, and using cleartext 64-bit L2TPv3 cookies as passwords—effective within a domain where packet interception is infeasible, but insufficient across domain boundaries.