Network Working Group                                              J. Wu
Internet Draft                                                    Y. Cui
Intended Status: Standards Track                                   X. Li
Expires: September 31, 2008 March 18, 2009                              Tsinghua University

                                                                 C. Metz
                                                       E. Rosen (Editor)
                                                               S. Barber
                                                            P. Mohapatra
                                                     Cisco Systems, Inc.

                                                              J. Scudder
                                                  Juniper Networks, Inc.

                                                          March 31,

                                                      September 18, 2008

                        Softwire Mesh Framework



Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   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

Table of Contents

 1          Specification of requirements  .........................   4
 2          Introduction  ..........................................   4
 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  ....................  11
 4.1        'E-IP' and 'I-IP'  .....................................  11
 4.2        Routing  ...............................................  11
 4.3        Tunneled Forwarding  ...................................  12
 5          Distribution of Inter-AFBR Routing Information  ........  12
 6          Softwire Signaling  ....................................  14
 7          Choosing to Forward Through a Softwire  ................  16
 8          Selecting a Tunneling Technology  ......................  16
 9          Selecting the Softwire for a Given Packet  .............  17
10          Softwire OAM and MIBs  .................................  18
10.1        Operations and Maintenance (OAM)  ......................  18
10.2        MIBs  ..................................................  19
11          Softwire Multicast  ....................................  19
11.1        One-to-One Mappings  ...................................  20
11.1.1      Using PIM in the Core  .................................  20
11.1.2      Using mLDP and Multicast MPLS in the Core  .............  21
11.2        MVPN-like Schemes  .....................................  22
12          Inter-AS Considerations  ...............................  23
13          IANA Considerations  ...................................  24
14          Security Considerations  ...............................  24
14.1        Problem Analysis  ......................................  24
14.2        Non-cryptographic techniques  ..........................  26
14.3        Cryptographic techniques  ..............................  27
15          Acknowledgments  .......................................  28
16          Normative References  ..................................  28
17          Informative References  ................................  29
18          Full Copyright Statement  ..............................  32
19          Intellectual Property  .................................  33

