RFC 5565

Softwire Mesh Framework

📅 published June 2009, from ietf

RFC 5565: Softwire Mesh Framework 🎀

okay bestie, this one is RFC 5565: Softwire Mesh Framework 🦋 It's a Standards Track doc from June 2009, so it's an actual Internet standards track protocol spec ✨ The authors are J. Wu and Y. Cui from Tsinghua University, plus C. Metz and E. Rosen from Cisco Systems, Inc. 💅 The header doesn't include any Obsoletes or Updates line, so it isn't replacing or amending any other RFC listed there 🌸

Status of This Memo ✨

this doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 💖 If you want the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 🔍 Distribution of this memo is unlimited 🌈

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, since they describe your rights and restrictions with respect to this document 📜

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English 🙈

Abstract 🧚

so the Internet has to handle both IPv4 and IPv6 packets 💜 But some of its networks are expected to be "single-protocol" networks, which is giving very focused energy. One kind can only parse IPv4 packets and only process IPv4 routing information 🍓 The other kind can only parse IPv6 packets and only process IPv6 routing information 🍓 Even so, either kind still needs to provide transit service for the "other" protocol 😭 The way that works is by passing the "other kind" of routing information from one edge of the single-protocol network to the other edge, and by tunneling the "other kind" of data packet across from one edge to the other 🔥 Those tunnels are called "softwires" ✨

This framework document explains how the routing information and data packets of one protocol get passed through a single-protocol network of the other protocol 👑 It's also careful about the difference between what can be done with existing technology and what needs new or modified technology, so you always know which is which 💅

Table of Contents 📚

1. Introduction ....................................................3
2. Specification of Requirements ...................................6
3. Scenarios of Interest ...........................................7
   3.1. IPv6-over-IPv4 Scenario ....................................7
   3.2. IPv4-over-IPv6 Scenario ....................................9
4. General Principles of the Solution .............................10
   4.1. E-IP and I-IP .............................................10
   4.2. Routing ...................................................10
   4.3. Tunneled Forwarding .......................................11
5. Distribution of Inter-AFBR Routing Information .................11
6. Softwire Signaling .............................................13
7. Choosing to Forward through a Softwire .........................15
8. Selecting a Tunneling Technology ...............................15
9. Selecting the Softwire for a Given Packet ......................16
10. Softwire OAM and MIBs .........................................17
   10.1. Operations and Maintenance (OAM) .........................17
   10.2. MIBs .....................................................18
11. Softwire Multicast ............................................18
   11.1. One-to-One Mappings ......................................18
        11.1.1. Using PIM in the Core .............................19
        11.1.2. Using mLDP and Multicast MPLS in the Core .........20
   11.2. MVPN-Like Schemes ........................................21
12. Inter-AS Considerations .......................................22
13. Security Considerations .......................................23
   13.1. Problem Analysis .........................................23
   13.2. Non-Cryptographic Techniques .............................24
   13.3. Cryptographic Techniques .................................26
14. References ....................................................27
   14.1. Normative References .....................................27
   14.2. Informative References ...................................28
15. Contributors ..................................................30
16. Acknowledgments ...............................................30

1. Introduction ✨

okay bestie, let's talk routing 💅 every IP backbone's routing info falls into one of two buckets: "internal routing information" or "external routing information" 🧚. Internal routing info is the routes to the nodes that belong to the backbone, plus the interfaces on those nodes. External routing info is the routes to destinations beyond the backbone, especially ones the backbone isn't directly attached to. Usually BGP [RFC4271] is the one distributing external routing info, while an Interior Gateway Protocol (IGP) like OSPF [RFC2328] or IS-IS [RFC1195] handles the internal stuff 🦋

Often a backbone is doing transit work too, meaning packets come from outside, have destinations outside, and just pass through 🚗 These packets enter at one of the backbone's "edge routers", get routed across to another edge router, and then leave and carry on with their lives. The edge nodes are often called "Provider Edge" (PE) routers. The "ingress" (or "ingress PE") is where a packet gets in, and the "egress" (or "egress PE") is where it gets out. The interior nodes are often called "P routers" 🌸 Routers that sit outside the backbone but are directly attached to it are called "Customer Edge" (CE) routers. (This terminology is taken from [RFC4364].)

When a packet's destination is outside the backbone, the routing info the backbone needs to get that packet to the right egress is, by definition, external routing info. Iconic 💀

Traditionally, BGP has passed external routing info to every router in the backbone, not just the edge ones (aka not just the ingress and egress points). Each interior node was expected to look up the packet's destination address and send it toward the egress. This is called "native forwarding": the interior nodes peek into each packet's header and match what they find against the external routing info 👀

Here's the twist though 🎀 it's totally possible to provide transit services without every backbone router needing the external routing info. The routing info that BGP hands each ingress router says which egress router goes with each route. So the ingress router can "tunnel" the packet straight to the egress router. "Tunneling the packet" means slapping on some sort of encapsulation header that forces the interior routers to forward the packet to the egress router 🫶 The original packet is called the "encapsulation payload". The P routers don't look at the payload's packet header, only at the encapsulation header. And since the path to the egress is part of the backbone's internal routing info, the interior routers don't need to know the external routing info at all. This is called "tunneled forwarding". Of course, before the packet can leave the egress, it has to be decapsulated ✨

The scenario where the P routers don't have external routes is sometimes called a "BGP-free core". That's kind of a misnomer, tbh 🙈 the crucial part isn't that the interior nodes don't run BGP, it's that they don't maintain the external routing info.

Lately we've seen this setup deployed for VPN services, as specified in [RFC4364] 💜 An edge router keeps multiple independent routing/addressing spaces, one for each VPN it connects to. But the VPN routing info isn't kept by the interior routers. In most of these setups, MPLS is the encapsulation mechanism that gets packets from ingress to egress. There are some deployments using an IP-based encapsulation instead, like L2TPv3 (Layer 2 Transport Protocol) [RFC3931] or GRE (Generic Routing Encapsulation) [RFC2784].

This same technique is also handy when the external routing info is not VPN routes, but "ordinary" Internet routes 🌈 It can be used any time you want to keep external routing info out of a backbone's interior nodes, or really any time you want to avoid native forwarding of certain kinds of packets for any reason.

This framework focuses on two such scenarios 👑

  1. In this scenario, the backbone's interior nodes support only IPv6. They don't maintain IPv4 routes at all, and they aren't expected to parse IPv4 packet headers. Yet it's still desired to use this backbone to provide transit services for IPv4 packets, so tunneled forwarding of IPv4 packets is required. Of course, the edge nodes must have the IPv4 routes, but the ingress has to do an encapsulation to get an IPv4 packet forwarded to the egress 😭
  2. This scenario is the reverse of scenario 1, i.e., the backbone's interior nodes support only IPv4, but it's desired to use the backbone for IPv6 transit 🔥

