doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc5565.txt b/doc/rfc/rfc5565.txt
new file mode 100644
index 0000000..f455ace
--- /dev/null
+++ b/doc/rfc/rfc5565.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                              J. Wu
+Request for Comments: 5565                                        Y. Cui
+Category: Standards Track                            Tsinghua University
+                                                                 C. Metz
+                                                                E. Rosen
+                                                     Cisco Systems, Inc.
+                                                               June 2009
+
+
+                        Softwire Mesh Framework
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   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, as 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.
+
+
+
+
+
+
+
+
+
+
+Wu, et al.                  Standards Track                     [Page 1]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+Abstract
+
+   The Internet needs to be able to handle both IPv4 and IPv6 packets.
+   However, it is expected that some constituent networks of the
+   Internet will be "single-protocol" networks.  One kind of single-
+   protocol network can parse only IPv4 packets and can process only
+   IPv4 routing information; another kind can parse only IPv6 packets
+   and can process only IPv6 routing information.  It is nevertheless
+   required that either kind of single-protocol network be able to
+   provide transit service for the "other" protocol.  This is done by
+   passing the "other kind" of routing information from one edge of the
+   single-protocol network to the other, and by tunneling the "other
+   kind" of data packet from one edge to the other.  The tunnels are
+   known as "softwires".  This framework document explains how the
+   routing information and the data packets of one protocol are passed
+   through a single-protocol network of the other protocol.  The
+   document is careful to specify when this can be done with existing
+   technology and when it requires the development of new or modified
+   technology.
+
+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
+
+
+
+Wu, et al.                  Standards Track                     [Page 2]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+      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
+
+   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
+   information.
+
+   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 that 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 that is needed within the backbone in order to route the
+   packet to the proper egress is, by definition, external routing
+   information.
+
+   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.
+
+
+
+Wu, et al.                  Standards Track                     [Page 3]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   It is, however, possible to provide transit services without
+   requiring that all the backbone routers have the external routing
+   information.  The routing information that 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 that 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
+
+
+
+
+Wu, et al.                  Standards Track                     [Page 4]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+         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 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 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
+   (Resource Reservation Protocol - Traffic Engineering, [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
+
+
+
+
+
+Wu, et al.                  Standards Track                     [Page 5]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   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 Softwire Mesh 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
+   standardized.
+
+   In this framework, the softwires do not form an overlay topology that
+   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 backbone.
+
+   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].
+
+2.  Specification of Requirements
+
+   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].
+
+
+
+
+
+
+
+
+
+Wu, et al.                  Standards Track                     [Page 6]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+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
+
+
+
+
+Wu, et al.                  Standards Track                     [Page 7]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   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, and
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al.                  Standards Track                     [Page 8]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+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.
+
+
+
+Wu, et al.                  Standards Track                     [Page 9]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   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 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.
+
+   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 sections, 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 Internal BGP (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
+
+
+
+Wu, et al.                  Standards Track                    [Page 10]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   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, others do not.
+
+   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 is 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
+
+   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.
+
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 11]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   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, 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 that 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 softwire deployment
+
+
+
+Wu, et al.                  Standards Track                    [Page 12]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   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 that 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 that 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 beyond the basic
+   requirements described in this document.  For example, Quality of
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 13]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   Service (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 framework.
+
+   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.  An IPsec-based softwire would use standard
+   IKEv2 (Internet Key Exchange) [RFC4306] and IPsec [RFC4301]
+   signaling, as that is necessary in order to guarantee the softwire's
+   security properties.
+
+   A GRE-based softwire 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
+   signaling.
+
+   The signaling to be used for GRE and L2TPv3 to cover these scenarios
+   is BGP-based, and is described in [RFC5512].
+
+   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 that 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 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
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 14]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   be triggered by the reception of BGP routing information (such as is
+   described in [RFC5512]); 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
+   policy.
+
+   In many cases, the policy will be very 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 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
+
+
+
+Wu, et al.                  Standards Track                    [Page 15]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   Y".  To support such policies, it is necessary for the AFBRs to be
+   able to advertise their class memberships.  [RFC5512] specifies a way
+   in which an AFBR may advertise, to other AFBRS, various
+   characteristics that may be relevant to the 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 1.
+
+   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 [RFC5512] 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 first
+   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.
+
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 16]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   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 [RFC5512].
+
+   If the tunnel technology being used is RSVP-TE-based MPLS or IPsec,
+   the native signaling procedures of those technologies will need to be
+   used.
+
+   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 endpoints (AFBRs) as well as the
+   tunnels themselves.  These techniques allow operations such as
+   softwire path tracing, remote softwire endpoint pinging, and remote
+   softwire endpoint 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
+   [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 contain the egress AFBR IP address and the softwire
+   identifier as the payload (similar to the MPLS Forwarding Equivalence
+
+
+
+Wu, et al.                  Standards Track                    [Page 17]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   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
+   softwire endpoint reachability, with the loss of reachability being
+   signaled to the softwire application on the local AFBR, thus enabling
+   suitable actions to be taken.  Consideration must be given to the
+   trade-offs between the scalability of such mechanisms versus the time
+   required for detection of loss of endpoint reachability for such
+   automated mechanisms.
+
+   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
+   [L3VPN-MCAST].
+
+   We will focus on supporting those multicast features and protocols
+   that are typically used across inter-provider boundaries.  Support is
+   provided for PIM-SM (Protocol Independent Multicast - Sparse Mode)
+   and PIM-SSM (PIM Source-Specific Mode).  Support for BIDIR-PIM
+   (Bidirectional PIM), BSR (Bootstrap Router Mechanism for PIM), and
+   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.
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 18]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   The one-to-one scheme is not used in [L3VPN-MCAST] because it
+   requires an amount of state in the core routers that 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 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 translates it from E-IP to I-IP, and forwards 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
+   include an "RPF (Reverse Path Forwarding) Vector" [RFC5496] 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 that 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
+   [RFC5496] 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 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 may be possible
+   to do this translation algorithmically.  A can translate the IPv4 S
+   into the corresponding IPv4-mapped IPv6 address [RFC4291], and then B
+   can translate it back.  At the time of this writing, there is no such
+
+
+
+Wu, et al.                  Standards Track                    [Page 19]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   thing as an IPv4-mapped IPv6 multicast address, but if such a thing
+   were to be standardized, then A could also translate the IPv4 G into
+   IPv6, and B could translate it back.  The precise circumstances under
+   which these translations are to be 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 needs 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
+
+   LDP extensions for point-to-multipoint and multipoint-to-multipoint
+   LSPs are specified in [MLDP]; we will use the term "mLDP" to refer to
+   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.
+
+   When an AFBR A receives an 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 an "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 that is its next hop on the route to S.
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 20]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   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
+   that 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
+   LSP.
+
+   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
+   anywhere.
+
+11.2.  MVPN-Like Schemes
+
+   The "MVPN (Multicast VPN)-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 softwire scenarios.
+
+   The MVPN-like schemes can support SM, SSM, and Bidir groups.  They
+   provide a number of options for the control plane:
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 21]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+     - 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 consist 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 softwire
+       scenarios, as every AFBR would have to receive every client
+       multicast packet.
+
+     - Every multicast group mapped to a tree that 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
+   [L3VPN-MCAST].
+
+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 a 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.
+
+
+
+Wu, et al.                  Standards Track                    [Page 22]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+      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
+         ASes.
+
+      3. Ensure that an ASBR that 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" (i.e., 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 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.  Security Considerations
+
+13.1.  Problem Analysis
+
+   In the Softwire Mesh Framework, the data packets that are
+   encapsulated are E-IP data packets that are traveling through the
+   Internet.  These data packets (the softwire "payload") may or may not
+   need such security features as authentication, integrity,
+   confidentiality, or replay 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 that
+   affect the I-IP encapsulation headers, rather than those that affect
+   the E-IP payload.
+
+   Since the encapsulation headers determine the routing of packets
+   traveling through softwires, they must appear "in the clear".
+
+   In the Softwire Mesh Framework, for each receiving endpoint of a
+   tunnel, there are one or more "valid" transmitting endpoints, where
+   the valid transmitting endpoints are those that 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
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 23]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   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 appearing in the destination IP address field of
+   the payload packet.
+
+   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.
+   (The assumption is that the cryptography mechanisms are likely to be
+   more costly than the decapsulation/forwarding mechanisms.  So if one
+   tries to eliminate a flooding attack on the decapsulation/forwarding
+   mechanisms by discarding packets that do not pass a cryptographic
+   integrity test, one ends up just 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 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:
+
+
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 24]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+     - 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 that are 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 the introduction of spoofed packets from within the
+   domain itself.  That may not always be the case.  Also, these
+   techniques 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 that 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
+   them.
+
+
+
+
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 25]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+13.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 [RFC5566].  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 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.  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, as specified in
+   Section 5.2, step 4, of [RFC4301].
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 26]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   Since the 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.
+
+
+
+Wu, et al.                  Standards Track                    [Page 27]
+
+RFC 5565                Softwire Mesh Framework                June 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
+
+   [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.
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 28]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 29]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+15.  Contributors
+
+   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
+
+   David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta,
+   Mingwei Xu, and Ke Xu provided useful input into this document.
+
+
+
+
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 30]
+
+RFC 5565                Softwire Mesh Framework                June 2009
+
+
+Authors' Addresses
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al.                  Standards Track                    [Page 31]
+