1. Specification of requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2. Introduction

   The routing information in any IP backbone network can be thought of
   as being in one of two categories: "internal routing information" or
   "external routing information".  The internal routing information
   consists of routes to the nodes that belong to the backbone, and to
   the interfaces of those nodes.  External routing information consists
   of routes to destinations beyond the backbone, especially
   destinations to which the backbone is not directly attached.  In
   general, BGP [RFC4271] is used to distribute external routing
   information, and an "Interior Gateway Protocol" (IGP) such as OSPF
   [RFC2328] or IS-IS [RFC1195] is used to distribute internal routing

   Often an IP backbone will provide transit routing services for
   packets that originate outside the backbone, and whose destinations
   are outside the backbone.  These packets enter the backbone at one of
   its "edge routers".  They are routed through the backbone to another
   edge router, after which they leave the backbone and continue on
   their way. The edge nodes of the backbone are often known as
   "Provider Edge" (PE) routers.  The term "ingress" (or "ingress PE")
   refers to the router at which a packet enters the backbone, and the
   term "egress" (or "egress PE") refers to the router at which it
   leaves the backbone.  Interior nodes are often known as "P routers".
   Routers which are outside the backbone but directly attached to it
   are known as "Customer Edge" (CE) routers.  (This terminology is
   taken from [RFC4364].)

   When a packet's destination is outside the backbone, the routing
   information which is needed within the backbone in order to route the
   packet to the proper egress is, by definition, external routing

   Traditionally, the external routing information has been distributed
   by BGP to all the routers in the backbone, not just to the edge
   routers (i.e., not just to the ingress and egress points).  Each of
   the interior nodes has been expected to look up the packet's
   destination address and route it towards the egress point.  This is
   known as "native forwarding":  the interior nodes look into each
   packet's header in order to match the information in the header with
   the external routing information.

   It is, however, possible to provide transit services without
   requiring that all the backbone routers have the external routing
   information.  The routing information which BGP distributes to each
   ingress router specifies the egress router for each route.  The
   ingress router can therefore "tunnel" the packet directly to the
   egress router.  "Tunneling the packet" means putting on some sort of
   encapsulation header which will force the interior routers to forward
   the packet to the egress router.  The original packet is known as the
   "encapsulation payload".  The P routers do not look at the packet
   header of the payload, but only at the encapsulation header.  Since
   the path to the egress router is part of the internal routing
   information of the backbone, the interior routers then do not need to
   know the external routing information.  This is known as "tunneled
   forwarding".  Of course, before the packet can leave the egress, it
   has to be decapsulated.

   The scenario where the P routers do not have external routes is
   sometimes known as a "BGP-free core".  That is something of a
   misnomer, though, since the crucial aspect of this scenario is not
   that the interior nodes don't run BGP, but that they don't maintain
   the external routing information.

   In recent years, we have seen this scenario deployed to support VPN
   services, as specified in [RFC4364].  An edge router maintains
   multiple independent routing/addressing spaces, one for each VPN to
   which it interfaces.  However, the routing information for the VPNs
   is not maintained by the interior routers.  In most of these
   scenarios, MPLS is used as the encapsulation mechanism for getting
   the packets from ingress to egress.  There are some deployments in
   which an IP-based encapsulation, such as L2TPv3 (Layer 2 Transport
   Protocol) [RFC3931] or GRE (Generic Routing Encapsulation) [RFC2784]
   is used.

   This same technique can also be useful when the external routing
   information consists not of VPN routes, but of "ordinary" Internet
   routes.  It can be used any time it is desired to keep external
   routing information out of a backbone's interior nodes, or in fact
   any time it is desired for any reason to avoid the native forwarding
   of certain kinds of packets.

   This framework focuses on two such scenarios.

      1. In this scenario, the backbone's interior nodes support only
         IPv6.  They do not maintain IPv4 routes at all, and are not
         expected to parse IPv4 packet headers.  Yet it is desired to
         use such a backbone to provide transit services for IPv4
         packets.  Therefore tunneled forwarding of IPv4 packets is
         required.  Of course, the edge nodes must have the IPv4 routes,
         but the ingress must perform an encapsulation in order 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 is 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 use the term "Address Family Border
   Router" (AFBR) to refer to these PE routers.  The tunnels that are
   used for forwarding are referred to as "softwires".

   These two scenarios are known as the "Softwire Mesh Problem" [SW-
   PROB], and the framework specified in this draft 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
   address family.

   It is possible to address these scenarios via a large variety of
   tunneling technologies.  This framework does not mandate the use of
   any particular tunneling technology.  In any given deployment, the
   choice of tunneling technology is a matter of policy.  The framework
   accommodates at least the use of MPLS ([RFC3031], [RFC3032]), both
   LDP-based (Label Distribution Protocol, [RFC5036]) and RSVP-TE-based
   ([RFC3209]), L2TPv3 [RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003].
   The framework will also accommodate the use of IPsec tunneling, when
   that is necessary in order to meet security requirements.

   It is expected that in many deployments, the choice of tunneling
   technology will be made by a simple expression of policy, such as
   "always use IP-IP tunnels", or "always use LDP-based MPLS", or
   "always use L2TPv3".

   However, other deployments may have a mixture of routers, some of
   which support, say, both GRE and L2TPv3, but others of which support
   only one of those techniques.  It is desirable therefore to allow the
   network administration to create a small set of classes, and to
   configure each AFBR to be a member of one or more of these classes.
   Then the routers can advertise their class memberships to each other,
   and the encapsulation policies can be expressed as, e.g., "use L2TPv3
   to tunnel to routers in class X, use GRE to tunnel to routers in
   class Y".  To support such policies, it is necessary for the AFBRs to
   be able to advertise their class memberships; a standard way of doing
   this must be developed.

   Policy may also require a certain class of traffic to receive a
   certain quality of service, and this may impact the choice of tunnel
   and/or tunneling technology used for packets in that class.  This
   needs to be accommodated by the softwires framework.

   The use of tunneled forwarding often requires that some sort of
   signaling protocol be used to set up and/or maintain the tunnels.
   Many of the tunneling technologies accommodated by this framework
   already have their own signaling protocols.  However, some do not,
   and in some cases the standard signaling protocol for a particular
   tunneling technology may not be appropriate, for one or another
   reason, in the scenarios of interest.  In such cases (and in such
   cases only), new signaling methodologies need to be defined and

   In this framework, the softwires do not form an overlay topology
   which is visible to routing; routing adjacencies are not maintained
   over the softwires, and routing control packets are not sent through
   the softwires.  Routing adjacencies among backbone nodes (including
   the edge nodes) are maintained via the native technology of the

   There is already a standard routing method for distributing external
   routing information among AFBRs, namely BGP.  However, in the
   scenarios of interest, we may be using IPv6-based BGP sessions to
   pass IPv4 routing information, and we may be using IPv4-based BGP
   sessions to pass IPv6 routing information.  Furthermore, when IPv4
   traffic is to be tunneled over an IPv6 backbone, it is necessary to
   encode the "BGP next hop" for an IPv4 route 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]; the method for
   encoding an IPv6 address as the next hop for an IPv4 route is
   specified in [V4NLRI-V6NH].

3. Scenarios of Interest

3.1. IPv6-over-IPv4 Scenario

   In this scenario, the client networks run IPv6 but the backbone
   network runs IPv4.  This is illustrated in Figure 1.

                       +--------+ +--------+
                       | 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 does not show any "backdoor" connections among the client
networks, this framework assumes that there will be such connections.

That is, there is no assumption that the only path between two client
networks is via the pictured transit core network.  Hence the routing
solution must be robust in any kind of topology.

Many mechanisms for providing IPv6 connectivity across IPv4 networks
have been devised over the past ten years.  A number of different
tunneling mechanisms have been used, some provisioned manually, others
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 described 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 is no manual provisioning of tunnels, and no
special addressing is required.