In these scenarios, a backbone whose interior nodes support only one of the two address families is required to provide transit services for the other. The backbone's edge routers must, of course, support both address families. We call these PE routers "Address Family Border Router" (AFBR) routers 💖 and the tunnels used for forwarding are called "softwires" 🧚

These two scenarios are known as the "Softwire Mesh Problem" [SW-PROB], and the framework specified in this document is therefore known as the "Softwire Mesh Framework" 🦋 In this framework, only the AFBRs need to support both address families. The CE routers support only a single address family, and the P routers support only the other one.

There are a lot of ways to tackle these scenarios with different tunneling technologies, and this framework doesn't mandate any particular one 🍓 In any given deployment, picking a tunneling technology is a matter of policy. The framework accommodates at least MPLS ([RFC3031], [RFC3032]), both LDP-based (Label Distribution Protocol, [RFC5036]) and RSVP-TE-based (Resource Reservation Protocol - Traffic Engineering, [RFC3209]), plus L2TPv3 [RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003]. It'll also accommodate IPsec tunneling, when that's needed to meet security requirements 🔐

In a lot of deployments, the tunneling choice will come down to a simple policy line, like "always use IP-IP tunnels", "always use LDP-based MPLS", or "always use L2TPv3" 💅

Other deployments might have a mix of routers, where some support, say, both GRE and L2TPv3, but others support only one of those techniques 🌸 So it's desirable to let the network admin create a small set of classes and configure each AFBR as a member of one or more of them. Then the routers can advertise their class memberships to each other, and encapsulation policies can be written as, e.g., "use L2TPv3 to tunnel to routers in class X; use GRE to tunnel to routers in class Y". To support this, the AFBRs need to be able to advertise their class memberships, and a standard way of doing that must be developed 🧚

Policy might also require a certain class of traffic to get a certain quality of service, and that can affect which tunnel and/or tunneling technology is used for packets in that class. The Softwire Mesh Framework needs to accommodate this too ✨

Using tunneled forwarding often requires some sort of signaling protocol to set up and/or maintain the tunnels 🫶 Many of the tunneling technologies this framework accommodates already have their own signaling protocols. But some don't, and sometimes the standard signaling protocol for a particular tunneling technology isn't appropriate (for one reason or another) in the scenarios of interest. In such cases (and in such cases only), new signaling methodologies need to be defined and standardized 💜

In this framework, the softwires do not form an overlay topology that's visible to routing. Routing adjacencies aren't maintained over the softwires, and routing control packets aren't sent through them. Routing adjacencies among backbone nodes (including the edge nodes) are maintained via the backbone's native technology 🌈

BGP is already a standard routing method for distributing external routing info among AFBRs. But in the scenarios of interest, we might be using IPv6-based BGP sessions to pass IPv4 routing info, and IPv4-based BGP sessions to pass IPv6 routing info 🙈 Also, when IPv4 traffic is tunneled over an IPv6 backbone, the "BGP next hop" for an IPv4 route has to be encoded as an IPv6 address, and vice versa. The method for encoding an IPv4 address as the next hop for an IPv6 route is specified in [V6NLRI-V4NH], and the method for encoding an IPv6 address as the next hop for an IPv4 route is specified in [V4NLRI-V6NH] 👑

2. Specification of Requirements ✨

okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💖

3. Scenarios of Interest 🦋

3.1. IPv6-over-IPv4 Scenario 🦋

okay so in this scenario, the client networks are running IPv6 but the backbone network is running IPv4 🌸 Figure 1 shows the setup:

                      +--------+   +--------+
                      |  IPv6  |   |  IPv6  |
                      | Client |   | Client |
                      | Network|   | Network|
                      +--------+   +--------+
                          |   \     /   |
                          |    \   /    |
                          |     \ /     |
                          |      X      |
                          |     / \     |
                          |    /   \    |
                          |   /     \   |
                      +--------+   +--------+
                      |  AFBR  |   |  AFBR  |
                   +--| IPv4/6 |---| IPv4/6 |--+
                   |  +--------+   +--------+  |
   +--------+      |                           |       +--------+
   |  IPv4  |      |                           |       |  IPv4  |
   | Client |      |                           |       | Client |
   | Network|------|            IPv4           |-------| Network|
   +--------+      |            only           |       +--------+
                   |                           |
                   |  +--------+   +--------+  |
                   +--|  AFBR  |---|  AFBR  |--+
                      | IPv4/6 |   | IPv4/6 |
                      +--------+   +--------+
                        |   \     /   |
                        |    \   /    |
                        |     \ /     |
                        |      X      |
                        |     / \     |
                        |    /   \    |
                        |   /     \   |
                     +--------+   +--------+
                     |  IPv6  |   |  IPv6  |
                     | Client |   | Client |
                     | Network|   | Network|
                     +--------+   +--------+

                 Figure 1: IPv6-over-IPv4 Scenario

The IPv4 transit core may or may not run MPLS. If it does, MPLS may be used as part of the solution. 💅

While Figure 1 doesn't show any "backdoor" connections among the client networks, this framework assumes there will be such connections 👀 So there's no assumption that the only path between two client networks goes through the pictured transit-core network. Hence, the routing solution must be robust in any kind of topology. 🫶

Many mechanisms for giving IPv6 connectivity across IPv4 networks have been devised over the past ten years 🌈 Some tunneling mechanisms were provisioned manually, and others were based on special addressing. More recently, L3VPN (Layer 3 Virtual Private Network) techniques from [RFC4364] have been extended to provide IPv6 connectivity, using MPLS in the AFBRs and, optionally, in the backbone [V6NLRI-V4NH]. The solution in this framework can be thought of as a superset of [V6NLRI-V4NH], with a more generalized scheme for choosing the tunneling (softwire) technology. In this framework, MPLS is allowed -- but not required -- even at the AFBRs. As in [V6NLRI-V4NH], there's no manual provisioning of tunnels, and no special addressing is required. ✨

3.2. IPv4-over-IPv6 Scenario 🧚

