draft-ietf-softwire-mesh-framework-06.txt   rfc5565.txt 
Network Working Group J. Wu Network Working Group J. Wu
Internet Draft Y. Cui Request for Comments: 5565 Y. Cui
Intended Status: Standards Track Tsinghua University Category: Standards Track Tsinghua University
Expires: August 16, 2009
C. Metz C. Metz
E. Rosen E. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
February 16, 2009
Softwire Mesh Framework Softwire Mesh Framework
draft-ietf-softwire-mesh-framework-06.txt Status of This Memo
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html. 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 and License Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 2, line 21 skipping to change at page 2, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Abstract Abstract
The Internet needs to be able to handle both IPv4 and IPv6 packets. The Internet needs to be able to handle both IPv4 and IPv6 packets.
However, it is expected that some constituent networks of the However, it is expected that some constituent networks of the
Internet will be "single protocol" networks. One kind of single Internet will be "single-protocol" networks. One kind of single-
protocol network can parse only IPv4 packets and can process only protocol network can parse only IPv4 packets and can process only
IPv4 routing information; another kind can parse only IPv6 packets IPv4 routing information; another kind can parse only IPv6 packets
and can process only IPv6 routing information. It is nevertheless and can process only IPv6 routing information. It is nevertheless
required that either kind of single protocol network be able to required that either kind of single-protocol network be able to
provide transit service for the "other" protocol. This is done by provide transit service for the "other" protocol. This is done by
passing the "other kind" of routing information from one edge of the passing the "other kind" of routing information from one edge of the
single protocol network to the other, and by tunneling the "other single-protocol network to the other, and by tunneling the "other
kind" of data packet from one edge to the other. The tunnels are kind" of data packet from one edge to the other. The tunnels are
known as "Softwires". This framework document explains how the known as "softwires". This framework document explains how the
routing information and the data packets of one protocol are passed routing information and the data packets of one protocol are passed
through a single protocol network of the other protocol. The through a single-protocol network of the other protocol. The
document is careful to specify when this can be done with existing document is careful to specify when this can be done with existing
technology, and when it requires the development of new or modified technology and when it requires the development of new or modified
technology. technology.
Table of Contents Table of Contents
1 Specification of requirements ......................... 4 1. Introduction ....................................................3
2 Introduction .......................................... 4 2. Specification of Requirements ...................................6
3 Scenarios of Interest ................................. 7 3. Scenarios of Interest ...........................................7
3.1 IPv6-over-IPv4 Scenario ............................... 7 3.1. IPv6-over-IPv4 Scenario ....................................7
3.2 IPv4-over-IPv6 Scenario ............................... 9 3.2. IPv4-over-IPv6 Scenario ....................................9
4 General Principles of the Solution .................... 11 4. General Principles of the Solution .............................10
4.1 'E-IP' and 'I-IP' ..................................... 11 4.1. E-IP and I-IP .............................................10
4.2 Routing ............................................... 11 4.2. Routing ...................................................10
4.3 Tunneled Forwarding ................................... 12 4.3. Tunneled Forwarding .......................................11
5 Distribution of Inter-AFBR Routing Information ........ 12 5. Distribution of Inter-AFBR Routing Information .................11
6 Softwire Signaling .................................... 14 6. Softwire Signaling .............................................13
7 Choosing to Forward Through a Softwire ................ 16 7. Choosing to Forward through a Softwire .........................15
8 Selecting a Tunneling Technology ...................... 16 8. Selecting a Tunneling Technology ...............................15
9 Selecting the Softwire for a Given Packet ............. 17 9. Selecting the Softwire for a Given Packet ......................16
10 Softwire OAM and MIBs ................................. 18 10. Softwire OAM and MIBs .........................................17
10.1 Operations and Maintenance (OAM) ...................... 18 10.1. Operations and Maintenance (OAM) .........................17
10.2 MIBs .................................................. 19 10.2. MIBs .....................................................18
11 Softwire Multicast .................................... 19 11. Softwire Multicast ............................................18
11.1 One-to-One Mappings ................................... 20 11.1. One-to-One Mappings ......................................18
11.1.1 Using PIM in the Core ................................. 20 11.1.1. Using PIM in the Core .............................19
11.1.2 Using mLDP and Multicast MPLS in the Core ............. 21 11.1.2. Using mLDP and Multicast MPLS in the Core .........20
11.2 MVPN-like Schemes ..................................... 22 11.2. MVPN-Like Schemes ........................................21
12 Inter-AS Considerations ............................... 23 12. Inter-AS Considerations .......................................22
13 IANA Considerations ................................... 24 13. Security Considerations .......................................23
14 Security Considerations ............................... 24 13.1. Problem Analysis .........................................23
14.1 Problem Analysis ...................................... 24 13.2. Non-Cryptographic Techniques .............................24
14.2 Non-cryptographic techniques .......................... 26 13.3. Cryptographic Techniques .................................26
14.3 Cryptographic techniques .............................. 27 14. References ....................................................27
15 Contributors .......................................... 28 14.1. Normative References .....................................27
16 Acknowledgments ....................................... 29 14.2. Informative References ...................................28
17 Normative References .................................. 30 15. Contributors ..................................................30
18 Informative References ................................ 31 16. Acknowledgments ...............................................30
1. 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].
2. Introduction 1. Introduction
The routing information in any IP backbone network can be thought of The routing information in any IP backbone network can be thought of
as being in one of two categories: "internal routing information" or as being in one of two categories: "internal routing information" or
"external routing information". The internal routing information "external routing information". The internal routing information
consists of routes to the nodes that belong to the backbone, and to consists of routes to the nodes that belong to the backbone, and to
the interfaces of those nodes. External routing information consists the interfaces of those nodes. External routing information consists
of routes to destinations beyond the backbone, especially of routes to destinations beyond the backbone, especially
destinations to which the backbone is not directly attached. In destinations to which the backbone is not directly attached. In
general, BGP [RFC4271] is used to distribute external routing general, BGP [RFC4271] is used to distribute external routing
information, and an "Interior Gateway Protocol" (IGP) such as OSPF information, and an Interior Gateway Protocol (IGP) such as OSPF
[RFC2328] or IS-IS [RFC1195] is used to distribute internal routing [RFC2328] or IS-IS [RFC1195] is used to distribute internal routing
information. information.
Often an IP backbone will provide transit routing services for Often an IP backbone will provide transit routing services for
packets that originate outside the backbone, and whose destinations packets that originate outside the backbone and whose destinations
are outside the backbone. These packets enter the backbone at one of are outside the backbone. These packets enter the backbone at one of
its "edge routers". They are routed through the backbone to another its "edge routers". They are routed through the backbone to another
edge router, after which they leave the backbone and continue on edge router, after which they leave the backbone and continue on
their way. The edge nodes of the backbone are often known as their way. The edge nodes of the backbone are often known as
"Provider Edge" (PE) routers. The term "ingress" (or "ingress PE") "Provider Edge" (PE) routers. The term "ingress" (or "ingress PE")
refers to the router at which a packet enters the backbone, and the 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 term "egress" (or "egress PE") refers to the router at which it
leaves the backbone. Interior nodes are often known as "P routers". leaves the backbone. Interior nodes are often known as "P routers".
Routers which are outside the backbone but directly attached to it Routers that are outside the backbone but directly attached to it are
are known as "Customer Edge" (CE) routers. (This terminology is known as "Customer Edge" (CE) routers. (This terminology is taken
taken from [RFC4364].) from [RFC4364].)
When a packet's destination is outside the backbone, the routing When a packet's destination is outside the backbone, the routing
information which is needed within the backbone in order to route the information that is needed within the backbone in order to route the
packet to the proper egress is, by definition, external routing packet to the proper egress is, by definition, external routing
information. information.
Traditionally, the external routing information has been distributed Traditionally, the external routing information has been distributed
by BGP to all the routers in the backbone, not just to the edge 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 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 the interior nodes has been expected to look up the packet's
destination address and route it towards the egress point. This is destination address and route it towards the egress point. This is
known as "native forwarding": the interior nodes look into each known as "native forwarding": the interior nodes look into each
packet's header in order to match the information in the header with packet's header in order to match the information in the header with
the external routing information. the external routing information.
It is, however, possible to provide transit services without It is, however, possible to provide transit services without
requiring that all the backbone routers have the external routing requiring that all the backbone routers have the external routing
information. The routing information which BGP distributes to each information. The routing information that BGP distributes to each
ingress router specifies the egress router for each route. The ingress router specifies the egress router for each route. The
ingress router can therefore "tunnel" the packet directly to the ingress router can therefore "tunnel" the packet directly to the
egress router. "Tunneling the packet" means putting on some sort of egress router. "Tunneling the packet" means putting on some sort of
encapsulation header which will force the interior routers to forward encapsulation header that will force the interior routers to forward
the packet to the egress router. The original packet is known as the the packet to the egress router. The original packet is known as the
"encapsulation payload". The P routers do not look at the packet "encapsulation payload". The P routers do not look at the packet
header of the payload, but only at the encapsulation header. Since header of the payload but only at the encapsulation header. Since
the path to the egress router is part of the internal routing the path to the egress router is part of the internal routing
information of the backbone, the interior routers then do not need to information of the backbone, the interior routers then do not need to
know the external routing information. This is known as "tunneled know the external routing information. This is known as "tunneled
forwarding". Of course, before the packet can leave the egress, it forwarding". Of course, before the packet can leave the egress, it
has to be decapsulated. has to be decapsulated.
The scenario where the P routers do not have external routes is The scenario where the P routers do not have external routes is
sometimes known as a "BGP-free core". That is something of a sometimes known as a "BGP-free core". That is something of a
misnomer, though, since the crucial aspect of this scenario is not 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 that the interior nodes don't run BGP, but that they don't maintain
skipping to change at page 5, line 49 skipping to change at page 4, line 49
information consists not of VPN routes, but of "ordinary" Internet information consists not of VPN routes, but of "ordinary" Internet
routes. It can be used any time it is desired to keep external 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 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 any time it is desired for any reason to avoid the native forwarding
of certain kinds of packets. of certain kinds of packets.
This framework focuses on two such scenarios. This framework focuses on two such scenarios.
1. In this scenario, the backbone's interior nodes support only 1. In this scenario, the backbone's interior nodes support only
IPv6. They do not maintain IPv4 routes at all, and are not IPv6. They do not maintain IPv4 routes at all, and are not
expected to parse IPv4 packet headers. Yet it is desired to expected to parse IPv4 packet headers. Yet, it is desired to
use such a backbone to provide transit services for IPv4 use such a backbone to provide transit services for IPv4
packets. Therefore tunneled forwarding of IPv4 packets is packets. Therefore, tunneled forwarding of IPv4 packets is
required. Of course, the edge nodes must have the IPv4 routes, required. Of course, the edge nodes must have the IPv4 routes,
but the ingress must perform an encapsulation in order to get but the ingress must perform an encapsulation in order to get
an IPv4 packet forwarded to the egress. an IPv4 packet forwarded to the egress.
2. This scenario is the reverse of scenario 1, i.e., the 2. This scenario is the reverse of scenario 1, i.e., the
backbone's interior nodes support only IPv4, but it is desired backbone's interior nodes support only IPv4, but it is desired
to use the backbone for IPv6 transit. to use the backbone for IPv6 transit.
In these scenarios, a backbone whose interior nodes support only one In these scenarios, a backbone whose interior nodes support only one
of the two address families is required to provide transit services of the two address families is required to provide transit services
for the other. The backbone's edge routers must, of course, support for the other. The backbone's edge routers must, of course, support
both address families. We use the term "Address Family Border both address families. We use the term "Address Family Border
Router" (AFBR) to refer to these PE routers. The tunnels that are Router" (AFBR) to refer to these PE routers. The tunnels that are
used for forwarding are referred to as "softwires". used for forwarding are referred to as "softwires".
These two scenarios are known as the "Softwire Mesh Problem" [SW- These two scenarios are known as the "Softwire Mesh Problem"
PROB], and the framework specified in this draft is therefore known [SW-PROB], and the framework specified in this document is therefore
as the "Softwire Mesh Framework". In this framework, only the AFBRs known as the "Softwire Mesh Framework". In this framework, only the
need to support both address families. The CE routers support only a AFBRs need to support both address families. The CE routers support
single address family, and the P routers support only the other only a single address family, and the P routers support only the
address family. other address family.
It is possible to address these scenarios via a large variety of It is possible to address these scenarios via a large variety of
tunneling technologies. This framework does not mandate the use of tunneling technologies. This framework does not mandate the use of
any particular tunneling technology. In any given deployment, the any particular tunneling technology. In any given deployment, the
choice of tunneling technology is a matter of policy. The framework choice of tunneling technology is a matter of policy. The framework
accommodates at least the use of MPLS ([RFC3031], [RFC3032]), both accommodates at least the use of MPLS ([RFC3031], [RFC3032]) -- both
LDP-based (Label Distribution Protocol, [RFC5036]) and RSVP-TE-based LDP-based (Label Distribution Protocol, [RFC5036]) and RSVP-TE-based
([RFC3209]), L2TPv3 [RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003]. (Resource Reservation Protocol - Traffic Engineering, [RFC3209]) --
The framework will also accommodate the use of IPsec tunneling, when L2TPv3 [RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003]. The
that is necessary in order to meet security requirements. 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 It is expected that, in many deployments, the choice of tunneling
technology will be made by a simple expression of policy, such as 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 IP-IP tunnels", or "always use LDP-based MPLS", or
"always use L2TPv3". "always use L2TPv3".
However, other deployments may have a mixture of routers, some of However, other deployments may have a mixture of routers, some of
which support, say, both GRE and L2TPv3, but others of which support which support, say, both GRE and L2TPv3, but others of which support
only one of those techniques. It is desirable therefore to allow the only one of those techniques. It is desirable therefore to allow the
network administration to create a small set of classes, and to 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. 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, Then the routers can advertise their class memberships to each other,
and the encapsulation policies can be expressed as, e.g., "use L2TPv3 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 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 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 be able to advertise their class memberships; a standard way of doing
this must be developed. this must be developed.
Policy may also require a certain class of traffic to receive a Policy may also require a certain class of traffic to receive a
certain quality of service, and this may impact the choice of tunnel certain quality of service, and this may impact the choice of tunnel
and/or tunneling technology used for packets in that class. This and/or tunneling technology used for packets in that class. This
needs to be accommodated by the softwires framework. needs to be accommodated by the Softwire Mesh Framework.
The use of tunneled forwarding often requires that some sort of The use of tunneled forwarding often requires that some sort of
signaling protocol be used to set up and/or maintain the tunnels. signaling protocol be used to set up and/or maintain the tunnels.
Many of the tunneling technologies accommodated by this framework Many of the tunneling technologies accommodated by this framework
already have their own signaling protocols. However, some do not, already have their own signaling protocols. However, some do not,
and in some cases the standard signaling protocol for a particular and in some cases the standard signaling protocol for a particular
tunneling technology may not be appropriate, for one or another tunneling technology may not be appropriate (for one or another
reason, in the scenarios of interest. In such cases (and in such reason) in the scenarios of interest. In such cases (and in such
cases only), new signaling methodologies need to be defined and cases only), new signaling methodologies need to be defined and
standardized. standardized.
In this framework, the softwires do not form an overlay topology In this framework, the softwires do not form an overlay topology that
which is visible to routing; routing adjacencies are not maintained is visible to routing; routing adjacencies are not maintained over
over the softwires, and routing control packets are not sent through the softwires, and routing control packets are not sent through the
the softwires. Routing adjacencies among backbone nodes (including softwires. Routing adjacencies among backbone nodes (including the
the edge nodes) are maintained via the native technology of the edge nodes) are maintained via the native technology of the backbone.
backbone.
There is already a standard routing method for distributing external There is already a standard routing method for distributing external
routing information among AFBRs, namely BGP. However, in the routing information among AFBRs, namely BGP. However, in the
scenarios of interest, we may be using IPv6-based BGP sessions to scenarios of interest, we may be using IPv6-based BGP sessions to
pass IPv4 routing information, and we may be using IPv4-based BGP pass IPv4 routing information, and we may be using IPv4-based BGP
sessions to pass IPv6 routing information. Furthermore, when IPv4 sessions to pass IPv6 routing information. Furthermore, when IPv4
traffic is to be tunneled over an IPv6 backbone, it is necessary to 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 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 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 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 encoding an IPv6 address as the next hop for an IPv4 route is
specified in [V4NLRI-V6NH]. 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].
3. Scenarios of Interest 3. Scenarios of Interest
3.1. IPv6-over-IPv4 Scenario 3.1. IPv6-over-IPv4 Scenario
In this scenario, the client networks run IPv6 but the backbone In this scenario, the client networks run IPv6 but the backbone
network runs IPv4. This is illustrated in Figure 1. network runs IPv4. This is illustrated in Figure 1.
+--------+ +--------+ +--------+ +--------+
| IPv6 | | IPv6 | | IPv6 | | IPv6 |
| Client | | Client | | Client | | Client |
skipping to change at page 8, line 44 skipping to change at page 7, line 51
| X | | X |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
+--------+ +--------+ +--------+ +--------+
| IPv6 | | IPv6 | | IPv6 | | IPv6 |
| Client | | Client | | Client | | Client |
| Network| | Network| | Network| | Network|
+--------+ +--------+ +--------+ +--------+
Figure 1 IPv6-over-IPv4 Scenario Figure 1: IPv6-over-IPv4 Scenario
The IPv4 transit core may or may not run MPLS. If it does, MPLS may
The IPv4 transit core may or may not run MPLS. If it does, MPLS may be be used as part of the solution.
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 While Figure 1 does not show any "backdoor" connections among the
networks is via the pictured transit core network. Hence the routing client networks, this framework assumes that there will be such
solution must be robust in any kind of topology. 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 Many mechanisms for providing IPv6 connectivity across IPv4 networks
have been devised over the past ten years. A number of different have been devised over the past ten years. A number of different
tunneling mechanisms have been used, some provisioned manually, others tunneling mechanisms have been used, some provisioned manually, and
based on special addressing. More recently, L3VPN (Layer 3 Virtual others based on special addressing. More recently, L3VPN (Layer 3
Private Network) techniques from [RFC4364] have been extended to provide Virtual Private Network) techniques from [RFC4364] have been extended
IPv6 connectivity, using MPLS in the AFBRs and optionally in the to provide IPv6 connectivity, using MPLS in the AFBRs and,
backbone [V6NLRI-V4NH]. The solution described in this framework can be optionally, in the backbone [V6NLRI-V4NH]. The solution described in
thought of as a superset of [V6NLRI-V4NH], with a more generalized this framework can be thought of as a superset of [V6NLRI-V4NH], with
scheme for choosing the tunneling (softwire) technology. In this a more generalized scheme for choosing the tunneling (softwire)
framework, MPLS is allowed, but not required, even at the AFBRs. As in technology. In this framework, MPLS is allowed -- but not required
[V6NLRI-V4NH], there is no manual provisioning of tunnels, and no -- even at the AFBRs. As in [V6NLRI-V4NH], there is no manual
special addressing is required. provisioning of tunnels, and no special addressing is required.
3.2. IPv4-over-IPv6 Scenario 3.2. IPv4-over-IPv6 Scenario
In this scenario, the client networks run IPv4 but the backbone In this scenario, the client networks run IPv4 but the backbone
network runs IPv6. This is illustrated in Figure 2. network runs IPv6. This is illustrated in Figure 2.
+--------+ +--------+ +--------+ +--------+
| IPv4 | | IPv4 | | IPv4 | | IPv4 |
| Client | | Client | | Client | | Client |
| Network| | Network| | Network| | Network|
skipping to change at page 10, line 44 skipping to change at page 9, line 49
| X | | X |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
+--------+ +--------+ +--------+ +--------+
| IPv4 | | IPv4 | | IPv4 | | IPv4 |
| Client | | Client | | Client | | Client |
| Network| | Network| | Network| | Network|
+--------+ +--------+ +--------+ +--------+
Figure 2 IPv4-over-IPv6 Scenario 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 The IPv6 transit core may or may not run MPLS. If it does, MPLS may
networks, this framework assumes that there will be such connections. be used as part of the solution.
That is, there is no assumption the only path between two client While Figure 2 does not show any "backdoor" connections among the
networks is via the pictured transit core network. Hence the routing client networks, this framework assumes that there will be such
solution must be robust in any kind of topology. 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 While the issue of IPv6-over-IPv4 has received considerable attention
the past, the scenario of IPv4-over-IPv6 has not. Yet it is a 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 significant emerging requirement, as a number of service providers
building IPv6 backbone networks and do not wish to provide native IPv4 are building IPv6 backbone networks and do not wish to provide native
support in their core routers. These service providers have a large IPv4 support in their core routers. These service providers have a
legacy of IPv4 networks and applications that need to operate across large legacy of IPv4 networks and applications that need to operate
their IPv6 backbone. Solutions for this do not exist yet because it had across their IPv6 backbone. Solutions for this do not exist yet
always been assumed that the backbone networks of the foreseeable future because it had always been assumed that the backbone networks of the
would be dual stack. foreseeable future would be dual stack.
4. General Principles of the Solution 4. General Principles of the Solution
This section gives a very brief overview of the procedures. The This section gives a very brief overview of the procedures. The
subsequent sections provide more detail. subsequent sections provide more detail.
4.1. 'E-IP' and 'I-IP' 4.1. E-IP and I-IP
In the following we use the term "I-IP" ("Internal IP") to refer to In the following sections, we use the term "I-IP" (Internal IP) to
the form of IP (i.e., either IPv4 or IPv6) that is supported by the refer to the form of IP (i.e., either IPv4 or IPv6) that is supported
transit network. We use the term "E-IP" ("External IP") to refer to by the transit network. We use the term "E-IP" (External IP) to
the form of IP that is supported by the client networks. In the refer to the form of IP that is supported by the client networks.
scenarios of interest, E-IP is IPv4 if and only if I-IP is IPv6, and In the scenarios of interest, E-IP is IPv4 if and only if I-IP is
E-IP is IPv6 if and only if I-IP is IPv4. 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 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 have only I-IP routing information, and they are not
expected to be able to parse E-IP headers. We similarly assume that expected to be able to parse E-IP headers. We similarly assume that
the CE routers support only E-IP. the CE routers support only E-IP.
The AFBRs handle both I-IP and E-IP. However, only I-IP is used on 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- AFBR's "core-facing interfaces", and E-IP is only used on its client-
facing interfaces. facing interfaces.
4.2. Routing 4.2. Routing
The P routers and the AFBRs of the transit network participate in an The P routers and the AFBRs of the transit network participate in an
IGP, for the purposes of distributing I-IP routing information. IGP for the purposes of distributing I-IP routing information.
The AFBRs use IBGP to exchange E-IP routing information with each The AFBRs use Internal BGP (IBGP) to exchange E-IP routing
other. Either there is a full mesh of IBGP connections among the information with each other. Either there is a full mesh of IBGP
AFBRs, or else some or all of the AFBRs are clients of a BGP Route connections among the AFBRs, or else some or all of the AFBRs are
Reflector. Although these IBGP connections are used to pass E-IP clients of a BGP Route Reflector. Although these IBGP connections
routing information (i.e., the NLRI of the BGP updates is in the E-IP are used to pass E-IP routing information (i.e., the Network Layer
address family), the IBGP connections run over I-IP, and the "BGP Reachability Information (NLRI) of the BGP updates is in the E-IP
next hop" for each E-IP NLRI is in the I-IP address family. 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 4.3. Tunneled Forwarding
When an ingress AFBR receives an E-IP packet from a client facing 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 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- 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, distributed route whose next hop is the I-IP address of another AFBR,
the egress AFBR. the egress AFBR.
The ingress AFBR must forward the packet through a tunnel (i.e, The ingress AFBR must forward the packet through a tunnel (i.e,
through a "softwire") to the egress AFBR. This is done by through a softwire) to the egress AFBR. This is done by
encapsulating the packet, using an encapsulation header which the P encapsulating the packet, using an encapsulation header that the P
routers can process, and which will cause the P routers to send the routers can process and that will cause the P routers to send the
packet to the egress AFBR. The egress AFBR then extracts 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 payload, i.e., the original E-IP packet, and forwards it further by
looking up its IP destination address. looking up its IP destination address.
Several kinds of tunneling technologies are supported. Some of those Several kinds of tunneling technologies are supported. Some of those
technologies require explicit AFBR-to-AFBR signaling before the technologies require explicit AFBR-to-AFBR signaling before the
tunnel can be used, others do not. tunnel can be used, others do not.
Transmitting a packet through a softwire always requires that an Transmitting a packet through a softwire always requires that an
encapsulation header be added to the original packet. The resulting encapsulation header be added to the original packet. The resulting
skipping to change at page 12, line 47 skipping to change at page 11, line 47
the context of tunneled forwarding may be found in [RFC4459]. the context of tunneled forwarding may be found in [RFC4459].
5. Distribution of Inter-AFBR Routing Information 5. Distribution of Inter-AFBR Routing Information
AFBRs peer with routers in the client networks to exchange routing AFBRs peer with routers in the client networks to exchange routing
information for the E-IP family. information for the E-IP family.
AFBRs use BGP to distribute the E-IP routing information to each 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 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 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 AFBR has an IBGP session to one or two Route Reflectors rather than
to other AFBRs. to other AFBRs.
The BGP sessions between the AFBRs, or between the AFBRs and the 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 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 is, if the transit core supports only IPv6, the IBGP sessions used to
distribute IPv4 routing information from the client networks will run distribute IPv4 routing information from the client networks will run
over IPv6; if the transit core supports only IPv4, the IBGP sessions over IPv6; if the transit core supports only IPv4, the IBGP sessions
used to distribute IPv6 routing information from the client networks used to distribute IPv6 routing information from the client networks
will run over IPv4. The BGP sessions thus use the native networking will run over IPv4. The BGP sessions thus use the native networking
layer of the core; BGP messages are NOT tunneled through softwires or layer of the core; BGP messages are NOT tunneled through softwires or
through any other mechanism. through any other mechanism.
In BGP, a routing update associates an address prefix (or more In BGP, a routing update associates an address prefix (or more
generally, "Network Layer Reachability Information", or NLRI) with generally, NLRI) with the address of a BGP next hop (NH). The NLRI
the address of a "BGP Next Hop" (NH). The NLRI is associated with a is associated with a particular address family. The NH address is
particular address family. The NH address is also associated with a also associated with a particular address family, which may be the
particular address family, which may be the same as or different than same as or different than the address family associated with the
the address family associated with the NLRI. Generally the NH NLRI. Generally, the NH address belongs to the address family that
address belongs to the address family that is used to communicate is used to communicate with the BGP speaker to whom the NH address
with the BGP speaker to whom the NH address belongs. belongs.
Since routing updates which contain information about E-IP address Since routing updates that contain information about E-IP address
prefixes are carried over BGP sessions that use I-IP transport, and prefixes are carried over BGP sessions that use I-IP transport, and
since the BGP messages are not tunneled, a BGP update providing since the BGP messages are not tunneled, a BGP update providing
information about an E-IP address prefix will need to specify a next information about an E-IP address prefix will need to specify a next
hop address in the I-IP family. hop address in the I-IP family.
Due to a variety of historical circumstances, when the NLRI and the 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 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 always obvious how the NH should be encoded. There is a different
encoding procedure for each pair of address families. encoding procedure for each pair of address families.
skipping to change at page 13, line 52 skipping to change at page 12, line 52
If a BGP speaker sends an update for an NLRI in the E-IP family, and 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 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 I-IP network layer, and the BGP speaker is advertising itself as
the NH for that NLRI, then the BGP speaker MUST, unless explicitly 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 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. 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 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 this rule unless one's BGP peers have advertised a particular BGP
capability. This leads to the following softwires deployment capability. This leads to the following softwire deployment
restriction: if a BGP Capability is defined for the case in which an 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 E-IP NLRI has an I-IP NH, all the AFBRs in a given transit core MUST
advertise that capability. advertise that capability.
If an AFBR has multiple IP addresses, the network administrators If an AFBR has multiple IP addresses, the network administrators
usually have considerable flexibility in choosing which one the AFBR usually have considerable flexibility in choosing which one the AFBR
uses to identify itself as the next hop in a BGP update. However, if 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 the AFBR expects to receive packets through a softwire of a
particular tunneling technology, and if the AFBR is known to that particular tunneling technology, and if the AFBR is known to that
tunneling technology via a specific IP address, then that same IP 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 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 the BGP updates. For example, if L2TPv3 tunneling is used, then the
IP address which the AFBR uses when engaging in L2TPv3 signaling must 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 be the same as the IP address it uses to identify itself in the next
hop field of a BGP update. hop field of a BGP update.
In [V6NLRI-V4NH], IPv6 routing information is distributed using the In [V6NLRI-V4NH], IPv6 routing information is distributed using the
labeled IPv6 address family. This allows the egress AFBR to labeled IPv6 address family. This allows the egress AFBR to
associate an MPLS label with each IPv6 address prefix. If an ingress associate an MPLS label with each IPv6 address prefix. If an ingress
AFBR forwards packets through a softwire than can carry MPLS packets, AFBR forwards packets through a softwire that can carry MPLS packets,
each data packet can carry the MPLS label corresponding to the IPv6 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 route that it matched. This may be useful at the egress AFBR, for
demultiplexing and/or enhanced performance. It is also possible to demultiplexing and/or enhanced performance. It is also possible to
do the same for the IPv4 address family, i.e., to use the labeled 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 IPv4 address family instead of the IPv4 address family. The use of
the labeled IP address families in this manner is OPTIONAL. the labeled IP address families in this manner is OPTIONAL.
6. Softwire Signaling 6. Softwire Signaling
A mesh of inter-AFBR softwires spanning the transit core must be in A mesh of inter-AFBR softwires spanning the transit core must be in
place before packets can flow between client networks. Given N dual- place before packets can flow between client networks. Given N dual-
stack AFBRs, this requires N^2 "point-to-point IP" or "label switched stack AFBRs, this requires N^2 "point-to-point IP" or "label switched
path" (LSP) tunnels. While in theory these could be configured path" (LSP) tunnels. While in theory these could be configured
manually, that would result in a very undesirable O(N^2) provisioning manually, that would result in a very undesirable O(N^2) provisioning
problem. Therefore manual configuration of point-to-point tunnels is problem. Therefore, manual configuration of point-to-point tunnels
not considered part of this framework. is not considered part of this framework.
Because the transit core is providing layer 3 transit services, Because the transit core is providing layer 3 transit services,
point-to-point tunnels are not required by this framework; point-to-point tunnels are not required by this framework;
multipoint-to-point tunnels are all that is needed. In a multipoint- 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 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 way to tell which router put the packet into the tunnel. This models
the native IP forwarding paradigm, wherein the egress router cannot the native IP forwarding paradigm, wherein the egress router cannot
determine a given packet's ingress router. Of course, point-to-point determine a given packet's ingress router. Of course, point-to-point
tunnels might be required for some reason which goes beyond the basic tunnels might be required for some reason beyond the basic
requirements described in this document. E.g., QoS or security requirements described in this document. For example, Quality of
considerations might require the use of point-to-point tunnels. So Service (QoS) or security considerations might require the use of
point-to-point tunnels are allowed, but not required, by this point-to-point tunnels. So point-to-point tunnels are allowed, but
framework. not required, by this framework.
If it is desired to use a particular tunneling technology for the If it is desired to use a particular tunneling technology for the
softwires, and if that technology has its own "native" signaling softwires, and if that technology has its own "native" signaling
methodology, the presumption is that the native signaling will be methodology, the presumption is that the native signaling will be
used. This would certainly apply to MPLS-based softwires, where LDP used. This would certainly apply to MPLS-based softwires, where LDP
or RSVP-TE would be used. A softwire based on IPsec would use or RSVP-TE would be used. An IPsec-based softwire would use standard
standard IKEv2 (Internet Key Exchange) [RFC4306] and IPsec [RFC4301] IKEv2 (Internet Key Exchange) [RFC4306] and IPsec [RFC4301]
signaling, as that is necessary in order to guarantee the softwire's signaling, as that is necessary in order to guarantee the softwire's
security properties. security properties.
A Softwire based on GRE might or might not require signaling, A GRE-based softwire might or might not require signaling, depending
depending on whether various optional GRE header fields are to be on whether various optional GRE header fields are to be used. GRE
used. GRE does not have any "native" signaling, so for those cases, does not have any "native" signaling, so for those cases, a signaling
a signaling procedure needs to be developed to support Softwires. procedure needs to be developed to support softwires.
Another possible softwire technology is L2TPv3. While L2TPv3 does Another possible softwire technology is L2TPv3. While L2TPv3 does
have its own native signaling, that signaling sets up point-to-point 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 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 a multipoint-to-point mode, and this requires a different kind of
signaling. signaling.
The signaling to be used for GRE and L2TPv3 to cover these scenarios The signaling to be used for GRE and L2TPv3 to cover these scenarios
is BGP-based, and is described in [ENCAPS-SAFI]. is BGP-based, and is described in [RFC5512].
If IP-IP tunneling is used, or if GRE tunneling is used without If IP-IP tunneling is used, or if GRE tunneling is used without
options, no signaling is required, as the only information needed by options, no signaling is required, as the only information needed by
the ingress AFBR to create the encapsulation header is the IP address the ingress AFBR to create the encapsulation header is the IP address
of the egress AFBR, and that is distributed by BGP. of the egress AFBR, and that is distributed by BGP.
When the encapsulation IP header is constructed, there may be fields When the encapsulation IP header is constructed, there may be fields
in the IP whose value is determined neither by whatever signaling has in the IP whose value is determined neither by whatever signaling has
been done nor by the distributed routing information. The values of been done nor by the distributed routing information. The values of
these fields are determined by policy in the ingress AFBR. Examples these fields are determined by policy in the ingress AFBR. Examples
of such fields may be the TTL (Time to Live) field, the DSCP of such fields may be the TTL (Time to Live) field, the DSCP
(DiffServ Service Classes) bits, etc. (Diffserv Service Classes) bits, etc.
It is desirable for all necessary softwires to be fully set up before 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. the arrival of any packets that need to go through the softwires.
That is, the softwires should be "always on". From the perspective That is, the softwires should be "always on". From the perspective
of any particular AFBR, the softwire endpoints are always BGP next of any particular AFBR, the softwire endpoints are always BGP next
hops of routes which the AFBR has installed. This suggests that any hops of routes that the AFBR has installed. This suggests that any
necessary softwire signaling should be either be done as part of necessary softwire signaling should either be done as part of normal
normal system startup (as would happen, e.g., with LDP-based MPLS), system startup (as would happen, e.g., with LDP-based MPLS) or else
or else should be triggered by the reception of BGP routing be triggered by the reception of BGP routing information (such as is
information (such as is described in [ENCAPS-SAFI]); it is also described in [RFC5512]); it is also helpful if distribution of the
helpful if distribution of the routing information that serves as the routing information that serves as the trigger is prioritized.
trigger is prioritized.
7. Choosing to Forward Through a Softwire 7. Choosing to Forward through a Softwire
The decision to forward through a softwire, instead of to forward The decision to forward through a softwire, instead of to forward
natively, is made by the ingress AFBR. This decision is a matter of natively, is made by the ingress AFBR. This decision is a matter of
policy. policy.
In many cases, the policy will be very simple. Some useful policies In many cases, the policy will be very simple. Some useful policies
are: are:
- if routing says that an E-IP packet has to be sent out a "core- - 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 facing interface to an I-IP core, then send the packet through a
softwire softwire.
- if routing says that an E-IP packet has to be sent out an - 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 interface that only supports I-IP packets, then send the E-IP
packets through a softwire packet through a softwire.
- if routing says that the BGP next hop address for an E-IP packet - 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 is an I-IP address, then send the E-IP packet through a softwire.
- if the route which is the best match for a particular packet's - If the route that is the best match for a particular packet's
destination address is a BGP-distributed route, then send the destination address is a BGP-distributed route, then send the
packet through a softwire (i.e., tunnel all BGP-routed packets). packet through a softwire (i.e., tunnel all BGP-routed packets).
More complicated policies are also possible, but a consideration of More complicated policies are also possible, but a consideration of
those policies is outside the scope of this document. those policies is outside the scope of this document.
8. Selecting a Tunneling Technology 8. Selecting a Tunneling Technology
The choice of tunneling technology is a matter of policy configured The choice of tunneling technology is a matter of policy configured
at the ingress AFBR. at the ingress AFBR.
It is envisioned that in most cases, the policy will be a very simple It is envisioned that, in most cases, the policy will be a very
one, and will be the same at all the AFBRs of a given transit core. simple one, and will be the same at all the AFBRs of a given transit
E.g., "always use LDP-based MPLS", or "always use L2TPv3". core -- e.g., "always use LDP-based MPLS" or "always use L2TPv3".
However, other deployments may have a mixture of routers, some of However, other deployments may have a mixture of routers, some of
which support, say, both GRE and L2TPv3, but others of which support which support, say, both GRE and L2TPv3, but others of which support
only one of those techniques. It is desirable therefore to allow the only one of those techniques. It is desirable therefore to allow the
network administration to create a small set of classes, and to 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. 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, Then the routers can advertise their class memberships to each other,
and the encapsulation policies can be expressed as, e.g., "use L2TPv3 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 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 Y". To support such policies, it is necessary for the AFBRs to be
able to advertise their class memberships. [ENCAPS-SAFI] specifies a able to advertise their class memberships. [RFC5512] specifies a way
way in which an AFBR may advertise, to other AFBRS, various in which an AFBR may advertise, to other AFBRS, various
characteristics which may be relevant to the policy (e.g., "I belong characteristics that may be relevant to the policy (e.g., "I belong
to class Y"). In many cases, these characteristics can be to class Y"). In many cases, these characteristics can be
represented by arbitrarily selected communities or extended represented by arbitrarily selected communities or extended
communities, and the policies at the ingress can be expressed in communities, and the policies at the ingress can be expressed in
terms of these classes (i.e., communities). terms of these classes (i.e., communities).
Policy may also require a certain class of traffic to receive a Policy may also require a certain class of traffic to receive a
certain quality of service, and this may impact the choice of tunnel certain quality of service, and this may impact the choice of tunnel
and/or tunneling technology used for packets in that class. This and/or tunneling technology used for packets in that class. This
framework allows a variety of tunneling technologies to be used for framework allows a variety of tunneling technologies to be used for
instantiating softwires. The choice of tunneling technology is a instantiating softwires. The choice of tunneling technology is a
matter of policy, as discussed in section 2. matter of policy, as discussed in Section 1.
While in many cases the policy will be unconditional, e.g., "always While in many cases the policy will be unconditional, e.g., "always
use L2TPv3 for softwires", in other cases the policy may specify that use L2TPv3 for softwires", in other cases the policy may specify that
the choice is conditional upon information about the softwire remote 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 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 talk to routers in class Y". It is desirable therefore to allow the
network administration to create a small set of classes, and to 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. 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 If each such class is represented as a community or extended
community, then [ENCAPS-SAFI] specifies a method that AFBRs can use community, then [RFC5512] specifies a method that AFBRs can use to
to advertise their class memberships to each other. advertise their class memberships to each other.
This framework also allows for policies of arbitrary complexity, This framework also allows for policies of arbitrary complexity,
which may depend on characteristics or attributes of individual which may depend on characteristics or attributes of individual
address prefixes, as well as on QoS or security considerations. address prefixes as well as on QoS or security considerations.
However, the specification of such policies is not within the scope However, the specification of such policies is not within the scope
of this document. of this document.
9. Selecting the Softwire for a Given Packet 9. Selecting the Softwire for a Given Packet
Suppose it has been decided to send a given packet through a Suppose it has been decided to send a given packet through a
softwire. Routing provides the address, in the address family of the softwire. Routing provides the address, in the address family of the
transport network, of the BGP next hop. The packet MUST be sent transport network, of the BGP next hop. The packet MUST be sent
through a softwire whose remote endpoint address is the same as the through a softwire whose remote endpoint address is the same as the
BGP next hop address. BGP next hop address.
Sending a packet through a softwire is a matter of encapsulating the Sending a packet through a softwire is a matter of first
packet with an encapsulation header that can be processed by the encapsulating the packet with an encapsulation header that can be
transit network, and then transmitting towards the softwire's remote processed by the transit network and then transmitting towards the
endpoint address. softwire's remote endpoint address.
In many cases, once one knows the remote endpoint address, one has In many cases, once one knows the remote endpoint address, one has
all the information one needs in order to form the encapsulation all the information one needs in order to form the encapsulation
header. This will be the case if the tunnel technology instantiating 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 the softwire is, e.g., LDP-based MPLS, IP-in-IP, or GRE without
optional header fields. optional header fields.
If the tunnel technology being used is L2TPv3 or GRE with optional If the tunnel technology being used is L2TPv3 or GRE with optional
header fields, additional information from the remote endpoint is header fields, additional information from the remote endpoint is
needed in order to form the encapsulation header. The procedures for needed in order to form the encapsulation header. The procedures for
sending and receiving this information are described in [ENCAPS- sending and receiving this information are described in [RFC5512].
SAFI].
If the tunnel technology being used is RSVP-TE-based MPLS or IPsec, If the tunnel technology being used is RSVP-TE-based MPLS or IPsec,
the native signaling procedures of those technologies will need to be the native signaling procedures of those technologies will need to be
used. used.
If the packet being sent through the softwire matches a route in the If the packet being sent through the softwire matches a route in the
labeled IPv4 or labeled IPv6 address families, it should be sent labeled IPv4 or labeled IPv6 address families, it should be sent
through the softwire as an MPLS packet with the corresponding label. through the softwire as an MPLS packet with the corresponding label.
Note that most of the tunneling technologies mentioned in this Note that most of the tunneling technologies mentioned in this
document are capable of carrying MPLS packets, so this does not document are capable of carrying MPLS packets, so this does not
presuppose support for MPLS in the core routers. presuppose support for MPLS in the core routers.
10. Softwire OAM and MIBs 10. Softwire OAM and MIBs
10.1. Operations and Maintenance (OAM) 10.1. Operations and Maintenance (OAM)
Softwires are essentially tunnels connecting routers. If they Softwires are essentially tunnels connecting routers. If they
disappear or degrade in performance then connectivity through those disappear or degrade in performance, then connectivity through those
tunnels will be impacted. There are several techniques available to tunnels will be impacted. There are several techniques available to
monitor the status of the tunnel end-points (AFBRs) as well as the monitor the status of the tunnel endpoints (AFBRs) as well as the
tunnels themselves. These techniques allow operations such as tunnels themselves. These techniques allow operations such as
softwires path tracing, remote softwire end-point pinging and remote softwire path tracing, remote softwire endpoint pinging, and remote
softwire end-point liveness failure detection. softwire endpoint liveness failure detection.
Examples of techniques applicable to softwire OAM include: Examples of techniques applicable to softwire OAM include:
o BGP/TCP timeouts between AFBRs o BGP/TCP timeouts between AFBRs
o ICMP or LSP echo request and reply addressed to a particular AFBR o ICMP or LSP echo request and reply addressed to a particular AFBR
o BFD (Bidirectional Forwarding Detection) [BFD] packet exchange o BFD (Bidirectional Forwarding Detection) [BFD] packet exchange
between AFBR routers between AFBR routers
Another possibility for softwire OAM is to build something similar to Another possibility for softwire OAM is to build something similar to
[RFC4378] or in other words creating and generating softwire echo [RFC4378] or, in other words, to create and generate softwire echo
request/reply packets. The echo request sent to a well-known UDP request/reply packets. The echo request sent to a well-known UDP
port would contain the egress AFBR IP address and the softwire port would contain the egress AFBR IP address and the softwire
identifier as the payload (similar to the MPLS forwarding equivalence identifier as the payload (similar to the MPLS Forwarding Equivalence
class contained in the LSP echo request). The softwire echo packet Class contained in the LSP echo request). The softwire echo packet
would be encapsulated with the encapsulation header and forwarded would be encapsulated with the encapsulation header and forwarded
across the same path (inband) as that of the softwire itself. across the same path (inband) as that of the softwire itself.
This mechanism can also be automated to periodically verify remote This mechanism can also be automated to periodically verify remote
softwires end-point reachability, with the loss of reachability being softwire endpoint reachability, with the loss of reachability being
signaled to the softwires application on the local AFBR thus enabling signaled to the softwire application on the local AFBR, thus enabling
suitable actions to be taken. Consideration must be given to the suitable actions to be taken. Consideration must be given to the
trade-offs between scalability of such mechanisms versus time to trade-offs between the scalability of such mechanisms versus the time
detection of loss of endpoint reachability for such automated required for detection of loss of endpoint reachability for such
mechanisms. automated mechanisms.
In general a framework for softwire OAM can for a large part be based In general, a framework for softwire OAM can, for a large part, be
on the [RFC4176] framework. based on the [RFC4176] framework.
10.2. MIBs 10.2. MIBs
Specific MIBs do exist to manage elements of the softwire mesh Specific MIBs do exist to manage elements of the Softwire Mesh
framework. However there will be a need to either extend these MIBs Framework. However, there will be a need to either extend these MIBs
or create new ones that reflect the functional elements that can be or create new ones that reflect the functional elements that can be
SNMP-managed within the softwire network. SNMP-managed within the softwire network.
11. Softwire Multicast 11. Softwire Multicast
A set of client networks, running E-IP, that are connected to a 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 provider's I-IP transit core may wish to run IP multicast
applications. Extending IP multicast connectivity across the transit applications. Extending IP multicast connectivity across the transit
core can be done in a number of ways, each with a different set of core can be done in a number of ways, each with a different set of
characteristics. Most (though not all) of the possibilities are characteristics. Most (though not all) of the possibilities are
either slight variations of the procedures defined for L3VPNs in either slight variations of the procedures defined for L3VPNs in
[L3VPN-MCAST]. [L3VPN-MCAST].
We will focus on supporting those multicast features and protocols We will focus on supporting those multicast features and protocols
which are typically used across inter-provider boundaries. Support that are typically used across inter-provider boundaries. Support is
is provided for PIM-SM (PIM Sparse Mode) and PIM-SSM (PIM Single provided for PIM-SM (Protocol Independent Multicast - Sparse Mode)
Source Mode). Support for BIDIR-PIM (Bidirectional PIM), BSR and PIM-SSM (PIM Source-Specific Mode). Support for BIDIR-PIM
(Bootstrap Router Mechanism for PIM), AutoRP (Automatic Rendezvous (Bidirectional PIM), BSR (Bootstrap Router Mechanism for PIM), and
Point Determination) is not provided as these features are not AutoRP (Automatic Rendezvous Point Determination) is not provided as
typically used across inter-provider boundaries. these features are not typically used across inter-provider
boundaries.
11.1. One-to-One Mappings 11.1. One-to-One Mappings
In the "one-to-one mapping" scheme, each client multicast tree is In the "one-to-one mapping" scheme, each client multicast tree is
extended through the transit core, so that for each client tree there extended through the transit core so that for each client tree there
is exactly one tree through the core. is exactly one tree through the core.
The one-to-one scheme is not used in [L3VPN-MCAST], because it 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 requires an amount of state in the core routers that is proportional
to the number of client multicast trees passing through the core. In to the number of client multicast trees passing through the core. In
the VPN context, this is considered undesirable, because the amount the VPN context, this is considered undesirable because the amount of
of state is unbounded and out of the control of the service provider. state is unbounded and out of the control of the service provider.
However, the one-to-one scheme models the typical "Internet However, the one-to-one scheme models the typical "Internet
multicast" scenario where the client network and the transit core are multicast" scenario where the client network and the transit core are
both IPv4 or are both IPv6. If it scales satisfactorily for that both IPv4 or both IPv6. If it scales satisfactorily for that case,
case, it should also scale satisfactorily for the case where the it should also scale satisfactorily for the case where the client
client network and the transit core support different versions of IP. network and the transit core support different versions of IP.
11.1.1. Using PIM in the Core 11.1.1. Using PIM in the Core
When an AFBR receives an E-IP PIM control message from one of its 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 CEs, it translates it from E-IP to I-IP, and forwards it towards the
the source of the tree. Since the routers in the transit core will source of the tree. Since the routers in the transit core will not
not generally have a route to the source of the tree, the AFBR must generally have a route to the source of the tree, the AFBR must
create include an "RPF (Reverse Path Forwarding) Vector" [RPF-VECTOR] include an "RPF (Reverse Path Forwarding) Vector" [RFC5496] in the
in the PIM message. PIM message.
Suppose an AFBR A receives an E-IP PIM Join/Prune message from a CE, 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 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 "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 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 (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 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. 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 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 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 AFBRs) do not have routes to E-IP addresses, A must put an RPF Vector
Vector" [RPF-VECTOR] in the PIM Join/Prune message that it sends to [RFC5496] in the PIM Join/Prune message that it sends to its upstream
its upstream neighbor. The RPF Vector will identify, as an I-IP neighbor. The RPF Vector will identify, as an I-IP address, the AFBR
address, the AFBR B that is the egress point in the transit network B that is the egress point in the transit network along the route to
along the route to the root of the multicast tree. AFBR B is AFBR the root of the multicast tree. AFBR B is AFBR A's BGP next hop for
A's "BGP next hop" for the route to the root of the tree. The RPF the route to the root of the tree. The RPF Vector allows the core
Vector allows the core routers to forward PIM Join/Prune messages routers to forward PIM Join/Prune messages upstream towards the root
upstream towards the root of the tree, even though they do not of the tree, even though they do not maintain E-IP routes.
maintain E-IP routes.
In order to "translate" the an E-IP PIM message into an I-IP PIM In order to translate an E-IP PIM message into an I-IP PIM message,
message, the AFBR A must translate the address of S (in the case of the AFBR A must translate the address of S (in the case of an (S,G)
an (S,G) group) or the address of G's RP from the E-IP address family group) or the address of G's RP from the E-IP address family to the
to the I-IP address family, and the AFBR B must translate them back. 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 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 to do this translation algorithmically. A can translate the IPv4 S
into the corresponding IPv4-mapped IPv6 address [RFC4291], and then B 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 can translate it back. At the time of this writing, there is no such
thing as an IPv4-mapped IPv6 multicast address, but if such a thing 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 were to be standardized, then A could also translate the IPv4 G into
IPv6, and B could translate it back. The precise circumstances under IPv6, and B could translate it back. The precise circumstances under
which these translations are to be done would be a matter of policy. which these translations are to be done would be a matter of policy.
Obviously, this translation procedure does not generalize to the case Obviously, this translation procedure does not generalize to the case
where the client multicast is IPv6 but the core is IPv4. To handle where the client multicast is IPv6 but the core is IPv4. To handle
that case, one needs additional signaling between the two AFBRs. that case, one needs additional signaling between the two AFBRs.
Each downstream AFBR need to signal the upstream AFBR that it needs a Each downstream AFBR needs to signal the upstream AFBR that it needs
multicast tunnel for (S,G). The upstream AFBR must then assign a 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 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 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 (S', G') tree, where S' is the IPv4 address of the upstream ASBR
(Autonomous System Border Router). (Autonomous System Border Router).
The (S', G') trees should be SSM trees. The (S', G') trees should be SSM trees.
This procedure can be used to support client multicasts of either This procedure can be used to support client multicasts of either
IPv4 or IPv6 over a transit core of the opposite protocol. However, IPv4 or IPv6 over a transit core of the opposite protocol. However,
it only works when the client multicasts are SSM, since it provides 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" 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 operation into an operation on the (S',G') tree. This method also
requires additional signaling. The BGP-based signaling of [L3VPN- requires additional signaling. The BGP-based signaling of
MCAST-BGP] is one signaling method that could be used. Other [L3VPN-MCAST-BGP] is one signaling method that could be used. Other
signaling methods could be defined as well. signaling methods could be defined as well.
11.1.2. Using mLDP and Multicast MPLS in the Core 11.1.2. Using mLDP and Multicast MPLS in the Core
If the transit core implements mLDP (LDP Extensions for Point-to- LDP extensions for point-to-multipoint and multipoint-to-multipoint
Multipoint and Multipoint-to-Multipoint LSPs, [mLDP]) and supports LSPs are specified in [MLDP]; we will use the term "mLDP" to refer to
multicast MPLS, then client Single-Source Multicast (SSM) trees can those LDP extensions. If the transit core implements mLDP and
be mapped one-to-one onto P2MP (Point-to-Multipoint) LSPs. 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 a E-IP PIM Join/Prune message for (S,G) from 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 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 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 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 identified by a combination of its root and an "FEC (Forwarding
Equivalence Class) identifier". The original (S,G) can be Equivalence Class) identifier". The original (S,G) can be
algorithmically encoded into the FEC identifier, so that all AFBRs 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 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 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, 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 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 CE that is its next hop on the route to S.
The method of encoding the (S,G) into the FEC identifier needs to be 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 standardized. The encoding must be self-identifying so that a node
which is the root of a P2MP LSP can determine whether a FEC that is the root of a P2MP LSP can determine whether a FEC identifier
identifier is the result of having encoded a PIM (S,G). is the result of having encoded a PIM (S,G).
The appropriate state machinery must be standardized so that PIM The appropriate state machinery must be standardized so that PIM
events at the AFBRs result in the proper mLDP events. For example, 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 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 longer has any downstream receivers for (S,G), the AFBR should invoke
the proper mLDP procedures to prune itself off the corresponding P2MP the proper mLDP procedures to prune itself off the corresponding P2MP
LSP. LSP.
Note that this method cannot be used when the G is a Sparse Mode 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 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 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 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 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 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 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. 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 It is recommended, though, that client SM multicast groups be
by other methods, such as those discussed below. supported by other methods, such as those discussed below.
Client-side bidirectional multicast groups set up by PIM-bidir could Client-side bidirectional multicast groups set up by PIM-bidir could
be mapped using the above technique to MP2MP (Multipoint-to- be mapped using the above technique to MP2MP (Multipoint-to-
Multipoint) LSPs set up by mLDP [MLDP]. We do not consider this Multipoint) LSPs set up by mLDP [MLDP]. We do not consider this
further as inter-provider bidirectional groups are not in use further, as inter-provider bidirectional groups are not in use
anywhere. anywhere.
11.2. MVPN-like Schemes 11.2. MVPN-Like Schemes
The "MVPN-like schemes" are those described in [L3VPN-MCAST] and its The "MVPN (Multicast VPN)-like schemes" are those described in
companion documents (such as [L3VPN-MCAST-BGP]). To apply those [L3VPN-MCAST] and its companion documents (such as
schemes to the softwire environment, it is necessary only to treat [L3VPN-MCAST-BGP]). To apply those schemes to the softwire
all the AFBRs of a given transit core as if they were all, for environment, it is necessary only to treat all the AFBRs of a given
multicast purposes, PE routers attached to the same VPN. 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 The MVPN-like schemes do not require a one-to-one mapping between
client multicast trees and transit core multicast trees. In the MVPN client multicast trees and transit-core multicast trees. In the MVPN
environment, it is a requirement that the number of trees in the core environment, it is a requirement that the number of trees in the core
scales less than linearly with the number of client trees. This scales less than linearly with the number of client trees. This
requirement may not hold in the softwires scenarios. requirement may not hold in the softwire scenarios.
The MVPN-like schemes can support SM, SSM, and Bidir groups. They The MVPN-like schemes can support SM, SSM, and Bidir groups. They
provide a number of options for the control plane: provide a number of options for the control plane:
- LAN-like - LAN-like
Use a set of multicast trees in the core to emulate a LAN (Local 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 Area Network) and run the client-side PIM protocol over that
"LAN". The "LAN" can consists of a single Bidir tree containing "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, all the AFBRs or a set of SSM trees, one rooted at each AFBR and
and containing all the other AFBRs as receivers. containing all the other AFBRs as receivers.
- NBMA (Non-Broadcast Multiple Access), using BGP - NBMA (Non-Broadcast Multiple Access), using BGP
The client-side PIM signaling can be "translated" into BGP-based The client-side PIM signaling can be translated into BGP-based
signaling, with a BGP route reflector mediating the signaling. signaling, with a BGP Route Reflector mediating the signaling.
These two basic options admit of many variations; a comprehensive These two basic options admit of many variations; a comprehensive
discussion is in [L3VPN-MCAST]. discussion is in [L3VPN-MCAST].
For the data plane, there are also a number of options: For the data plane, there are also a number of options:
- All multicast data sent over the emulated LAN. This particular - All multicast data sent over the emulated LAN. This particular
option is not very attractive though for the softwires scenarios, option is not very attractive, though, for the softwire
as every AFBR would have to receive every client multicast scenarios, as every AFBR would have to receive every client
packet. multicast packet.
- Every multicast group mapped to a tree which is considered - Every multicast group mapped to a tree that is considered
appropriate for that group, in the sense of causing the traffic 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 of that group to go to "too many" AFBRs that don't need to
receive it. receive it.
Again, a comprehensive discussion of the issues can be found in Again, a comprehensive discussion of the issues can be found in
[L3VPN-MCAST]. [L3VPN-MCAST].
12. Inter-AS Considerations 12. Inter-AS Considerations
We have so far only considered the case where a "transit core" 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 a single Autonomous System (AS). If the transit core
consists of multiple ASes, then it may be necessary to use softwires consists of multiple ASes, then it may be necessary to use softwires
whose endpoints are AFBRs attached to different Autonomous Systems. whose endpoints are AFBRs attached to different Autonomous Systems.
In this case, the AFBR at the remote endpoint of a softwire is not 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. the BGP next hop for packets that need to be sent on the softwire.
Since the procedures described above require the address of remote 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, 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 those procedures do not work as specified when the transit core
consists of multiple ASes. consists of multiple ASes.
There are several ways to deal with this situation. There are several ways to deal with this situation.
1. Don't do it; require that there be AFBRs at the edge of each 1. Don't do it; require that there be AFBRs at the edge of each AS
AS, so that a transit core does not extend more than one 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 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 other, even if the ABFRs are not in the same or in neighboring
ASes. ASes.
3. Ensure that an ASBR which is not an AFBR does not change the 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. next hop field of the routes for which encapsulation is needed.
In the latter two cases, BGP recursive next hop resolution needs to In the latter two cases, BGP recursive next hop resolution needs to
be done, and encapsulations may need to be "stacked" (i.e., multiple be done, and encapsulations may need to be "stacked" (i.e., multiple
layers of encapsulation may need to be used). layers of encapsulation may need to be used).
For instance, consider packet P with destination IP address D. For instance, consider packet P with destination IP address D.
Suppose it arrives at ingress AFBR A1, and that the route that is the 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 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 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 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 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, routes to B1, then A1 needs to encapsulate the packet a second time,
this time for delivery to B2. this time for delivery to B2.
13. IANA Considerations 13. Security Considerations
This document has no actions for IANA.
14. Security Considerations
14.1. Problem Analysis 13.1. Problem Analysis
In the Softwires mesh framework, the data packets that are In the Softwire Mesh Framework, the data packets that are
encapsulated are E-IP data packets that are traveling through the encapsulated are E-IP data packets that are traveling through the
Internet. These data packets (the Softwires "payload") may or may Internet. These data packets (the softwire "payload") may or may not
not need such security features as authentication, integrity, need such security features as authentication, integrity,
confidentiality, or replay protection. However, the security needs confidentiality, or replay protection. However, the security needs
of the payload packets are independent of whether or not those of the payload packets are independent of whether or not those
packets are traversing softwires. The fact that a particular payload packets are traversing softwires. The fact that a particular payload
packet is traveling through a softwire does not in any way affect its packet is traveling through a softwire does not in any way affect its
security needs. security needs.
Thus the only security issues we need to consider are those which Thus, the only security issues we need to consider are those that
affect the I-IP encapsulation headers, rather than those which affect affect the I-IP encapsulation headers, rather than those that affect
the E-IP payload. the E-IP payload.
Since the encapsulation headers determine the routing of packets Since the encapsulation headers determine the routing of packets
traveling through softwires, they must appear "in the clear". traveling through softwires, they must appear "in the clear".
In the Softwires mesh framework, for each tunnel receiving endpoint, In the Softwire Mesh Framework, for each receiving endpoint of a
there are one or more "valid" transmitting endpoints, where the valid tunnel, there are one or more "valid" transmitting endpoints, where
transmitting endpoints are those which are authorized to tunnel the valid transmitting endpoints are those that are authorized to
packets to the receiving endpoint. If the encapsulation header has tunnel packets to the receiving endpoint. If the encapsulation
no guarantee of authentication or integrity, then it is possible to header has no guarantee of authentication or integrity, then it is
have spoofing attacks, in which unauthorized nodes send encapsulated possible to have spoofing attacks, in which unauthorized nodes send
packets to the receiving endpoint, giving the receiving endpoint the encapsulated packets to the receiving endpoint, giving the receiving
invalid impression the encapsulated packets have really traveled endpoint the invalid impression the encapsulated packets have really
through the softwire. Replay attacks are also possible. traveled through the softwire. Replay attacks are also possible.
The effect of such attacks is somewhat limited though. The receiving The effect of such attacks is somewhat limited, though. The
endpoint of a softwire decapsulates the payload and does further receiving endpoint of a softwire decapsulates the payload and does
routing based on the IP destination address of the payload. Since further routing based on the IP destination address of the payload.
the payload packets are traveling through the Internet, they have Since the payload packets are traveling through the Internet, they
addresses from the globally unique address space (rather than, e.g., have addresses from the globally unique address space (rather than,
from a private address space of some sort). Therefore these attacks e.g., from a private address space of some sort). Therefore, these
cannot cause payload packets to be delivered to an address other than attacks cannot cause payload packets to be delivered to an address
the one appearing in the destination IP address field of the payload other than the one appearing in the destination IP address field of
packet. the payload packet.
However, attacks of this sort can result in policy violations. The However, attacks of this sort can result in policy violations. The
authorized transmitting endpoint(s) of a softwire may be following a authorized transmitting endpoint(s) of a softwire may be following a
policy according to which only certain payload packets get sent policy according to which only certain payload packets get sent
through the softwire. If unauthorized nodes are able to encapsulate through the softwire. If unauthorized nodes are able to encapsulate
the payload packets so that they arrive at the receiving endpoint the payload packets so that they arrive at the receiving endpoint
looking as if they arrived from authorized nodes, then the properly looking as if they arrived from authorized nodes, then the properly
authorized policies have been side-stepped. authorized policies have been side-stepped.
Attacks of the sort we are considering can also be used in Denial of Attacks of the sort we are considering can also be used in denial-
Service attacks on the receiving tunnel endpoints. However, such of-service attacks on the receiving tunnel endpoints. However, such
attacks cannot be prevented by use of cryptographic attacks cannot be prevented by use of cryptographic
authentication/integrity techniques, as the need to do cryptography authentication/integrity techniques, as the need to do cryptography
on spoofed packets only makes the Denial of Service problem worse. on spoofed packets only makes the denial-of-service problem worse.
(The assumption is that the cryptography mechanisms are likely to be (The assumption is that the cryptography mechanisms are likely to be
more costly than the decapsulation/forwarding mechanisms. So if one more costly than the decapsulation/forwarding mechanisms. So if one
tries to eliminate a flooding attack on the decapsulation/forwarding tries to eliminate a flooding attack on the decapsulation/forwarding
mechanisms by discarding packets that do not pass a cryptographic mechanisms by discarding packets that do not pass a cryptographic
integrity test, one ends up just trading one kind of attack for integrity test, one ends up just trading one kind of attack for
another.) another.)
This section is largely based on the security considerations section This section is largely based on the security considerations section
of RFC 4023, which also deals with encapsulations and tunnels. of RFC 4023, which also deals with encapsulations and tunnels.
14.2. Non-cryptographic techniques 13.2. Non-Cryptographic Techniques
If a tunnel lies entirely within a single administrative domain, then If a tunnel lies entirely within a single administrative domain,
to a certain extent, then there are certain non-cryptographic then, to a certain extent, there are certain non-cryptographic
techniques one can use to prevent spoofed packets from reaching a techniques one can use to prevent spoofed packets from reaching a
tunnel's receiving endpoint. For example, when the tunnel tunnel's receiving endpoint. For example, when the tunnel
encapsulation is IP-based: encapsulation is IP-based:
- The tunnel receiving endpoints can be given a distinct set of - The receiving endpoints of the tunnels can be given a distinct
addresses, and those addresses can be made known to the border set of addresses, and those addresses can be made known to the
routers. The border routers can then filter out packets, border routers. The border routers can then filter out packets,
destined to those addresses, which arrive from outside the destined to those addresses, that arrive from outside the domain.
domain.
- The tunnel transmitting endpoints can be given a distinct set of - The transmitting endpoints of the tunnels can be given a distinct
addresses, and those addresses can be made known to the border set of addresses, and those addresses can be made known to the
routers and to the tunnel receiving endpoints. The border routers border routers and to the receiving endpoints of the tunnels.
can filter out all packets arriving from outside the domain with The border routers can filter out all packets arriving from
source addresses that are in this set, and the receiving outside the domain with source addresses that are in this set,
endpoints can discard all packets which appear to be part of a and the receiving endpoints can discard all packets that appear
softwire, but whose source addresses are not in this set. 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 If an MPLS-based encapsulation is used, the border routers can refuse
to accept MPLS packets from outside the domain, or can refuse to to accept MPLS packets from outside the domain, or they can refuse to
accept such MPLS packets whenever the top label corresponds to the accept such MPLS packets whenever the top label corresponds to the
address of a tunnel receiving endpoint. address of a tunnel receiving endpoint.
These techniques assume that within a domain, the network is secure These techniques assume that, within a domain, the network is secure
enough to prevent the introduction of spoofed packets from within the enough to prevent the introduction of spoofed packets from within the
domain itself. That may not always be the case. Also, these domain itself. That may not always be the case. Also, these
techniques however can be difficult or impossible to use effectively techniques can be difficult or impossible to use effectively for
for tunnels that are not in the same administrative domain. tunnels that are not in the same administrative domain.
A different technique is to have the encapsulation header contain a A different technique is to have the encapsulation header contain a
cleartext password. The 64-bit "cookie" of L2TPv3 [RFC3931] is cleartext password. The 64-bit "cookie" of L2TPv3 [RFC3931] is
sometimes used in this way. This can be useful within an sometimes used in this way. This can be useful within an
administrative domain if it is regarded as infeasible for an attacker 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 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 the domain. An attacker would then not be able to discover the
password. An attacker could of course try to guess the password, but password. An attacker could, of course, try to guess the password,
if the password is an arbitrary 64-bit binary sequence, brute force but if the password is an arbitrary 64-bit binary sequence, brute
attacks which run through all the possible passwords would be force attacks that run through all the possible passwords would be
infeasible. This technique may be easier to manage than ingress infeasible. This technique may be easier to manage than ingress
filtering is, and may be just as effective if the assumptions hold. filtering is, and may be just as effective if the assumptions hold.
Like ingress filtering, though, it may not be applicable for tunnels Like ingress filtering, though, it may not be applicable for tunnels
that cross domain boundaries. that cross domain boundaries.
Therefore it is necessary to also consider the use of cryptographic Therefore, it is necessary to also consider the use of cryptographic
techniques for setting up the tunnels and for passing data through techniques for setting up the tunnels and for passing data through
them. them.
14.3. Cryptographic techniques 13.3. Cryptographic Techniques
If the path between the two endpoints of a tunnel is not adequately If the path between the two endpoints of a tunnel is not adequately
secure, then secure, then:
- If a control protocol is used to set up the tunnels (e.g., to - 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 inform one tunnel endpoint of the IP address of the other), the
control protocol MUST have an authentication mechanism, and this control protocol MUST have an authentication mechanism, and this
MUST be used when the tunnel is set up. If the tunnel is set up MUST be used when the tunnel is set up. If the tunnel is set up
automatically as the result of, for example, information automatically as the result of, for example, information
distributed by BGP, then the use of BGP's MD5-based distributed by BGP, then the use of BGP's MD5-based
authentication mechanism [RFC2385] is satisfactory. authentication mechanism [RFC2385] is satisfactory.
- Data transmission through the tunnel should be secured with - Data transmission through the tunnel should be secured with
IPsec. In the remainder of this section, we specify the way IPsec. In the remainder of this section, we specify the way
IPsec may be used, and the implementation requirements we mention IPsec may be used, and the implementation requirements we mention
are meant to be applicable whenever IPsec is being used. are meant to be applicable whenever IPsec is being used.
We consider only the case where IPsec is used together with an IP- We consider only the case where IPsec is used together with an IP-
based tunneling mechanism. Use of IPsec with an MPLS-based tunneling based tunneling mechanism. Use of IPsec with an MPLS-based tunneling
mechanism is for further study. mechanism is for further study.
If it is deemed necessary to use tunnels that are protected by IPsec, 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 tunnel type SHOULD be negotiated by the tunnel endpoints using
the procedures specified in [ENCAPS-IPSEC]. That document allows the the procedures specified in [RFC5566]. That document allows the use
use of IPsec tunnel mode, but also allows one to treat the tunnel of IPsec tunnel mode but also allows one to treat the tunnel head and
head and the tunnel tail as the endpoints of a Security Association, the tunnel tail as the endpoints of a Security Association, and to
and to use IPsec transport mode. use IPsec transport mode.
In order to use IPsec transport mode, encapsulated packets should be In order to use IPsec transport mode, encapsulated packets should be
viewed as originating at the tunnel head and as being destined for 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 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 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 will be used as the destination IP address. This technique can be
used to to carry MPLS packets through an IPsec Security Association, used to carry MPLS packets through an IPsec Security Association, by
but first encapsulating the MPLS packets in MPLS-in-IP or MPLS-in-GRE first encapsulating the MPLS packets in MPLS-in-IP or MPLS-in-GRE
[RFC4023] and then applying IPsec transport mode. [RFC4023] and then applying IPsec transport mode.
When IPsec is used to secure softwires, IPsec MUST provide When IPsec is used to secure softwires, IPsec MUST provide
authentication and integrity. Thus, the implementation MUST support authentication and integrity. Thus, the implementation MUST support
either ESP (IP Encapsulating Security Payload) with null encryption either ESP (IP Encapsulating Security Payload) with null encryption
[RFC4303] or else AH (IP Authentication Header) [RFC4302]. ESP with [RFC4303] or else AH (IP Authentication Header) [RFC4302]. ESP with
encryption MAY be supported. If ESP is used, the tunnel tail MUST 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 check that the source IP address of any packet received on a given SA
(IPsec Security Association) is the one expected, as specified in (IPsec Security Association) is the one expected, as specified in
[RFC4301] section 5.2 step 4. Section 5.2, step 4, of [RFC4301].
Since the softwires are set up dynamically as a byproduct of passing Since the softwires are set up dynamically as a byproduct of passing
routing information, key distribution MUST be done automatically by routing information, key distribution MUST be done automatically by
means of IKEv2 [RFC4306]. If a PKI (Public Key Infrastructure) is means of IKEv2 [RFC4306]. If a PKI (Public Key Infrastructure) is
not available, the IPsec Tunnel Authenticator sub-TLV described in not available, the IPsec Tunnel Authenticator sub-TLV described in
[ENCAPS-IPSEC] MUST be used and validated before setting up an SA. [RFC5566] MUST be used and validated before setting up an SA.
The selectors associated with the SA are the source and destination The selectors associated with the SA are the source and destination
addresses of the encapsulation header, along with the IP protocol addresses of the encapsulation header, along with the IP protocol
number representing the encapsulation protocol being used. number representing the encapsulation protocol being used.
14. References
14.1. Normative References
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC
2784, March 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)",
RFC 3931, March 2005.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing
Encapsulation (GRE)", RFC 4023, March 2005.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the
BGP Tunnel Encapsulation Attribute", RFC 5512, April
2009.
[RFC5566] Berger, L., White, R. and E. Rosen, "BGP IPsec Tunnel
Encapsulation Attribute", RFC 5566, June 2009.
[V4NLRI-V6NH] Le Faucheur, F. and E. Rosen, "Advertising IPv4
Network Layer Reachability Information with an IPv6
Next Hop", RFC 5549, May 2009.
[V6NLRI-V4NH] De Clercq, J., Ooms, D., Prevost, S., and F. Le
Faucheur, "Connecting IPv6 Islands over IPv4 MPLS
Using IPv6 Provider Edge Routers (6PE)", RFC 4798,
February 2007.
14.2. Informative References
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", Work in Progress, February 2009.
[L3VPN-MCAST] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
MPLS/BGP IP VPNs", Work in Progress, March 2009.
[L3VPN-MCAST-BGP]
Aggarwal, R., Rosen, E., Morin, T. and Y. Rekhter,
"BGP Encodings and Procedures for Multicast in
MPLS/BGP IP VPNs", Work in Progress, April 2009.
[MLDP] Minei, I., Ed., Kompella, K., Wijnands, IJ., Ed., and
B. Thomas, "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths", Work in Progress, April 2009.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP
and dual environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan,
K., and A. Gonguet, "Framework for Layer 3 Virtual
Private Networks (L3VPN) Operations and Management",
RFC 4176, October 2005.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
2006.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for
Multi-Protocol Label Switching (MPLS) Operations and
Management (OAM)", RFC 4378, February 2006.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-
the-Network Tunneling", RFC 4459, April 2006.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas,
Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse
Path Forwarding (RPF) Vector TLV", RFC 5496, March
2009.
[SW-PROB] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A.
Durand, Ed., "Softwire Problem Statement", RFC 4925,
July 2007.
15. Contributors 15. Contributors
Xing Li Xing Li
Tsinghua University Tsinghua University
Department of Electronic Engineering, Tsinghua University Department of Electronic Engineering, Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.China
Phone: +86-10-6278-5983 Phone: +86-10-6278-5983
Email: xing@cernet.edu.cn EMail: xing@cernet.edu.cn
Simon Barber Simon Barber
Cisco Systems, Inc. Cisco Systems, Inc.
250 Longwater Avenue 250 Longwater Avenue
Reading, ENGLAND, RG2 6GB Reading, ENGLAND, RG2 6GB
United Kingdom United Kingdom
Email: sbarber@cisco.com EMail: sbarber@cisco.com
Pradosh Mohapatra Pradosh Mohapatra
Cisco Systems, Inc. Cisco Systems, Inc.
3700 Cisco Way 3700 Cisco Way
San Jose, Ca. 95134 San Jose, CA 95134
USA USA
Email: pmohapat@cisco.com EMail: pmohapat@cisco.com
John Scudder John Scudder
Juniper Networks Juniper Networks
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, California 94089 Sunnyvale, CA 94089
USA USA
Email: jgs@juniper.net EMail: jgs@juniper.net
16. Acknowledgments 16. Acknowledgments
David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta, David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta,
Mingwei Xu and Ke Xu provided useful input into this document. Mingwei Xu, and Ke Xu provided useful input into this document.
Authors' Addresses Authors' Addresses
Jianping Wu Jianping Wu
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.China
Phone: +86-10-6278-5983 Phone: +86-10-6278-5983
Email: jianping@cernet.edu.cn EMail: jianping@cernet.edu.cn
Yong Cui Yong Cui
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing 100084 Beijing 100084
P.R.China P.R.China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: yong@csnet1.cs.tsinghua.edu.cn EMail: yong@csnet1.cs.tsinghua.edu.cn
Chris Metz Chris Metz
Cisco Systems, Inc. Cisco Systems, Inc.
3700 Cisco Way 3700 Cisco Way
San Jose, Ca. 95134 San Jose, CA 95134
USA USA
Email: chmetz@cisco.com EMail: chmetz@cisco.com
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA, 01719 Boxborough, MA 01719
USA USA
Email: erosen@cisco.com EMail: erosen@cisco.com
17. Normative References
[ENCAPS-IPSEC] "BGP IPSec Tunnel Encapsulation Attribute", L. Berger,
R. White, E. Rosen, draft-ietf-softwire-encaps-ipsec-01.txt, April
2008.
[ENCAPS-SAFI] "BGP Information SAFI and BGP Tunnel Encapsulation
Attribute", P. Mohapatra and E. Rosen, draft-ietf-softwire-encaps-
safi-05.txt, February 2009.
[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-02.txt,
January 2009.
[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.
18. Informative References
[BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-09.txt, February 2009.
[L3VPN-MCAST], "Multicast in MPLS/BGP IP VPNs", E. Rosen, R.
Aggarwal, 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-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-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] Y. Rekhter, T. Li, S. Hares, "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
2005.
[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] E. Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006.
[RFC4378] D. Allan, T. Nadeau, "A Framework for Multi-Protocol Label
Switching (MPLS) Operations and Management (OAM)", RFC 4378, February
2006.
[RFC4459] P. Savola, "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006.
[RFC5036] "LDP Specification", L. Andersson, I. Minei, B. Thomas, RFC
5036, October 2007.
[RPF-VECTOR], "The RPF Vector TLV", IJ. Wijnands, A. Boers, E. Rosen,
draft-ietf-pim-rpf-vector-08.txt, January 2009.
[SW-PROB] X. Li, S. Dawkins, D. Ward, A. Durand, "Softwire Problem
Statement", RFC 4925, July 2007.
 End of changes. 155 change blocks. 
399 lines changed or deleted 500 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/