3.2. IPv4-over-IPv6 Scenario

   In this scenario, the client networks run IPv4 but the backbone
   network runs IPv6.  This is illustrated in Figure 2.

                       +--------+ +--------+
                       | 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 does not show any "backdoor" connections among the client
networks, this framework assumes that there will be such connections.

That is, there is no assumption the only path between two client
networks is via the pictured transit core network.  Hence the routing
solution must be robust in any kind of topology.

While the issue of IPv6-over-IPv4 has received considerable attention in
the past, the scenario of IPv4-over-IPv6 has not.  Yet it is a
significant emerging requirement, as a number of service providers are
building IPv6 backbone networks and do not wish to provide native IPv4
support in their core routers.  These service providers have a large
legacy of IPv4 networks and applications that need to operate across
their IPv6 backbone.  Solutions for this do not 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 provide more detail.

4.1. 'E-IP' and 'I-IP'

   In the following we use the term "I-IP" ("Internal IP") to refer to
   the form of IP (i.e., either IPv4 or IPv6) that is supported by the
   transit network.  We use the term "E-IP" ("External IP") to refer to
   the form of IP that is 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 that the P routers support only I-IP.  That is, they are
   expected to have only I-IP routing information, and they are not
   expected to be able to parse E-IP headers.  We similarly assume that
   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 participate in an
   IGP, for the purposes of distributing I-IP routing information.

   The AFBRs use IBGP to exchange E-IP routing information with each
   other.  Either there is a full mesh of IBGP connections among the
   AFBRs, or else 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 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 which the P
   routers can process, and which 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, others do not.

5. Distribution of Inter-AFBR Routing Information

   AFBRs peer with routers in the client networks to exchange routing
   information for the E-IP family.

   AFBRs use BGP to distribute the E-IP routing information to each
   other.  This can be done by an AFBR-AFBR mesh of IBGP sessions, but
   more likely is done through a BGP Route Reflector, i.e., where each
   AFBR has an IBGP session to one or two Route Reflectors, rather than
   to other AFBRs.

   The BGP sessions between the AFBRs, or between the AFBRs and the
   Route Reflector, will run on top of the I-IP address family.  That
   is, if the transit core supports only IPv6, the IBGP sessions used to
   distribute IPv4 routing information from the client networks will run
   over IPv6; if the transit core supports only IPv4, the IBGP sessions
   used to distribute IPv6 routing information from the client networks
   will run over IPv4.  The BGP sessions thus use the native networking
   layer of the core; BGP messages are NOT tunneled through softwires or
   through any other mechanism.

   In BGP, a routing update associates an address prefix (or more
   generally, "Network Layer Reachability Information", or NLRI) with
   the address of a "BGP Next Hop" (NH). The NLRI is associated with a
   particular address family.  The NH address is also associated with a
   particular address family, which may be the same as or different than
   the address family associated with the NLRI.  Generally the NH
   address belongs to the address family that is used to communicate
   with the BGP speaker to whom the NH address belongs.

   Since routing updates which contain information about E-IP address
   prefixes are carried over BGP sessions that use I-IP transport, and
   since the BGP messages are not tunneled, a BGP update providing
   information about an E-IP address prefix will need to specify a next
   hop address in the I-IP family.

   Due to a variety of historical circumstances, when the NLRI and the
   NH in a given BGP update are of different address families, it is not
   always obvious how the NH should be encoded.  There is a different
   encoding procedure for each pair of address families.

   In the case where the NLRI is in the IPv6 address family, and the NH
   is in the IPv4 address family, [V6NLRI-V4NH] explains how to encode
   the NH.

   In the case where the NLRI is in the IPv4 address family, and the NH
   is in the IPv6 address family, [V4NLRI-V6NH] explains how to encode
   the NH.

   If a BGP speaker sends an update for an NLRI in the E-IP family, and
   the update is being sent over a BGP session that is 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.

   In some cases (e.g., when [V4NLRI-V6NH] is used), one cannot follow
   this rule unless one's BGP peers have advertised a particular BGP
   capability.  This leads to the following softwires deployment
   restriction: if a BGP Capability is defined for the case in which an
   E-IP NLRI has an I-IP NH, all the AFBRs in a given transit core MUST
   advertise that capability.

   If an AFBR has multiple IP addresses, the network administrators
   usually have considerable flexibility in choosing which one the AFBR
   uses to identify itself as the next hop in a BGP update.  However, if
   the AFBR expects to receive packets through a softwire of a
   particular tunneling technology, and if the AFBR is known to that
   tunneling technology via 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, then the
   IP address which the AFBR uses when engaging in L2TPv3 signaling must
   be the same as the IP address it uses to identify itself in the next
   hop field of a BGP update.

   In [V6NLRI-V4NH], IPv6 routing information is distributed using the
   labeled IPv6 address family.  This allows the egress AFBR to
   associate an MPLS label with each IPv6 address prefix.  If an ingress
   AFBR forwards packets through a softwire than can carry MPLS packets,
   each data packet can carry the MPLS label corresponding to the IPv6
   route that it matched.  This may be useful at the egress AFBR, for
   demultiplexing and/or enhanced performance.  It is also 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.  The use of the
   labeled IP address families in this manner is OPTIONAL.