Flip it! In this scenario, the client networks run IPv4 but the backbone network runs IPv6. Figure 2 has the picture:

                      +--------+   +--------+
                      |  IPv4  |   |  IPv4  |
                      | Client |   | Client |
                      | Network|   | Network|
                      +--------+   +--------+
                          |   \     /   |
                          |    \   /    |
                          |     \ /     |
                          |      X      |
                          |     / \     |
                          |    /   \    |
                          |   /     \   |
                      +--------+   +--------+
                      |  AFBR  |   |  AFBR  |
                   +--| IPv4/6 |---| IPv4/6 |--+
                   |  +--------+   +--------+  |
   +--------+      |                           |       +--------+
   |  IPv6  |      |                           |       |  IPv6  |
   | Client |      |                           |       | Client |
   | Network|------|            IPv6           |-------| Network|
   +--------+      |            only           |       +--------+
                   |                           |
                   |  +--------+   +--------+  |
                   +--|  AFBR  |---|  AFBR  |--+
                      | IPv4/6 |   | IPv4/6 |
                      +--------+   +--------+
                        |   \     /   |
                        |    \   /    |
                        |     \ /     |
                        |      X      |
                        |     / \     |
                        |    /   \    |
                        |   /     \   |
                     +--------+   +--------+
                     |  IPv4  |   |  IPv4  |
                     | Client |   | Client |
                     | Network|   | Network|
                     +--------+   +--------+

                 Figure 2: IPv4-over-IPv6 Scenario

The IPv6 transit core may or may not run MPLS. If it does, MPLS may be used as part of the solution. 💖

While Figure 2 doesn't show any "backdoor" connections among the client networks, this framework assumes there will be such connections 🙈 Again, there's no assumption that the only path between two client networks goes through the pictured transit-core network. Hence, the routing solution must be robust in any kind of topology. 💅

While IPv6-over-IPv4 has gotten a lot of attention in the past, IPv4-over-IPv6 really hasn't 😭 And yet it's a significant emerging requirement, because a bunch of service providers are building IPv6 backbone networks and don't want to provide native IPv4 support in their core routers. These providers have a huge legacy of IPv4 networks and applications that need to keep working across their IPv6 backbone. Solutions for this don't exist yet, because it had always been assumed that the backbone networks of the foreseeable future would be dual stack. 👑

4. General Principles of the Solution 🌸

This section gives a very brief overview of the procedures. The subsequent sections go into more detail. 🍓

4.1. E-IP and I-IP 🎀

In the following sections, we use the term "I-IP" (Internal IP) to refer to the form of IP (i.e., either IPv4 or IPv6) that's supported by the transit network. We use the term "E-IP" (External IP) to refer to the form of IP that's supported by the client networks. In the scenarios of interest, E-IP is IPv4 if and only if I-IP is IPv6, and E-IP is IPv6 if and only if I-IP is IPv4. 🔥

We assume the P routers support only I-IP. That is, they're expected to have only I-IP routing information, and they're not expected to be able to parse E-IP headers. We similarly assume the CE routers support only E-IP. 🧚

The AFBRs handle both I-IP and E-IP. However, only I-IP is used on AFBR's "core-facing interfaces", and E-IP is only used on its client-facing interfaces. 💜

4.2. Routing 🌈

The P routers and the AFBRs of the transit network take part in an IGP for the purpose of distributing I-IP routing information. 🫶

The AFBRs use Internal BGP (IBGP) to exchange E-IP routing information with each other. Either there's a full mesh of IBGP connections among the AFBRs, or some or all of the AFBRs are clients of a BGP Route Reflector. Although these IBGP connections are used to pass E-IP routing information (i.e., the Network Layer Reachability Information (NLRI) of the BGP updates is in the E-IP address family), the IBGP connections run over I-IP, and the BGP next hop for each E-IP NLRI is in the I-IP address family. ✨

4.3. Tunneled Forwarding 💅

When an ingress AFBR receives an E-IP packet from a client-facing interface, it looks up the packet's destination IP address. In the scenarios of interest, the best match for that address will be a BGP-distributed route whose next hop is the I-IP address of another AFBR, the egress AFBR. 👑

The ingress AFBR must forward the packet through a tunnel (i.e, through a softwire) to the egress AFBR. This is done by encapsulating the packet, using an encapsulation header that the P routers can process and that will cause the P routers to send the packet to the egress AFBR. The egress AFBR then extracts the payload, i.e., the original E-IP packet, and forwards it further by looking up its IP destination address. 🦋

Several kinds of tunneling technologies are supported. Some of those technologies require explicit AFBR-to-AFBR signaling before the tunnel can be used, and others don't. 🌸

Transmitting a packet through a softwire always requires that an encapsulation header be added to the original packet. The resulting packet is therefore always longer than the encapsulation payload. As an operational matter, the Maximum Transmission Unit (MTU) of the softwire's path SHOULD be large enough so that (a) no packet will need to be fragmented before being encapsulated, and (b) no encapsulated packet will need to be fragmented while it's being forwarded along a softwire. A general discussion of MTU issues in the context of tunneled forwarding may be found in [RFC4459]. 🍓

5. Distribution of Inter-AFBR Routing Information ✨

okay so AFBRs have to peer with routers in the client networks to swap routing info for the E-IP family 💅

Then they use BGP to pass that E-IP routing info to each other 🦋 You can do this with an AFBR-AFBR mesh of IBGP sessions, but ngl it's way more likely to go through a BGP Route Reflector, so each AFBR just has an IBGP session to one or two Route Reflectors instead of to other AFBRs. Reflector is the main character here 👑

The BGP sessions between the AFBRs, or between the AFBRs and the Route Reflector, run on top of the I-IP address family. So if the transit core only supports IPv6, the IBGP sessions carrying IPv4 routing info from the client networks run over IPv6. If the core only supports IPv4, the sessions carrying IPv6 routing info from the client networks run over IPv4. The BGP sessions use the core's native networking layer, and BGP messages are NOT tunneled through softwires or through any other mechanism. It's giving native, no detours 🌸

In BGP, a routing update links an address prefix (or, more generally, NLRI) to the address of a BGP next hop (NH). The NLRI belongs to one address family. The NH address also belongs to an address family, which can be the same as the NLRI's or a different one. Usually, the NH address is in the address family used to talk to the BGP speaker that owns that NH address.

Because routing updates about E-IP address prefixes travel over BGP sessions that use I-IP transport, and because the BGP messages aren't tunneled, a BGP update about an E-IP address prefix has to specify an NH address in the I-IP family 🧚

Here's the tricky bit: when the NLRI and the NH in a BGP update are in different address families, it's not always obvious how the NH should be encoded, thanks to a bunch of historical stuff. Each pair of address families has its own encoding procedure 🙈

If the NLRI is IPv6 and the NH is IPv4, [V6NLRI-V4NH] explains how to encode the NH.

If the NLRI is IPv4 and the NH is IPv6, [V4NLRI-V6NH] explains how to encode the NH.

If a BGP speaker sends an update for an NLRI in the E-IP family, the update goes over a BGP session running on top of the I-IP network layer, and the BGP speaker is advertising itself as the NH for that NLRI, then the BGP speaker MUST, unless explicitly overridden by policy, specify the NH address in the I-IP family. The address family of the NH MUST NOT be changed by a Route Reflector. Hands off the NH family, reflector 🙅‍♀️

Sometimes (for example, when [V4NLRI-V6NH] is used), you can't follow this rule unless your BGP peers have advertised a particular BGP capability. That leads to this softwire deployment restriction: if a BGP capability is defined for the case where an E-IP NLRI has an I-IP NH, then all the AFBRs in a given transit core MUST advertise that capability. Everyone has to be on the same page or it's a mess 💀

If an AFBR has multiple IP addresses, the network admins usually get to pick which one the AFBR uses to identify itself as the next hop in a BGP update, so they have a lot of flexibility. BUT, if the AFBR expects to receive packets through a softwire of a particular tunneling technology, and that tunneling technology knows the AFBR by a specific IP address, then that same IP address must be used to identify the AFBR in the next hop field of the BGP updates. For example, if L2TPv3 tunneling is used, the IP address the AFBR uses for L2TPv3 signaling must be the same as the IP address it uses to identify itself in the next hop field of a BGP update. Consistency is everything, bestie 🎀

In [V6NLRI-V4NH], IPv6 routing info is distributed using the labeled IPv6 address family. This lets the egress AFBR associate an MPLS label with each IPv6 address prefix. If an ingress AFBR forwards packets through a softwire that can carry MPLS packets, each data packet can carry the MPLS label that matches the IPv6 route it matched. This may be useful at the egress AFBR for demultiplexing and/or better performance ✨ The document also says it's possible to do the same for the IPv4 address family, i.e., to use the labeled IPv4 address family instead of the IPv4 address family. Using the labeled IP address families this way is OPTIONAL. Your call 🫶

6. Softwire Signaling 🦋

A mesh of inter-AFBR softwires spanning the transit core must be in place before packets can flow between client networks. With N dual-stack AFBRs, that means N^2 "point-to-point IP" or "label switched path" (LSP) tunnels. Sure, in theory you could configure them all by hand, but that would be a super undesirable O(N^2) provisioning nightmare 😭 So manual configuration of point-to-point tunnels is not considered part of this framework. Nope, not doing that.

Since the transit core is providing layer 3 transit services, point-to-point tunnels aren't required by this framework. Multipoint-to-point tunnels are all you need. In a multipoint-to-point tunnel, when a packet comes out of the tunnel, there's no way to tell which router put it in. This matches the native IP forwarding vibe, where the egress router can't figure out a packet's ingress router either 🌈 Point-to-point tunnels might still be needed for some reason beyond the basic requirements in this document. For example, Quality of Service (QoS) or security considerations might call for them. So point-to-point tunnels are allowed, but not required, by this framework 💜

If you want a particular tunneling technology for the softwires, and that technology has its own "native" signaling method, the presumption is that the native signaling gets used. This definitely applies to MPLS-based softwires, where LDP or RSVP-TE would be used. An IPsec-based softwire would use standard IKEv2 (Internet Key Exchange) [RFC4306] and IPsec [RFC4301] signaling, because that's necessary to guarantee the softwire's security properties 🔥

A GRE-based softwire might or might not need signaling, depending on whether various optional GRE header fields are going to be used. GRE doesn't have any "native" signaling, so for those cases, a signaling procedure needs to be developed to support softwires.

Another possible softwire technology is L2TPv3. L2TPv3 does have its own native signaling, but that signaling sets up point-to-point tunnels. For softwires, it's better to use L2TPv3 in a multipoint-to-point mode, and that needs a different kind of signaling.

The signaling for GRE and L2TPv3 to cover these scenarios is BGP-based, and it's described in [RFC5512] 🫶

If IP-IP tunneling is used, or GRE tunneling is used without options, no signaling is required. The only info the ingress AFBR needs to build the encapsulation header is the IP address of the egress AFBR, and BGP already distributes that. Easy peasy 🍓

When the encapsulation IP header is built, some fields in the IP header might have values that are determined neither by whatever signaling was done nor by the distributed routing info. The values of these fields are determined by policy in the ingress AFBR. Examples of such fields are the TTL (Time to Live) field, the DSCP (Diffserv Service Classes) bits, etc. 💅

It's desirable for all the necessary softwires to be fully set up before any packets that need to go through them arrive. In other words, the softwires should be "always on" 💖 From the perspective of any given AFBR, the softwire endpoints are always BGP next hops of routes that the AFBR has installed. This suggests that any necessary softwire signaling should either be done as part of normal system startup (as would happen, e.g., with LDP-based MPLS), or else be triggered by the reception of BGP routing info (such as is described in [RFC5512]). It also helps if distribution of the routing info that serves as the trigger gets prioritized ⭐

7. Choosing to Forward through a Softwire 🎀

The decision to forward through a softwire, instead of forwarding natively, is made by the ingress AFBR. This decision is a matter of policy 👑

In many cases the policy will be super simple. Some useful policies are:

  • If routing says that an E-IP packet has to be sent out a core-facing interface to an I-IP core, then send the packet through a softwire.
  • If routing says that an E-IP packet has to be sent out an interface that only supports I-IP packets, then send the E-IP packet through a softwire.
  • If routing says that the BGP next hop address for an E-IP packet is an I-IP address, then send the E-IP packet through a softwire.
  • If the route that is the best match for a particular packet's destination address is a BGP-distributed route, then send the packet through a softwire (i.e., tunnel all BGP-routed packets).

More complicated policies are also possible, but thinking through those is outside the scope of this document 🦋

8. Selecting a Tunneling Technology ✨

okay so, which tunnel to use is a policy thing that gets configured at the ingress AFBR 🎀

in most cases the policy is gonna be super simple and the same on every AFBR in a given transit core, like "always use LDP-based MPLS" or "always use L2TPv3" 💅

but real networks are messy 🙈 some routers might support both GRE and L2TPv3 while others only do one of them. so it's really useful to let the network admin make a small set of classes and put each AFBR into one or more of them 🧚 then the routers can tell each other which classes they're in, and the policy can say stuff like "use L2TPv3 to talk to routers in class X; use GRE to talk to routers in class Y." 🦋 for that to work, the AFBRs need a way to advertise their class memberships. [RFC5512] is the one that specifies how an AFBR advertises characteristics that matter for policy, like "I belong to class Y" 💜 a lot of the time those characteristics can be represented by arbitrarily selected communities or extended communities, and the ingress policies can be written in terms of those classes (aka communities) ✨

policy might also say a certain class of traffic needs a certain quality of service, and that can affect which tunnel, or which tunneling technology, handles those packets 🌸 this framework lets a bunch of different tunneling technologies be used to set up softwires. and yep, the choice of tunneling technology is a policy matter, same as we talked about in Section 1 🫶