6. Softwire Signaling

   A mesh of inter-AFBR softwires spanning the transit core must be in
   place before packets can flow between client networks.  Given N dual-
   stack AFBRs, this requires N^2 "point-to-point IP" or "label switched
   path" (LSP) tunnels.  While in theory these could be configured
   manually, that would result in a very undesirable O(N^2) provisioning
   problem.  Therefore manual configuration of point-to-point tunnels is
   not considered part of this framework.

   Because the transit core is providing layer 3 transit services,
   point-to-point tunnels are not required by this framework;
   multipoint-to-point tunnels are all that is needed.  In a multipoint-
   to-point tunnel, when a packet emerges from the tunnel there is no
   way to tell which router put the packet into the tunnel.  This models
   the native IP forwarding paradigm, wherein the egress router cannot
   determine a given packet's ingress router.  Of course, point-to-point
   tunnels might be required for some reason which goes beyond the basic
   requirements described in this document.  E.g., QoS or security
   considerations might require the use of point-to-point tunnels.  So
   point-to-point tunnels are allowed, but not required, by this

   If it is desired to use a particular tunneling technology for the
   softwires, and if that technology has its own "native" signaling
   methodology, the presumption is that the native signaling will be
   used.  This would certainly apply to MPLS-based softwires, where LDP
   or RSVP-TE would be used.  A softwire based on IPsec would use
   standard IKE IKEv2 (Internet Key Exchange) [RFC4306] and IPsec [RFC4301]
   signaling, as that is necessary in order to guarantee the softwire's
   security properties.

   A Softwire based on GRE might or might not require signaling,
   depending on whether various optional GRE header fields are to be
   used.  GRE does not have any "native" signaling, so for those cases,
   a signaling procedure needs to be developed to support Softwires.

   Another possible softwire technology is L2TPv3.  While L2TPv3 does
   have its own native signaling, that signaling sets up point-to-point
   tunnels.  For the purpose of softwires, it is better to use L2TPv3 in
   a multipoint-to-point mode, and this requires a different kind of

   The signaling to be used for GRE and L2TPv3 to cover these scenarios
   is BGP-based, and is described in [ENCAPS-SAFI].

   If IP-IP tunneling is used, or if GRE tunneling is used without
   options, no signaling is required, as the only information needed by
   the ingress AFBR to create the encapsulation header is the IP address
   of the egress AFBR, and that is distributed by BGP.

   When the encapsulation IP header is constructed, there may be fields
   in the IP whose value is determined neither by whatever signaling has
   been done nor by the distributed routing information.  The values of
   these fields are determined by policy in the ingress AFBR.  Examples
   of such fields may be the TTL (Time to Live) field, the DSCP
   (DiffServ Service Classes) bits, etc.

   It is desirable for all necessary softwires to be fully set up before
   the arrival of any packets which need to go through the softwires.
   That is, the softwires should be "always on".  From the perspective
   of any particular AFBR, the softwire endpoints are always BGP next
   hops of routes which the AFBR has installed.  This suggests that any
   necessary softwire signaling should be either be done as part of
   normal system startup (as would happen, e.g., with LDP-based MPLS),
   or else should be triggered by the reception of BGP routing
   information (such as is described in [ENCAPS-SAFI]); it is also
   helpful if distribution of the routing information that serves as the
   trigger is prioritized.

7. Choosing to Forward Through a Softwire

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

   In many cases, the policy will be very simple.  Some useful policies

     - if routing says that an E-IP packet has to be sent out a "core-
       facing interface" to an I-IP core, send the packet through a

     - 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
       packets 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 packets through a softwire

     - if the route which 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 a consideration of
   those policies is outside the scope of this document.