in plenty of cases the policy is unconditional, like "always use L2TPv3 for softwires" 💖 but sometimes the choice depends on info about the softwire's remote endpoint, e.g. "use L2TPv3 to talk to routers in class X; use GRE to talk to routers in class Y." so again, it's useful to have a small set of classes, with each AFBR a member of one or more of them. if each class is represented as a community or extended community, [RFC5512] has a method AFBRs can use to advertise their class memberships to each other 🔥

this framework also works with policies of arbitrary complexity 🌈 those can depend on characteristics or attributes of individual address prefixes, and on QoS or security considerations too. BUT (and this is important) writing those policies is not in scope for this document 😭

9. Selecting the Softwire for a Given Packet

okay so say we've already decided a given packet is going through a softwire 👑 routing gives us the address of the BGP next hop, in the address family of the transport network. and the packet MUST be sent through a softwire whose remote endpoint address is the same as that BGP next hop address. no exceptions, bestie 💅

sending a packet through a softwire means first wrapping it in an encapsulation header that the transit network can process, and then transmitting it toward the softwire's remote endpoint address 🦋

honestly once you know the remote endpoint address, you often have everything you need to build the encapsulation header ✨ that's the case when the tunnel technology is, e.g., LDP-based MPLS, IP-in-IP, or GRE without optional header fields 🧚

if the tunnel technology is L2TPv3 or GRE with optional header fields, though, you need extra info from the remote endpoint to build the header 🙈 the procedures for sending and receiving that info are described in [RFC5512] 💜

if the tunnel technology is RSVP-TE-based MPLS or IPsec, then the native signaling procedures of those technologies are what you'll need to use 🔥

now, if the packet being sent through the softwire matches a route in the labeled IPv4 or labeled IPv6 address families, it should be sent through the softwire as an MPLS packet with the corresponding label 🌸 and here's the cute part: most of the tunneling technologies in this document can carry MPLS packets, so this does NOT mean the core routers have to support MPLS 🎀

10. Softwire OAM and MIBs

10.1. Operations and Maintenance (OAM)

softwires are basically tunnels connecting routers 🌈 if they disappear or get slow, the connectivity going through them takes a hit 😭 there are several techniques for keeping an eye on the status of both the tunnel endpoints (AFBRs) and the tunnels themselves. they make stuff like softwire path tracing, remote softwire endpoint pinging, and remote softwire endpoint liveness failure detection possible 🦋

some examples of techniques that work for softwire OAM:

  • BGP/TCP timeouts between AFBRs
  • ICMP or LSP echo request and reply addressed to a particular AFBR
  • BFD (Bidirectional Forwarding Detection) [BFD] packet exchange between AFBR routers

another option is to build something similar to [RFC4378], or in other words, to create and generate softwire echo request/reply packets 🧚 the echo request, sent to a well-known UDP port, would carry the egress AFBR IP address and the softwire identifier in its payload (kinda like the MPLS Forwarding Equivalence Class in the LSP echo request) 💖 the softwire echo packet gets encapsulated with the encapsulation header and sent across the same path (inband) as the softwire itself ✨

this can also be automated to periodically check remote softwire endpoint reachability 👑 when reachability is lost, that gets signaled to the softwire application on the local AFBR, so suitable actions can be taken 🔥 but the trade-offs are real: you have to think about how scalable these mechanisms are versus how fast they detect a loss of endpoint reachability 🙈

overall, a softwire OAM framework can mostly be based on the [RFC4176] framework 🌸

10.2. MIBs

there are specific MIBs that already exist to manage elements of the Softwire Mesh Framework 💜 BUT we'll need to either extend those MIBs or create new ones that reflect the functional elements that can be SNMP-managed within the softwire network 🎀

11. Softwire Multicast

okay multicast time 🌈 a set of client networks running E-IP that are connected to a provider's I-IP transit core might want to run IP multicast applications 🦋 there are a bunch of ways to extend multicast connectivity across the transit core, and each one has its own set of characteristics 💅 most of them (though not all) are slight variations on the procedures defined for L3VPNs in [L3VPN-MCAST] ✨

we're focusing on the multicast features and protocols that are typically used across inter-provider boundaries 🫶 so support is provided for PIM-SM (Protocol Independent Multicast - Sparse Mode) and PIM-SSM (PIM Source-Specific Mode) 🔥 but support for BIDIR-PIM (Bidirectional PIM), BSR (Bootstrap Router Mechanism for PIM), and AutoRP (Automatic Rendezvous Point Determination) is NOT provided, because those features aren't typically used across inter-provider boundaries 🙈

11.1. One-to-One Mappings

in the "one-to-one mapping" scheme, each client multicast tree gets extended through the transit core so that for each client tree there's exactly one tree through the core 🧚

the one-to-one scheme isn't used in [L3VPN-MCAST] because it needs an amount of state in the core routers that's proportional to the number of client multicast trees passing through the core 😭 in the VPN context that's considered undesirable, since the amount of state is unbounded and out of the service provider's control 💀 BUT the one-to-one scheme models the typical "Internet multicast" scenario, where the client network and the transit core are both IPv4 or both IPv6 🌸 and if it scales satisfactorily for that case, it should also scale satisfactorily for the case where the client network and the transit core support different versions of IP 👑

11.1.1. Using PIM in the Core

okay bestie, so when an AFBR gets an E-IP PIM control message from one of its CEs, it translates that message from E-IP to I-IP and forwards it toward the source of the tree 🧚. The routers in the transit core usually don't have a route to the source of the tree, so the AFBR must include an "RPF (Reverse Path Forwarding) Vector" [RFC5496] in the PIM message. This is giving main character energy 💅

Say AFBR A gets an E-IP PIM Join/Prune message from a CE, either for an (S,G) tree or a (*,G) tree. A has to "translate" that PIM message into an I-IP PIM message, then send it to the neighbor that is the next hop along the route to the root of the (S,G) or (*,G) tree. For an (S,G) tree, the root is S. For a (*,G) tree, the root is the Rendezvous Point (RP) for group G 🌸

Here's the thing: the root's address is an E-IP address. The routers inside the transit core (other than the AFBRs) don't have routes to E-IP addresses, so A has to put an RPF Vector [RFC5496] in the PIM Join/Prune message it sends to its upstream neighbor 🎀 That RPF Vector identifies, as an I-IP address, AFBR B, which is the egress point in the transit network along the route to the root of the multicast tree. B is A's BGP next hop for the route to the root. The RPF Vector is what lets the core routers forward PIM Join/Prune messages upstream toward the root, even though they don't keep E-IP routes. Iconic 🙌

To translate an E-IP PIM message into an I-IP one, AFBR A has to convert the address of S (for an (S,G) group) or the address of G's RP from the E-IP address family to the I-IP address family. AFBR B then converts them back ✨

If E-IP is IPv4 and I-IP is IPv6, this translation might be doable algorithmically. A can map the IPv4 S into the corresponding IPv4-mapped IPv6 address [RFC4291], and then B can map it back 🦋 At the time of writing, there is no such thing as an IPv4-mapped IPv6 multicast address. But if one were ever standardized, A could also translate the IPv4 G into IPv6, and B could translate it back. The precise circumstances under which these translations are done would be a matter of policy 🧁

Obviously, this translation procedure doesn't generalize to the case where the client multicast is IPv6 but the core is IPv4 😭 To handle that, you need additional signaling between the two AFBRs. Each downstream AFBR needs to signal the upstream AFBR that it needs a multicast tunnel for (S,G). The upstream AFBR then has to assign a multicast address G' to the tunnel and tell the downstream AFBR which P-G value to use. The downstream AFBR then uses PIM/IPv4 to join the (S',G') tree, where S' is the IPv4 address of the upstream ASBR (Autonomous System Border Router) 💜

The (S',G') trees should be SSM trees.

⚠️ Heads up: this procedure can support client multicasts of either IPv4 or IPv6 over a transit core of the opposite protocol. But it only works when the client multicasts are SSM, because there's no way to map a client "prune a source off the (*,G) tree" operation onto an operation on the (S',G') tree. This method also needs extra signaling. The BGP-based signaling of [L3VPN-MCAST-BGP] is one signaling method that could be used. Other signaling methods could be defined too 🫶

11.1.2. Using mLDP and Multicast MPLS in the Core

LDP extensions for point-to-multipoint and multipoint-to-multipoint LSPs are specified in [MLDP]. We'll say "mLDP" to mean those LDP extensions 🌈 If the transit core implements mLDP and supports multicast MPLS, then client Source-Specific Multicast (SSM) trees can be mapped one-to-one onto P2MP (Point-to-Multipoint) LSPs. Literally so clean 🧚

When AFBR A gets an E-IP PIM Join/Prune message for (S,G) from one of its CEs, where G is an SSM group, it uses mLDP to join a P2MP LSP. The root of that P2MP LSP is AFBR B, which is A's BGP next hop on the route to S. In mLDP, a P2MP LSP is uniquely identified by its root plus a "FEC (Forwarding Equivalence Class) identifier". The original (S,G) can be algorithmically encoded into the FEC identifier, so all the AFBRs that need to join the P2MP LSP for (S,G) generate the same FEC identifier 🍓 When the root of the P2MP LSP (AFBR B) receives such an mLDP message, it extracts the original (S,G) from the FEC identifier, creates an "ordinary" E-IP PIM Join/Prune message, and sends it to the CE that is its next hop on the route to S ✨

The method for encoding (S,G) into the FEC identifier needs to be standardized. The encoding must be self-identifying, so that a node that is the root of a P2MP LSP can tell whether a FEC identifier came from encoding a PIM (S,G) 🔥

The right state machinery needs to be standardized so that PIM events at the AFBRs result in the proper mLDP events. For example, if an AFBR determines (via PIM procedures) that it no longer has any downstream receivers for (S,G), the AFBR should invoke the proper mLDP procedures to prune itself off the corresponding P2MP LSP 🙈

Note that this method can't be used when G is a Sparse Mode group 💀 The reason is that mLDP has no function corresponding to the PIM "prune this source off the shared tree" function. So if a P2MP LSP were mapped one-to-one with a P2MP LSP, duplicate traffic could end up traversing the transit core (that is, traffic from S might travel down both the shared tree and S's source tree). Alternatively, you could devise an AFBR-to-AFBR protocol to prune sources off the P2MP LSP at the root of the LSP. It is recommended, though, that client SM multicast groups be supported by other methods, such as the ones discussed below 🦋

Client-side bidirectional multicast groups set up by PIM-bidir could be mapped with the technique above onto MP2MP (Multipoint-to-Multipoint) LSPs set up by mLDP [MLDP]. We won't consider this further, since inter-provider bidirectional groups aren't in use anywhere 🌸

11.2. MVPN-Like Schemes

The "MVPN (Multicast VPN)-like schemes" are the ones described in [L3VPN-MCAST] and its companion documents (such as [L3VPN-MCAST-BGP]). To apply those schemes to the softwire environment, you only need to treat all the AFBRs of a given transit core as if they were, for multicast purposes, PE routers attached to the same VPN 👑

The MVPN-like schemes don't require a one-to-one mapping between client multicast trees and transit-core multicast trees. In the MVPN environment, it's a requirement that the number of trees in the core scales less than linearly with the number of client trees. That requirement may not hold in softwire scenarios 💅

The MVPN-like schemes can support SM, SSM, and Bidir groups. They offer a number of control plane options:

  • LAN-like

Use a set of multicast trees in the core to emulate a LAN (Local Area Network), and run the client-side PIM protocol over that "LAN". The "LAN" can be a single Bidir tree containing all the AFBRs, or a set of SSM trees, one rooted at each AFBR and containing all the other AFBRs as receivers ✨

  • NBMA (Non-Broadcast Multiple Access), using BGP

The client-side PIM signaling can be translated into BGP-based signaling, with a BGP Route Reflector mediating the signaling 🫶

These two basic options have lots of variations, and a full discussion is in [L3VPN-MCAST] 🧚

For the data plane, there are also several options:

  • All multicast data is sent over the emulated LAN. This one isn't very attractive for softwire scenarios, though, because every AFBR would have to receive every client multicast packet 😭
  • Every multicast group is mapped to a tree that's considered appropriate for that group, in the sense of not causing the traffic of that group to go to "too many" AFBRs that don't need to receive it 🍓

Again, you can find a full discussion of these issues in [L3VPN-MCAST] 🌈

12. Inter-AS Considerations ✨

We've only looked at the case where a "transit core" consists of a single Autonomous System (AS) so far 🦋 If the transit core consists of multiple ASes, it may be necessary to use softwires whose endpoints are AFBRs attached to different Autonomous Systems. In that case, the AFBR at the remote endpoint of a softwire is not the BGP next hop for packets that need to be sent on the softwire. The procedures described above require the address of a remote softwire endpoint to be the same as the address of the BGP next hop, so those procedures don't work as specified when the transit core consists of multiple ASes 😭

There are several ways to deal with this:

  1. Don't do it. Require that there be AFBRs at the edge of each AS, so that a transit core doesn't extend beyond one AS 🙅‍♀️
  2. Use multi-hop EBGP to let AFBRs send BGP routes to each other, even if the ABFRs are not in the same or in neighboring ASes 🌐
  3. Make sure that an ASBR that is not an AFBR doesn't change the next hop field of the routes for which encapsulation is needed 🎀

In the latter two cases, BGP recursive next hop resolution needs to be done, and encapsulations may need to be "stacked" (that is, multiple layers of encapsulation may need to be used) 🧁