8. Selecting a Tunneling Technology

   The choice of tunneling technology is a matter of policy configured
   at the ingress AFBR.

   It is envisioned that in most cases, the policy will be a very simple
   one, and will be the same at all the AFBRs of a given transit core.
   E.g., "always use LDP-based MPLS", or "always use L2TPv3".

   However, other deployments may have a mixture of routers, some of
   which support, say, both GRE and L2TPv3, but others of which support
   only one of those techniques.  It is desirable therefore to allow the
   network administration to create a small set of classes, and to
   configure each AFBR to be a member of one or more of these classes.
   Then the routers can advertise their class memberships to each other,
   and the encapsulation policies can be expressed as, e.g., "use L2TPv3
   to talk to routers in class X, use GRE to talk to routers in class
   Y".  To support such policies, it is necessary for the AFBRs to be
   able to advertise their class memberships.  [ENCAPS-SAFI] specifies a
   way in which an AFBR may advertise, to other AFBRS, various
   characteristics which may be relevant to the polcy policy (e.g., "I belong
   to class Y").  In many cases, these characteristics can be
   represented by arbitrarily selected communities or extended
   communities, and the policies at the ingress can be expressed in
   terms of these classes (i.e., communities).

   Policy may also require a certain class of traffic to receive a
   certain quality of service, and this may impact the choice of tunnel
   and/or tunneling technology used for packets in that class.  This
   framework allows a variety of tunneling technologies to be used for
   instantiating softwires.  The choice of tunneling technology is a
   matter of policy, as discussed in section 2.

   While in many cases the policy will be unconditional, e.g., "always
   use L2TPv3 for softwires", in other cases the policy may specify that
   the choice is conditional upon information about the softwire remote
   endpoint, e.g., "use L2TPv3 to talk to routers in class X, use GRE to
   talk to routers in class Y".  It is desirable therefore to allow the
   network administration to create a small set of classes, and to
   configure each AFBR to be a member of one or more of these classes.
   If each such class is represented as a community or extended
   community, then [ENCAPS-SAFI] specifies a method that AFBRs can use
   to advertise their class memberships to each other.

   This framework also allows for policies of arbitrary complexity,
   which may depend on characteristics or attributes of individual
   address prefixes, as well as on QoS or security considerations.
   However, the specification of such policies is not within the scope
   of this document.

9. Selecting the Softwire for a Given Packet

   Suppose it has been decided to send a given packet through a
   softwire.  Routing provides the address, in the address family of the
   transport network, of the BGP next hop.  The packet MUST be sent
   through a softwire whose remote endpoint address is the same as the
   BGP next hop address.

   Sending a packet through a softwire is a matter of encapsulating the
   packet with an encapsulation header that can be processed by the
   transit network, and then transmitting towards the softwire's remote
   endpoint address.

   In many cases, once one knows the remote endpoint address, one has
   all the information one needs in order to form the encapsulation
   header.  This will be the case if the tunnel technology instantiating
   the softwire is, e.g., LDP-based MPLS, IP-in-IP, or GRE without
   optional header fields.

   If the tunnel technology being used is L2TPv3 or GRE with optional
   header fields, additional information from the remote endpoint is
   needed in order to form the encapsulation header.  The procedures for
   sending and receiving this information are described in [ENCAPS-

   If the tunnel technology being used is RSVP-TE-based MPLS or IPsec,
   the native signaling procedures of those technologies will need to be

   IPsec procedures will be discussed further in a subsequent revision
   of this document.

   RSVP-TE procedures will be discussed in companion documents.

   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.
   Note that most of the tunneling technologies mentioned in this
   document are capable of carrying MPLS packets, so this does not
   presuppose support for MPLS in the core routers.

10. Softwire OAM and MIBs

10.1. Operations and Maintenance (OAM)

   Softwires are essentially tunnels connecting routers.  If they
   disappear or degrade in performance then connectivity through those
   tunnels will be impacted.  There are several techniques available to
   monitor the status of the tunnel end-points (AFBRs) as well as the
   tunnels themselves.  These techniques allow operations such as
   softwires path tracing, remote softwire end-point pinging and remote
   softwire end-point liveness failure detection.

   Examples of techniques applicable to softwire OAM include:

     o BGP/TCP timeouts between AFBRs

     o ICMP or LSP echo request and reply addressed to a particular AFBR

     o BFD (Bidirectional Forwarding Detection) [BFD] packet exchange
       between AFBR routers

   Another possibility for softwire OAM is to build something similar to
   the [RFC4378] or in other words creating and generating softwire echo
   request/reply packets.  The echo request sent to a well-known UDP
   port would contain the egress AFBR IP address and the softwire
   identifier as the payload (similar to the MPLS forwarding equivalence
   class contained in the LSP echo request).  The softwire echo packet
   would be encapsulated with the encapsulation header and forwarded
   across the same path (inband) as that of the softwire itself.

   This mechanism can also be automated to periodically verify remote
   softwires end-point reachability, with the loss of reachability being
   signaled to the softwires application on the local AFBR thus enabling
   suitable actions to be taken.  Consideration must be given to the
   trade offs between scalability of such mechanisms verses time to
   detection of loss of endpoint reachability for such automated

   In general a framework for softwire OAM can for a large part be based
   on the [RFC4176] framework.

10.2. MIBs

   Specific MIBs do exist to manage elements of the softwire mesh
   framework.  However there will be a need to either extend these MIBs
   or create new ones that reflect the functional elements that can be
   SNMP-managed within the softwire network.

11. Softwire Multicast

   A set of client networks, running E-IP, that are connected to a
   provider's I-IP transit core, may wish to run IP multicast
   applications.  Extending IP multicast connectivity across the transit
   core can be done in a number of ways, each with a different set of
   characteristics.  Most (though not all) of the possibilities are
   either slight variations of the procedures defined for L3VPNs in

   We will focus on supporting those multicast features and protocols
   which are typically used across inter-provider boundaries.  Support
   is provided for PIM-SM (PIM Sparse Mode) and PIM-SSM (PIM Single
   Source Mode).  Support for BIDIR-PIM (Bidirectional PIM), BSR
   (Bootstrap Router Mechanism for PIM), AutoRP (Automatic Rendezvous
   Point Determination) is not provided as these features are not
   typically used across inter-provider boundaries.

11.1. One-to-One Mappings

   In the "one-to-one mapping" scheme, each client multicast tree is
   extended through the transit core, so that for each client tree there
   is exactly one tree through the core.

   The one-to-one scheme is not used in [L3VPN-MCAST], because it
   requires an amount of state in the core routers which is proportional
   to the number of client multicast trees passing through the core.  In
   the VPN context, this is considered undesirable, because the amount
   of state is unbounded and out of the control of the service provider.
   However, the one-to-one scheme models the typical "Internet
   multicast" scenario where the client network and the transit core are
   both IPv4 or are both IPv6.  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

   When an AFBR receives an E-IP PIM control message from one of its
   CEs, it would translate it from E-IP to I-IP, and forward it towards
   the source of the tree.  Since the routers in the transit core will
   not generally have a route to the source of the tree, the AFBR must
   create include an "RPF (Reverse Path Forwarding) Vector" [RPF-VECTOR]
   in the PIM message.

   Suppose an AFBR A receives an E-IP PIM Join/Prune message from a CE,
   for either an (S,G) tree or a (*,G) tree.  The AFBR would have to
   "translate" the PIM message into an I-IP PIM message.  It would then
   send it to the neighbor which is the next hop along the route to the
   root of the (S,G) or (*,G) tree.  In the case of an (S,G) tree the
   root of the tree is S; in the case of a (*,G) tree the root of the
   tree is the Rendezvous Point (RP) for the group G.

   Note that the address of the root of the tree will be an E-IP
   address.  Since the routers within the transit core (other than the
   AFBRs) do not have routes to E-IP addresses, A must put an "RPF
   Vector" [RPF-VECTOR] in the PIM Join/Prune message that it sends to
   its upstream neighbor.  The RPF Vector will identify, as an I-IP
   address, the AFBR B that is the egress point in the transit network
   along the route to the root of the multicast tree.  AFBR B is AFBR
   A's "BGP next hop" for the route to the root of the tree.  The RPF
   Vector allows the core routers to forward PIM Join/Prune messages
   upstream towards the root of the tree, even though they do not
   maintain E-IP routes.

   In order to "translate" the an E-IP PIM message into an I-IP PIM
   message, the AFBR A must translate the address of S (in the case of
   an (S,G) group) or the address of G's RP from the E-IP address family
   to the I-IP address family, and the AFBR B must translate them back.

   In the case where E-IP is IPv4 and I-IP is IPv6, it is possible to do
   this translation algorithmically.  A can translate the IPv4 S and G
   into the corresponding IPv4-mapped IPv6 addresses [RFC4291], and then
   B can translate them back.  The precise circumstances under which
   these translations are done would be a matter of policy.

   Obviously, this translation procedure does not generalize to the case
   where the client multicast is IPv6 but the core is IPv4.  To handle
   that case, one needs additional signaling between the two AFBRs.
   Each downstream AFBR need to signal the upstream AFBR that it needs a
   multicast tunnel for (S,G).  The upstream AFBR must then assign a
   multicast address G' to the tunnel, and inform the downstream of the
   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.

   This procedure can be used to support client multicasts of either
   IPv4 or IPv6 over a transit core of the opposite protocol.  However,
   it only works when the client multicasts are SSM, since it provides
   no method for mapping a client "prune a source off the (*,G) tree"
   operation into an operation on the (S',G') tree.  This method also
   requires additional signaling.  The BGP-based signaling of [L3VPN-
   MCAST-BGP] is one signaling method that could be used.  Other
   signaling methods could be defined as well.

11.1.2. Using mLDP and Multicast MPLS in the Core

   If the transit core implements mLDP (LDP Extensions for Point-to-
   Multipoint and Multipoint-to-Multipoint LSPs, [mLDP]) and supports
   multicast MPLS, then client Single-Source Multicast (SSM) trees can
   be mapped one-to-one onto P2MP (Point-to-Multipoint) LSPs.

   When an AFBR A receives a E-IP PIM Join/Prune message for (S,G) from
   one of its CEs, where G is an SSM group it would use mLDP to join a
   P2MP LSP.  The root of the P2MP LSP would be the AFBR B that is A's
   BGP next hop on the route to S. In mLDP, a P2MP LSP is uniquely
   identified by a combination of its root and a "FEC (Forwarding
   Equivalence Class) identifier".  The original (S,G) can be
   algorithmically encoded into the FEC identifier, so that all AFBRs
   that need to join the P2MP LSP for (S,G) will 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 which is its next hop on the route to S.

   The method of encoding the (S,G) into the FEC identifier needs to be
   standardized.  The encoding must be self-identifying, so that a node
   which is the root of a P2MP LSP can determine whether a FEC
   identifier is the result of having encoded a PIM (S,G).

   The appropriate state machinery must be standardized so that PIM
   events at the AFBRs result in the proper mLDP events.  For example,
   if at some point 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

   Note that this method cannot be used when the G is a Sparse Mode
   group.  The reason this method cannot be used is that mLDP does not
   have any 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 (i.e., traffic from S might travel down both the shared tree and
   S's source tree).  Alternatively, one 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 those discussed below.

   Client-side bidirectional multicast groups set up by PIM-bidir could
   be mapped using the above technique to MP2MP (Multipoint-to-
   Multipoint) LSPs set up by mLDP [MLDP].  We do not consider this
   further as inter-provider bidirectional groups are not in use

11.2. MVPN-like Schemes

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

   The MVPN-like schemes do not require a one-to-one mapping between
   client multicast trees and transit core multicast trees.  In the MVPN
   environment, it is a requirement that the number of trees in the core
   scales less than linearly with the number of client trees.  This
   requirement may not hold in the softwires scenarios.

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

     - 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 consists of 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 admit of many variations; a comprehensive
   discussion is in [L3VPN-MCAST].

   For the data plane, there are also a number of options:

     - All multicast data sent over the emulated LAN.  This particular
       option is not very attractive though for the softwires scenarios,
       as every AFBR would have to receive every client multicast

     - Every multicast group mapped to a tree which is considered
       appropriate for that group, in the sense of causing the traffic
       of that group to go to "too many" AFBRs that don't need to
       receive it.

   Again, a comprehensive discussion of the issues can be found in

12. Inter-AS Considerations

   We have so far only considered the case where a "transit core"
   consists of a single Autonomous System (AS).  If the transit core
   consists of multiple ASes, then it may be necessary to use softwires
   whose endpoints are AFBRs attached to different Autonomous Systems.
   In this 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.
   Since the procedures described above require the address of remote
   softwire endpoint to be the same as the address of the BGP next hop,
   those procedures do not work as specified when the transit core
   consists of multiple ASes.

   There are several ways to deal with this situation.

      1. Don't do it; require that there be AFBRs at the edge of each
         AS, so that a transit core does not extend more than one AS.

      2. Use multi-hop EBGP to allow AFBRs to send BGP routes to each
         other, even if the ABFRs are not in the same or in neighboring

      3. Ensure that an ASBR which is not an AFBR does not 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.

   For instance, consider packet P with destination IP address D.
   Suppose it arrives at ingress AFBR A1, and that the route that is the
   best match for D has BGP next hop B1.  So A1 will encapsulate the
   packet for delivery to B1.  If B1 is not 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 do not have
   routes to B1, then A1 needs to encapsulate the packet a second time,
   this time for delivery to B2.

13. IANA Considerations

   This document has no actions for IANA.

14. Security Considerations

14.1. Problem Analysis

   In the Softwires mesh framework, the data packets that are
   encapsulated are E-IP data packets that are traveling through the
   Internet.  These data packets (the Softwires "payload") may or may
   not need such security features as authentication, integrity,
   confidentiality, or playback protection.  However, the security needs
   of the payload packets are independent of whether or not those
   packets are traversing softwires.  The fact that a particular payload
   packet is traveling through a softwire does not in any way affect its
   security needs.

   Thus the only security issues we need to consider are those which
   affect the I-IP encapsulation headers, rather than those which affect
   the E-IP payload.

   Since the encapsulation headers determine the routing of packets
   traveling through softwires, they must appear "in the clear", i.e.,
   they do not have any confidentiality requirement.

   In the Softwires mesh framework, for each tunnel receiving endpoint,
   there are one or more "valid" transmitting endpoints, where the valid
   transmitting endpoints are those which are authorized to tunnel
   packets to the receiving endpoint.  If the encapsulation header has
   no guarantee of authentication or integrity, then it is possible to
   have spoofing attacks, in which unauthorized nodes send encapsulated
   packets to the receiving endpoint, giving the receiving endpoint the
   invalid impression the encapsulated packets have really traveled
   through the softwire.  Replay attacks are also possible.

   The effect of such attacks is somewhat limited though.  The receiving
   endpoint of a softwire decapsulates the payload and does further
   routing based on the IP destination address of the payload.  Since
   the payload packets are traveling through the Internet, they have
   addresses from the globally unique address space (rather than, e.g.,
   from a private address space of some sort).  Therefore these attacks
   cannot cause payload packets to be delivered to an address other than
   the one intended.

   However, attacks of this sort can result in policy violations.  The
   authorized transmitting endpoint(s) of a softwire may be following a
   policy according to which only certain payload packets get sent
   through the softwire.  If unauthorized nodes are able to encapsulate
   the payload packets so that they arrive at the receiving endpoint
   looking as if they arrived from authorized nodes, then the properly
   authorized policies have been side-stepped.

   Attacks of the sort we are considering can also be used in Denial of
   Service attacks on the receiving tunnel endpoints.  However, such
   attacks cannot be prevented by use of cryptographic
   authentication/integrity techniques, as the need to do cryptography
   on spoofed packets only makes the Denial of Service problem worse.

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

14.2. Non-cryptographic techniques

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

     - The tunnel receiving endpoints 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, which arrive from outside the

     - The tunnel transmitting endpoints can be given a distinct set of
       addresses, and those addresses can be made known to the border
       routers and to the tunnel receiving endpoints. The border routers
       can filter out all packets arriving from outside the domain with
       source addresses that are in this set, and the receiving
       endpoints can discard all packets which 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 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 the introduction of spoofed packets from within the
   domain itself.  That may not always be the case.  Also, these
   techniques however can be difficult or impossible to use effectively
   for tunnels that are not 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 in this way.  This can be useful within an
   administrative domain if it is regarded as infeasible for an attacker
   to spy on packets that originate in the domain and that do not leave
   the domain.  An attacker would then not 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 which run through all the possible passwords would be
   infeasible.  This technique may be easier to manage than ingress
   filtering is, 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.

   Therefore it is necessary to also consider the use of cryptographic
   techniques for setting up the tunnels and for passing data through

14.3. Cryptographic techniques

   If the path between the two endpoints of a tunnel is not 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 remainder of this section, we specify the way
       IPsec may be used, and the implementation requirements we mention
       are meant to be applicable whenever IPsec is being used.

   We consider only 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 is deemed necessary to use tunnels that are protected by IPsec,
   the tunnel type SHOULD be negotiated by the tunnel endpoints using
   the procedures specified in [ENCAPS-IPSEC].  That document allows the
   use of IPsec tunnel mode, but also allows one to treat the tunnel
   head and the tunnel tail as the endpoints of a Security Association,
   and to use IPsec transport mode.

   In order 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 be
   used to to carry MPLS packets through an IPsec Security Association,
   but 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.  Thus, 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. expected, as specified in
   [RFC4301] section 5.2 step 4.

   Since the softwires are set up dynamically as a byproduct of passing
   routing information, key distribution MUST be done automatically by
   means of IKE IKEv2 [RFC4306], operating in main mode with preshared keys.
   If a PKI (Public Key Infrastructure) is not available, the IPsec
   Tunnel Authenticator sub-TLV described in [ENCAPS-IPSEC] 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.

15. Acknowledgments

   David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta,
   Mingwei Xu and Ke Xu provided useful input into this document.

16. Normative References

   [ENCAPS-IPSEC] "BGP IPSec Tunnel Encapsulation Attribute", L. Berger,
   R. White, E. Rosen, draft-ietf-softwire-encaps-ipsec-00.txt, March draft-ietf-softwire-encaps-ipsec-01.txt, April

   [ENCAPS-SAFI] "BGP Information SAFI and BGP Tunnel Encapsulation
   Attribute", P. Mohapatra and E. Rosen, draft-ietf-softwire-encaps-
   safi-00.txt, January
   safi-03.txt, June 2008.

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

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

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

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

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

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

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

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

   [V4NLRI-V6NH] F. Le Faucheur, E. Rosen, "Advertising an IPv4 NLRI
   with an IPv6 Next Hop", draft-ietf-softwire-v4nlri-v6nh-00.txt,
   January draft-ietf-softwire-v4nlri-v6nh-01.txt, April

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

17. Informative References

   [BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection",
   draft-ietf-bfd-base-08.txt, March 2008.

   [L3VPN-MCAST], "Multicast in MPLS/BGP IP VPNs", E. Rosen, R.
   Aggarwal, draft-ietf-l3vpn-2547bis-mcast-06.txt, January draft-ietf-l3vpn-2547bis-mcast-07.txt, July 2008.

   [L3VPN-MCAST-BGP], "BGP Encodings and Procedures for Multicast in
   MPLS/BGP IP VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C.
   Kodeboniya, draft-ietf-l3vpn-2547bis-mcast-bgp-04.txt, November 2007. draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt, June 2008.

   [MLDP] "Label Distribution Protocol Extensions for Point-to-
   Multipoint and Multipoint-to-Multipoint Label Switched Paths", I.
   Minei, K. Kompella, IJ. Wijnands, B. Thomas, draft-ietf-mpls-ldp-
   p2mp-04, February
   p2mp-05.txt, June 2008.

   [RFC1195] "Use of OSI IS-IS for Routing in TCP/IP and Dual
   Environments", R. Callon, RFC 1195, December 1990.

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

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

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

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

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

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

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

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

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

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

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

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

   [RPF-VECTOR], "The RPF Vector TLV", IJ. Wijnands, A. Boers, E. Rosen,
   draft-ietf-pim-rpf-vector-06.txt, February 2008.

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

   Authors' Addresses

   Jianping Wu
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084

   Phone: +86-10-6278-5983
   Yong Cui
   Tsinghua University
   Department of Computer Science, Tsinghua University
   Beijing  100084

   Phone: +86-10-6278-5822

   Xing Li
   Tsinghua University
   Department of Electronic Engineering, Tsinghua University
   Beijing  100084

   Phone: +86-10-6278-5983

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


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

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


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


   John Scudder
   Juniper Networks
   1194 North Mathilda Avenue
   Sunnyvale, California 94089


18. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

19. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-