For instance, consider packet P with destination IP address D. Suppose it arrives at ingress AFBR A1, and the route that's the best match for D has BGP next hop B1. So A1 will encapsulate the packet for delivery to B1. If B1 isn't within A1's AS, A1 will need to look up the route to B1 and then find the BGP next hop, call it B2, of that route. If the interior routers of A1's AS don't have routes to B1, then A1 needs to encapsulate the packet a second time, this time for delivery to B2 💖

13. Security Considerations

13.1. Problem Analysis 🔍

okay so in the Softwire Mesh Framework, the data packets getting encapsulated are E-IP data packets zooming across the Internet 🌐. These inner packets (the softwire "payload") may or may not need authentication, integrity, confidentiality, or replay protection 🔐. BUT here's the tea: their security needs are totally independent of whether they're riding a softwire at all. Being inside a softwire does NOT change what they need 💅.

So the only security stuff we actually need to think about is whatever affects the I-IP encapsulation headers, not the E-IP payload 🎀.

And since those encapsulation headers are what decide how packets get routed through softwires, they must appear "in the clear" 👀.

In the Softwire Mesh Framework, every receiving endpoint of a tunnel has one or more "valid" transmitting endpoints, meaning the ones that are authorized to tunnel packets to it 🫶. If the encapsulation header has no guarantee of authentication or integrity, then spoofing attacks are possible, where unauthorized nodes send encapsulated packets to the receiving endpoint and make it think the packets really traveled through the softwire 😭. Replay attacks are also possible 🙈.

The effect of these attacks is somewhat limited, though 🌸. The receiving endpoint of a softwire decapsulates the payload and then routes based on the IP destination address of the payload. Since payload packets travel through the Internet, they have addresses from the globally unique address space (rather than, e.g., a private address space of some sort) 🧚. So these attacks cannot cause payload packets to be delivered to an address other than the one in the destination IP address field of the payload packet ✨.

HOWEVER, attacks like this can still cause policy violations 🚨. The authorized transmitting endpoint(s) of a softwire may be following a policy where only certain payload packets get sent through the softwire. If unauthorized nodes can encapsulate payload packets so they arrive at the receiving endpoint looking like they came from authorized nodes, then the properly authorized policies have been side-stepped 💀.

Attacks of this sort can also be used in denial-of-service attacks on the receiving tunnel endpoints 😤. Cryptographic authentication/integrity techniques can't prevent this, though, because needing to do cryptography on spoofed packets just makes the denial-of-service problem worse 🥲. (The assumption is that the cryptography mechanisms are likely to be more costly than the decapsulation/forwarding mechanisms. So if you try to stop a flooding attack on the decapsulation/forwarding mechanisms by discarding packets that don't pass a cryptographic integrity test, you just end up trading one kind of attack for another 🙃.)

This section is largely based on the security considerations section of RFC 4023, which also deals with encapsulations and tunnels 🦋.

13.2. Non-Cryptographic Techniques 🧁

If a tunnel lies entirely within a single administrative domain, then, to a certain extent, there are some non-cryptographic techniques you can use to stop spoofed packets from reaching a tunnel's receiving endpoint 🛡️. For example, when the tunnel encapsulation is IP-based:

  • The receiving endpoints of the tunnels can be given a distinct set of addresses, and those addresses can be made known to the border routers. The border routers can then filter out packets, destined to those addresses, that arrive from outside the domain 🚧.
  • The transmitting endpoints of the tunnels can be given a distinct set of addresses, and those addresses can be made known to the border routers and to the receiving endpoints of the tunnels. The border routers can filter out all packets arriving from outside the domain with source addresses in this set, and the receiving endpoints can discard all packets that appear to be part of a softwire but whose source addresses are not in this set 💅.

If an MPLS-based encapsulation is used, the border routers can refuse to accept MPLS packets from outside the domain, or they can refuse to accept such MPLS packets whenever the top label corresponds to the address of a tunnel receiving endpoint 🏰.

These techniques assume that, within a domain, the network is secure enough to prevent spoofed packets from being introduced from inside the domain itself. That may not always be the case 😬. Also, these techniques can be difficult or impossible to use effectively for tunnels that aren't in the same administrative domain 🙅‍♀️.

A different technique is to have the encapsulation header contain a cleartext password 🔑. The 64-bit "cookie" of L2TPv3 [RFC3931] is sometimes used this way. This can be useful within an administrative domain if it's considered infeasible for an attacker to spy on packets that originate in the domain and don't leave it 🕵️‍♀️. That way an attacker wouldn't be able to discover the password. An attacker could, of course, try to guess the password, but if the password is an arbitrary 64-bit binary sequence, brute force attacks that run through all the possible passwords would be infeasible 💪. This technique may be easier to manage than ingress filtering, and may be just as effective if the assumptions hold ✨. Like ingress filtering, though, it may not be applicable for tunnels that cross domain boundaries 🌉.

So it's necessary to also consider cryptographic techniques for setting up the tunnels and for passing data through them 🔒.

13.3. Cryptographic Techniques 🔐

If the path between the two endpoints of a tunnel isn't adequately secure, then:

  • If a control protocol is used to set up the tunnels (e.g., to inform one tunnel endpoint of the IP address of the other), the control protocol MUST have an authentication mechanism, and this MUST be used when the tunnel is set up 🗝️. If the tunnel is set up automatically as the result of, for example, information distributed by BGP, then the use of BGP's MD5-based authentication mechanism [RFC2385] is satisfactory 🎉.
  • Data transmission through the tunnel should be secured with IPsec 💜. In the rest of this section, we specify the way IPsec may be used, and the implementation requirements we mention are meant to apply whenever IPsec is being used 📝.

We're only considering the case where IPsec is used together with an IP-based tunneling mechanism. Use of IPsec with an MPLS-based tunneling mechanism is for further study 🔭.

If it's deemed necessary to use tunnels protected by IPsec, the tunnel type SHOULD be negotiated by the tunnel endpoints using the procedures specified in [RFC5566] 🤝. That document allows IPsec tunnel mode, but it also lets you treat the tunnel head and the tunnel tail as the endpoints of a Security Association, and use IPsec transport mode 🦄.

To use IPsec transport mode, encapsulated packets should be viewed as originating at the tunnel head and as being destined for the tunnel tail 🧭. A single IP address of the tunnel head will be used as the source IP address, and a single IP address of the tunnel tail will be used as the destination IP address 📍. This technique can carry MPLS packets through an IPsec Security Association by first encapsulating the MPLS packets in MPLS-in-IP or MPLS-in-GRE [RFC4023] and then applying IPsec transport mode 🎀.

When IPsec is used to secure softwires, IPsec MUST provide authentication and integrity 🛡️. So the implementation MUST support either ESP (IP Encapsulating Security Payload) with null encryption [RFC4303] or else AH (IP Authentication Header) [RFC4302]. ESP with encryption MAY be supported 🌈. If ESP is used, the tunnel tail MUST check that the source IP address of any packet received on a given SA (IPsec Security Association) is the one expected, as specified in Section 5.2, step 4, of [RFC4301] 👀.

Since softwires are set up dynamically as a byproduct of passing routing information, key distribution MUST be done automatically by means of IKEv2 [RFC4306] 🔑. If a PKI (Public Key Infrastructure) is not available, the IPsec Tunnel Authenticator sub-TLV described in [RFC5566] MUST be used and validated before setting up an SA 🫡.

The selectors associated with the SA are the source and destination addresses of the encapsulation header, along with the IP protocol number representing the encapsulation protocol being used 🧚‍♀️.

14. References 📚

14.1. Normative References

[RFC2003]      Perkins, C., "IP Encapsulation within IP", RFC 2003,
               October 1996.

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2784]      Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
               Traina, "Generic Routing Encapsulation (GRE)", RFC
               2784, March 2000.

[RFC3031]      Rosen, E., Viswanathan, A., and R. Callon,
               "Multiprotocol Label Switching Architecture", RFC
               3031, January 2001.

[RFC3032]      Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
               Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
               Encoding", RFC 3032, January 2001.

[RFC3209]      Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
               V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
               LSP Tunnels", RFC 3209, December 2001.

[RFC3931]      Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
               "Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
               RFC 3931, March 2005.

[RFC4023]      Worster, T., Rekhter, Y., and E. Rosen, Ed.,
               "Encapsulating MPLS in IP or Generic Routing
               Encapsulation (GRE)", RFC 4023, March 2005.

[RFC5512]      Mohapatra, P. and E. Rosen, "The BGP Encapsulation
               Subsequent Address Family Identifier (SAFI) and the
               BGP Tunnel Encapsulation Attribute", RFC 5512, April
               2009.

[RFC5566]      Berger, L., White, R. and E. Rosen, "BGP IPsec Tunnel
               Encapsulation Attribute", RFC 5566, June 2009.

[V4NLRI-V6NH]  Le Faucheur, F. and E. Rosen, "Advertising IPv4
               Network Layer Reachability Information with an IPv6
               Next Hop", RFC 5549, May 2009.

[V6NLRI-V4NH]  De Clercq, J., Ooms, D., Prevost, S., and F. Le
               Faucheur, "Connecting IPv6 Islands over IPv4 MPLS
               Using IPv6 Provider Edge Routers (6PE)", RFC 4798,
               February 2007.

14.2. Informative References ✨

Okay, now the informative references, which are the extra reading that helps you understand the story but isn't strictly required 💅

[BFD]          Katz, D. and D. Ward, "Bidirectional Forwarding
               Detection", Work in Progress, February 2009.

[L3VPN-MCAST]  Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
               MPLS/BGP IP VPNs", Work in Progress, March 2009.

[L3VPN-MCAST-BGP]
               Aggarwal, R., Rosen, E., Morin, T. and Y. Rekhter,
               "BGP Encodings and Procedures for Multicast in
               MPLS/BGP IP VPNs", Work in Progress, April 2009.

[MLDP]         Minei, I., Ed., Kompella, K., Wijnands, IJ., Ed., and
               B. Thomas, "Label Distribution Protocol Extensions for
               Point-to-Multipoint and Multipoint-to-Multipoint Label
               Switched Paths", Work in Progress, April 2009.

[RFC1195]      Callon, R., "Use of OSI IS-IS for routing in TCP/IP
               and dual environments", RFC 1195, December 1990.

[RFC2328]      Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
               1998.

[RFC2385]      Heffernan, A., "Protection of BGP Sessions via the TCP
               MD5 Signature Option", RFC 2385, August 1998.

[RFC4176]      El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan,
               K., and A. Gonguet, "Framework for Layer 3 Virtual
               Private Networks (L3VPN) Operations and Management",
               RFC 4176, October 2005.

[RFC4271]      Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
               Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
               2006.

[RFC4291]      Hinden, R. and S. Deering, "IP Version 6 Addressing
               Architecture", RFC 4291, February 2006.

[RFC4301]      Kent, S. and K. Seo, "Security Architecture for the
               Internet Protocol", RFC 4301, December 2005.

[RFC4302]      Kent, S., "IP Authentication Header", RFC 4302,
               December 2005.

[RFC4303]      Kent, S., "IP Encapsulating Security Payload (ESP)",
               RFC 4303, December 2005.

[RFC4306]      Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
               Protocol", RFC 4306, December 2005.

[RFC4364]      Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
               Networks (VPNs)", RFC 4364, February 2006.

[RFC4378]      Allan, D., Ed., and T. Nadeau, Ed., "A Framework for
               Multi-Protocol Label Switching (MPLS) Operations and
               Management (OAM)", RFC 4378, February 2006.

[RFC4459]      Savola, P., "MTU and Fragmentation Issues with In-
               the-Network Tunneling", RFC 4459, April 2006.

[RFC5036]      Andersson, L., Ed., Minei, I., Ed., and B. Thomas,
               Ed., "LDP Specification", RFC 5036, October 2007.

[RFC5496]      Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse
               Path Forwarding (RPF) Vector TLV", RFC 5496, March
               2009.

[SW-PROB]      Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A.
               Durand, Ed., "Softwire Problem Statement", RFC 4925,
               July 2007.

15. Contributors 🫶

Big shoutout to these people, who really did the work with the whole squad 🌸

Xing Li
Tsinghua University
Department of Electronic Engineering, Tsinghua University
Beijing  100084
P.R.China

Phone: +86-10-6278-5983
EMail: xing@cernet.edu.cn


Simon Barber
Cisco Systems, Inc.
250 Longwater Avenue
Reading, ENGLAND, RG2 6GB
United Kingdom

EMail: sbarber@cisco.com


Pradosh Mohapatra
Cisco Systems, Inc.
3700 Cisco Way
San Jose, CA  95134
USA

EMail: pmohapat@cisco.com


John Scudder
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA  94089
USA

EMail: jgs@juniper.net

16. Acknowledgments 💖

Hugs to David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta, Mingwei Xu, and Ke Xu, who gave really useful input into this document 🧚

Authors' Addresses 🎀

Here are the authors, the ones who started this whole thing ✨

Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing  100084
P.R.China

Phone: +86-10-6278-5983
EMail: jianping@cernet.edu.cn


Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing  100084
P.R.China

Phone: +86-10-6278-5822
EMail: yong@csnet1.cs.tsinghua.edu.cn


Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, CA  95134
USA

EMail: chmetz@cisco.com


Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA  01719
USA

EMail: erosen@cisco.com
📦 where this page comes from