draft-ietf-softwire-mesh-framework-00.txt   draft-ietf-softwire-mesh-framework-01.txt 
Network Working Group J. Wu Network Working Group J. Wu
Internet Draft Y. Cui Internet Draft Y. Cui
Expiration Date: September 2007 X. Li Expiration Date: December 2007 X. Li
Tsinghua University Tsinghua University
C. Metz C. Metz
E. Rosen (Editor) E. Rosen (Editor)
S. Barber S. Barber
P. Mohapatra P. Mohapatra
Cisco Systems, Inc. Cisco Systems, Inc.
J. Scudder J. Scudder
Juniper Networks, Inc. Juniper Networks, Inc.
Softwire Mesh Framework Softwire Mesh Framework
draft-ietf-softwire-mesh-framework-00.txt draft-ietf-softwire-mesh-framework-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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 ...................... 3 1 Specification of requirements ......................... 2
2 Introduction ....................................... 4 2 Introduction .......................................... 2
3 Scenarios of Interest .............................. 7 3 Scenarios of Interest ................................. 5
3.1 IPv6-over-IPv4 Scenario ............................ 7 3.1 IPv6-over-IPv4 Scenario ............................... 5
3.2 IPv4-over-IPv6 Scenario ............................ 9 3.2 IPv4-over-IPv6 Scenario ............................... 7
4 General Principles of the Solution ................. 11 4 General Principles of the Solution .................... 8
4.1 'E-IP' and 'I-IP' .................................. 11 4.1 'E-IP' and 'I-IP' ..................................... 8
4.2 Routing ............................................ 12 4.2 Routing ............................................... 8
4.3 Tunneled Forwarding ................................ 12 4.3 Tunneled Forwarding ................................... 8
5 Distribution of Inter-AFBR Routing Information ..... 12 5 Distribution of Inter-AFBR Routing Information ........ 9
6 Softwire Signaling ................................. 14 6 Softwire Signaling .................................... 10
7 Choosing to Forward Through a Softwire ............. 16 7 Choosing to Forward Through a Softwire ................ 11
8 Selecting a Tunneling Technology ................... 16 8 Selecting a Tunneling Technology ...................... 11
9 Selecting the Softwire for a Given Packet .......... 17 9 Selecting the Softwire for a Given Packet ............. 12
10 Softwire OAM and MIBs .............................. 18 10 Softwire OAM and MIBs ................................. 13
10.1 Operations and Maintenance (OAM) ................... 18 10.1 Operations and Maintenance (OAM) ...................... 13
10.2 MIBs ............................................... 19 10.2 MIBs .................................................. 13
11 Softwire Multicast ................................. 19 11 Softwire Multicast .................................... 13
12 Inter-AS Considerations ............................ 20 11.1 One-to-One Mappings ................................... 14
13 Security Considerations ............................ 21 11.1.1 Using PIM in the Core ................................. 14
14 Acknowledgments .................................... 21 11.1.2 Using mLDP and Multicast MPLS in the Core ............. 15
15 Normative References ............................... 21 11.2 MVPN-like Schemes ..................................... 15
16 Informative References ............................. 22 12 Inter-AS Considerations ............................... 16
17 Full Copyright Statement ........................... 25 13 IANA Considerations ................................... 17
18 Intellectual Property .............................. 25 14 Security Considerations ............................... 17
14.1 Problem Analysis ...................................... 17
14.2 Non-cryptographic techniques .......................... 18
14.3 Cryptographic techniques .............................. 18
15 Acknowledgments ....................................... 19
16 Normative References .................................. 19
17 Informative References ................................ 20
18 Full Copyright Statement .............................. 22
19 Intellectual Property ................................. 23
1. Specification of requirements 1. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. 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
skipping to change at page 5, line 27 skipping to change at page 5, line 34
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
the external routing information. the external routing information.
In recent years, we have seen this scenario deployed to support VPN In recent years, we have seen this scenario deployed to support VPN
services, as specified in [RFC4364]. An edge router maintains services, as specified in [RFC4364]. An edge router maintains
multiple independent routing/addressing spaces, one for each VPN to multiple independent routing/addressing spaces, one for each VPN to
which it interfaces. However, the routing information for the VPNs which it interfaces. However, the routing information for the VPNs
is not maintained by the interior routers. In most of these is not maintained by the interior routers. In most of these
scenarios, MPLS is used as the encapsulation mechanism for getting scenarios, MPLS is used as the encapsulation mechanism for getting
the packets from ingress to egress. There are some deployments in the packets from ingress to egress. There are some deployments in
which an IP-based encapsulation, such as L2TPv3 [RFC3931] or GRE which an IP-based encapsulation, such as L2TPv3 (Layer 2 Transport
[RFC2784] is used. Protocol) [RFC3931] or GRE (Generic Routing Encapsulation) [RFC2784]
is used.
This same technique can also be useful when the external routing This same technique can also be useful when the external routing
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.
skipping to change at page 6, line 24 skipping to change at page 6, line 30
as the "Softwire Mesh Framework". In this framework, only the AFBRs as the "Softwire Mesh Framework". In this framework, only the AFBRs
need to support both address families. The CE routers support only a need to support both address families. The CE routers support only a
single address family, and the P routers support only the other single address family, and the P routers support only the other
address family. 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 ([RFC3036]) and RSVP-TE-based ([RFC3209]), L2TPv3 LDP-based (Label Distribution Protocol, [RFC3036]) and RSVP-TE-based
[RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003]. The framework will ([RFC3209]), L2TPv3 [RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003].
also accommodate the use of IPsec tunneling, when that is necessary The framework will also accommodate the use of IPsec tunneling, when
in order to meet security requirements. 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
skipping to change at page 8, line 46 skipping to change at page 8, line 46
| / \ | | / \ |
| / \ | | / \ |
+--------+ +--------+ +--------+ +--------+
| 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 While Figure 1 does not show any "backdoor" connections among the client
client networks, this framework assumes that there will be such networks, this framework assumes that there will be such connections.
connections. That is, there is no assumption that the only path
between two client networks is via the pictured transit core network. That is, there is no assumption that the only path between two client
Hence the routing solution must be robust in any kind of topology. 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, tunneling mechanisms have been used, some provisioned manually, others
others based on special addressing. More recently, L3VPN techniques based on special addressing. More recently, L3VPN (Layer 3 Virtual
from [RFC4364] have been extended to provide IPv6 connectivity, using Private Network) techniques from [RFC4364] have been extended to provide
MPLS in the AFBRs and optionally in the backbone [V6NLRI-V4NH]. The IPv6 connectivity, using MPLS in the AFBRs and optionally in the
solution described in this framework can be thought of as a superset backbone [V6NLRI-V4NH]. The solution described in this framework can be
of [V6NLRI-V4NH], with a more generalized scheme for choosing the thought of as a superset of [V6NLRI-V4NH], with a more generalized
tunneling (softwire) technology. In this framework, MPLS is allowed, scheme for choosing the tunneling (softwire) technology. In this
but not required, even at the AFBRs. As in [V6NLRI-V4NH], there is framework, MPLS is allowed, but not required, even at the AFBRs. As in
no manual provisioning of tunnels, and no special addressing is [V6NLRI-V4NH], there is no manual provisioning of tunnels, and no
required. 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 46 skipping to change at page 10, line 46
| / \ | | / \ |
| / \ | | / \ |
+--------+ +--------+ +--------+ +--------+
| 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 The IPv6 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 2 does not show any "backdoor" connections among the While Figure 2 does not show any "backdoor" connections among the client
client networks, this framework assumes that there will be such networks, this framework assumes that there will be such connections.
connections. That is, there is no assumption the only path between
two client networks is via the pictured transit core network. Hence
the routing solution must be robust in any kind of topology.
While the issue of IPv6-over-IPv4 has received considerable attention That is, there is no assumption the only path between two client
in the past, the scenario of IPv4-over-IPv6 has not. Yet it is a networks is via the pictured transit core network. Hence the routing
significant emerging requirement, as a number of service providers solution must be robust in any kind of topology.
are building IPv6 backbone networks and do not wish to provide native
IPv4 support in their core routers. These service providers have a While the issue of IPv6-over-IPv4 has received considerable attention in
large legacy of IPv4 networks and applications that need to operate the past, the scenario of IPv4-over-IPv6 has not. Yet it is a
across their IPv6 backbone. Solutions for this do not exist yet significant emerging requirement, as a number of service providers are
because it had always been assumed that the backbone networks of the building IPv6 backbone networks and do not wish to provide native IPv4
foreseeable future would be dual stack. support in their core routers. These service providers have a large
legacy of IPv4 networks and applications that need to operate across
their IPv6 backbone. Solutions for this do not exist yet because it had
always been assumed that the backbone networks of the foreseeable future
would be dual stack.
4. General Principles of the Solution 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 we use the term "I-IP" ("Internal IP") to refer to
the form of IP (i.e., either IPv4 or IPv6) that is supported by the the form of IP (i.e., either IPv4 or IPv6) that is supported by the
skipping to change at page 11, line 39 skipping to change at page 11, line 39
the form of IP that is supported by the client networks. In the the form of IP that is supported by the client networks. In the
scenarios of interest, E-IP is IPv4 if and only if I-IP is IPv6, and scenarios of interest, E-IP is IPv4 if and only if I-IP is IPv6, and
E-IP is IPv6 if and only if I-IP is IPv4. 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 AFBR's "core facing interfaces", and E-IP is only used on its client-
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 IBGP to exchange E-IP routing information with each
other. Either there is a full mesh of IBGP connections among the other. Either there is a full mesh of IBGP connections among the
AFBRs, or else some or all of the AFBRs are clients of a BGP Route AFBRs, or else some or all of the AFBRs are clients of a BGP Route
Reflector. Although these IBGP connections are used to pass E-IP Reflector. Although these IBGP connections are used to pass E-IP
routing information (i.e., the NLRI of the BGP updates is in the E-IP routing information (i.e., the NLRI of the BGP updates is in the E-IP
address family), the IBGP connections run over I-IP, and the "BGP 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. 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 scenarios of interest, the best match for that address will be a BGP-
BGP-distributed route whose next hop is the I-IP address of another distributed route whose next hop is the I-IP address of another AFBR,
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 which the P
routers can process, and which will cause the P routers to send the routers can process, and which 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
skipping to change at page 14, line 32 skipping to change at page 14, line 24
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 IPv4 do the same for the IPv4 address family, i.e. to use the labeled IPv4
address family instead of the IPv4 address family. The use of the address family instead of the IPv4 address family. The use of the
labeled IP address families in this manner is OPTIONAL. 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 place before packets can flow between client networks. Given N dual-
dual-stack AFBRs, this requires N^2 "point-to-point IP" or "label stack AFBRs, this requires N^2 "point-to-point IP" or "label switched
switched path" (LSP) tunnels. While in theory these could be path" (LSP) tunnels. While in theory these could be configured
configured manually, that would result in a very undesirable O(N^2) manually, that would result in a very undesirable O(N^2) provisioning
provisioning problem. Therefore manual configuration of point-to- problem. Therefore manual configuration of point-to-point tunnels is
point tunnels is not considered part of this framework. 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-to-point tunnels are all that is needed. In a multipoint-
multipoint-to-point tunnel, when a packet emerges from the tunnel to-point tunnel, when a packet emerges from the tunnel there is no
there is no way to tell which router put the packet into the tunnel. way to tell which router put the packet into the tunnel. This models
This models the native IP forwarding paradigm, wherein the egress the native IP forwarding paradigm, wherein the egress router cannot
router cannot determine a given packet's ingress router. Of course, determine a given packet's ingress router. Of course, point-to-point
point-to-point tunnels might be required for some reason which goes tunnels might be required for some reason which goes beyond the basic
beyond the basic requirements described in this document. E.g., QoS requirements described in this document. E.g., QoS or security
or security considerations might require the use of point-to-point considerations might require the use of point-to-point tunnels. So
tunnels. So point-to-point tunnels are allowed, but not required, by point-to-point tunnels are allowed, but not required, by this
this framework. 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. A softwire based on IPsec would use
standard IKE/IPsec signaling, as that is necessary in order to standard IKE (Internet Key Exchange) [RFC4306] and IPsec [RFC4301]
guarantee the softwire's security properties. signaling, as that is necessary in order to guarantee the softwire's
security properties.
A Softwire based on GRE might or might not require signaling, A Softwire based on GRE might or might not require signaling,
depending on whether various optional GRE header fields are to be depending on whether various optional GRE header fields are to be
used. GRE does not have any "native" signaling, so for those cases, used. GRE does not have any "native" signaling, so for those cases,
a signaling procedure needs to be developed to support Softwires. a signaling 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
skipping to change at page 15, line 36 skipping to change at page 15, line 29
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 field, the DSCP bits, etc. of such fields may be the TTL (Time to Live) field, the DSCP
(DiffServ Service Classes) bits, etc.
It is desirable for all necessary softwires to be fully set up before 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 which 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 which the AFBR has installed. This suggests that any
necessary softwire signaling should be either be done as part of necessary softwire signaling should be either be done as part of
normal system startup (as would happen, e.g., with LDP-based MPLS), normal system startup (as would happen, e.g., with LDP-based MPLS),
or else should be triggered by the reception of BGP routing or else should be triggered by the reception of BGP routing
information (such as is described in [ENCAPS-SAFI]); it is also information (such as is described in [ENCAPS-SAFI]); it is also
skipping to change at page 18, line 46 skipping to change at page 18, line 46
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 softwires path tracing, remote softwire end-point pinging and remote
softwire end-point liveness failure detection. softwire end-point 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] packet exchange between AFBR routers o BFD (Bidirectional Forwarding Detection) [BFD] packet exchange
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
the [RFC4378] or in other words creating and generating softwire echo the [RFC4378] or in other words creating and generating 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.
skipping to change at page 19, line 34 skipping to change at page 19, line 35
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. Among them are: characteristics. Most (though not all) of the possibilities are
either slight variations of the procedures defined for L3VPNs in
[L3VPN-MCAST].
- Extend each client multicast tree through the transit core, so We will focus on supporting those multicast features and protocols
that for each client tree there is exactly one tree through the which are typically used across inter-provider boundaries. Support
core. is provided for PIM-SM (PIM Sparse Mode) and PIM-SSM (PIM Single
Source Mode). Support for BIDIR-PIM (Bidirectional PIM), BSR
(Bootstrap Router Mechanism for PIM), AutoRP (Automatic Rendezvous
Point Determination) is not provided as these features are not
typically used across inter-provider boundaries.
- Use one multicast tree in the core, add all the AFBRs to it, make 11.1. One-to-One Mappings
it look to the client multicast control protocols as if the
transit network is a LAN over which they can run transparently.
- Use more than one multicast tree in the core, but less than one In the "one-to-one mapping" scheme, each client multicast tree is
per client tree, and perform some kind of aggregation of client extended through the transit core, so that for each client tree there
trees to core trees. is exactly one tree through the core.
- Don't use any multicast trees in the core, have the ingress AFBRs The one-to-one scheme is not used in [L3VPN-MCAST], because it
replicate the multicast traffic and then unicast each replica. requires an amount of state in the core routers which is proportional
to the number of client multicast trees passing through the core. In
the VPN context, this is considered undesirable, because the amount
of state is unbounded and out of the control of the service provider.
However, the one-to-one scheme models the typical "Internet
multicast" scenario where the client network and the transit core are
both IPv4 or are both IPv6. If it scales satisfactorily for that
case, it should also scale satisfactorily for the case where the
client network and the transit core support different versions of IP.
This list does not exhaust the set of alternatives. There are also 11.1.1. Using PIM in the Core
additional issues which are somewhat orthogonal, such as whether it
is best for the transit core and the clients to be using the same
multicast control protocols or not, what multicast control protocols
and service models need to be supported, etc.
All these issues will be considered more fully in a subsequent When an AFBR receives an E-IP PIM control message from one of its
revision of this document. CEs, it would translate it from E-IP to I-IP, and forward it towards
the source of the tree. Since the routers in the transit core will
not generally have a route to the source of the tree, the AFBR must
create include an "RPF Vector" in the PIM message.
Suppose an AFBR A receives an E-IP PIM Join/Prune message from a CE,
for either an (S,G) tree or a (*,G) tree. The AFBR would have to
"translate" the PIM message into an I-IP PIM message. It would then
send it to the neighbor which is the next hop along the route to the
root of the (S,G) or (*,G) tree. In the case of an (S,G) tree the
root of the tree is S; in the case of a (*,G) tree the root of the
tree is the Rendezvous Point (RP) for the group G.
Note that the address of the root of the tree will be an E-IP
address. Since the routers within the transit core (other than the
AFBRs) do not have routes to E-IP addresses, A must put an "RPF
Vector" [RPF-VECTOR] in the PIM Join/Prune message that it sends to
its upstream neighbor. The RPF Vector will identify, as an I-IP
address, the AFBR B that is the egress point in the transit network
along the route to the root of the multicast tree. AFBR B is AFBR
A's "BGP next hop" for the route to the root of the tree. The RPF
Vector allows the core routers to forward PIM Join/Prune messages
upstream towards the root of the tree, even though they do not
maintain E-IP routes.
In order to "translate" the an E-IP PIM message into an I-IP PIM
message, the AFBR A must translate the address of S (in the case of
an (S,G) group) or the address of G's RP from the E-IP address family
to the I-IP address family, and the AFBR B must translate them back.
In the case where E-IP is IPv4 and I-IP is IPv6, it is possible to do
this translation algorithmically. A can translate the IPv4 S and G
into the corresponding IPv4-mapped IPv6 addresses [RFC4291], and then
B can translate them back. The precise circumstances under which
these translations are done would be a matter of policy.
Obviously, this translation procedure does not generalize to the case
where the client multicast is IPv6 but the core is IPv4. To handle
that case, one needs additional signaling between the two AFBRs.
Each downstream AFBR need to signal the upstream AFBR that it needs a
multicast tunnel for (S,G). The upstream AFBR must then assign a
multicast address G' to the tunnel, and inform the downstream of the
P-G value to use. The downstream AFBR then uses PIM/IPv4 to join the
(S', G') tree, where S' is the IPv4 address of the upstream ASBR
(Autonomous System Border Router).
The (S', G') trees should be SSM trees.
This procedure can be used to support client multicasts of either
IPv4 or IPv6 over a transit core of the opposite protocol. However,
it only works when the client multicasts are SSM, since it provides
no method for mapping a client "prune a source off the (*,G) tree"
operation into an operation on the (S',G') tree. This method also
requires additional signaling. The BGP-based signaling of [L3VPN-
MCAST-BGP] is one signaling method that could be used. Other
signaling methods could be defined as well.
11.1.2. Using mLDP and Multicast MPLS in the Core
If the transit core implements mLDP [mLDP] and supports multicast
MPLS, then client Single-Source Multicast (SSM) trees can be mapped
one-to-one onto P2MP LSPs.
When an AFBR A receives a E-IP PIM Join/Prune message for (S,G) from
one of its CEs, where G is an SSM group it would use mLDP to join a
P2MP LSP. The root of the P2MP LSP would be the AFBR B that is A's
BGP next hop on the route to S. In mLDP, a P2MP LSP is uniquely
identified by a combination of its root and a "FEC (Forwarding
Equivalence Class) identifier". The original (S,G) can be
algorithmically encoded into the FEC identifier, so that all AFBRs
that need to join the P2MP LSP for (S,G) will generate the same FEC
identifier. When the root of the P2MP LSP (AFBR B) receives such an
mLDP message, it extracts the original (S,G) from the FEC identifier,
creates an "ordinary" E-IP PIM Join/Prune message, and sends it to
the CE which is its next hop on the route to S.
The method of encoding the (S,G) into the FEC identifier needs to be
standardized. The encoding must be self-identifying, so that a node
which is the root of a P2MP LSP can determine whether a FEC
identifier is the result of having encoded a PIM (S,G).
The appropriate state machinery must be standardized so that PIM
events at the AFBRs result in the proper mLDP events. For example,
if at some point an AFBR determines (via PIM procedures) that it no
longer has any downstream receivers for (S,G), the AFBR should invoke
the proper mLDP procedures to prune itself off the corresponding P2MP
LSP.
Note that this method cannot be used when the G is a Sparse Mode
group. The reason this method cannot be used is that mLDP does not
have any function corresponding to the PIM "prune this source off the
shared tree" function. So if a P2MP LSP were mapped one-to-one with
a P2MP LSP, duplicate traffic could end up traversing the transit
core (i.e., traffic from S might travel down both the shared tree and
S's source tree). Alternatively, one could devise an AFBR-to-AFBR
protocol to prune sources off the P2MP LSP at the root of the LSP.
It is recommended though that client SM multicast groups be supported
by other methods, such as those discussed below.
Client-side bidirectional multicast groups set up by PIM-bidir could
be mapped using the above technique to MP2MP (Multipoint-to-
Multipoint) LSPs set up by mLDP [MLDP]. We do not consider this
further as inter-provider bidirectional groups are not in use
anywhere.
11.2. MVPN-like Schemes
The "MVPN-like schemes" are those described in [L3VPN-MCAST] and its
companion documents (such as [L3VPN-MCAST-BGP]). To apply those
schemes to the softwire environment, it is necessary only to treat
all the AFBRs of a given transit core as if they were all, for
multicast purposes, PE routers attached to the same VPN.
The MVPN-like schemes do not require a one-to-one mapping between
client multicast trees and transit core multicast trees. In the MVPN
environment, it is a requirement that the number of trees in the core
scales less than linearly with the number of client trees. This
requirement may not hold in the softwires scenarios.
The MVPN-like schemes can support SM, SSM, and Bidir groups. They
provide a number of options for the control plane:
- Lan-Like
Use a set of multicast trees in the core to emulate a LAN (Local
Area Network), and run the client-side PIM protocol over that
"LAN". The "LAN" can consists of a single Bidir tree containing
all the AFBRs, or a set of SSM trees, one rooted at each AFBR,
and containing all the other AFBRs as receivers.
- NBMA (Non-Broadcast Multiple Access), using BGP
The client-side PIM signaling can be "translated" into BGP-based
signaling, with a BGP route reflector mediating the signaling.
These two basic options admit of many variations; a comprehensive
discussion is in [L3VPN-MCAST].
For the data plane, there are also a number of options:
- All multicast data sent over the emulated LAN. This particular
option is not very attractive though for the softwires scenarios,
as every AFBR would have to receive every client multicast
packet.
- Every multicast group mapped to a tree which is considered
appropriate for that group, in the sense of causing the traffic
of that group to go to "too many" AFBRs that don't need to
receive it.
Again, a comprehensive discussion of the issues can be found in
[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 remote
skipping to change at page 21, line 5 skipping to change at page 24, line 17
2. Specify a new BGP attribute that allows an AFBR to identify 2. Specify a new BGP attribute that allows an AFBR to identify
itself without using the NH field. This "next AFBR" attribute itself without using the NH field. This "next AFBR" attribute
would be passed unchanged by non-AFBRs, but each AFBR would be passed unchanged by non-AFBRs, but each AFBR
disseminating a given routing update would replace any existing disseminating a given routing update would replace any existing
"next AFBR" attribute by its own address. When an ingress AFBR "next AFBR" attribute by its own address. When an ingress AFBR
is choosing a softwire to send a packet through, if a "next is choosing a softwire to send a packet through, if a "next
AFBR" attribute is present, it would use that rather than the AFBR" attribute is present, it would use that rather than the
next hop to help it choose the proper softwire. next hop to help it choose the proper softwire.
13. Security Considerations 13. IANA Considerations
Security for softwire signaling can be achieved using BGP/TCP MD5- This document has no actions for IANA.
keying. The softwire data plane can employ encryption of the data
packets using Ipsec. This will be explained in a companion document.
[RFC4111] outlines the L3VPN security framework which in many cases 14. Security Considerations
is directly applicable to the softwire mesh framework.
14. Acknowledgments 14.1. Problem Analysis
In the Softwires mesh framework, the data packets that are
encapsulated are E-IP data packets that are traveling through the
Internet. These data packets (the Softwires "payload") may or may
not need such security features as authentication, integrity,
confidentiality, or playback protection. However, the security needs
of the payload packets are independent of whether or not those
packets are traversing softwires. The fact that a particular payload
packet is traveling through a softwire does not in any way affect its
security needs.
Thus the only security issues we need to consider are those which
affect the I-IP encapsulation headers, rather than those which affect
the E-IP payload.
Since the encapsulation headers determine the routing of packets
traveling through softwires, they must appear "in the clear", i.e.,
they do not have any confidentiality requirement.
In the Softwires mesh framework, for each tunnel receiving endpoint,
there are one or more "valid" transmitting endpoints, where the valid
transmitting endpoints are those which are authorized to tunnel
packets to the receiving endpoint. If the encapsulation header has
no guarantee of authentication or integrity, then it is possible to
have spoofing attacks, in which unauthorized nodes send encapsulated
packets to the receiving endpoint, giving the receiving endpoint the
invalid impression the encapsulated packets have really traveled
through the softwire. Replay attacks are also possible.
The effect of such attacks is somewhat limited though. The receiving
endpoint of a softwire decapsulates the payload and does further
routing based on the IP destination address of the payload. Since
the payload packets are traveling through the Internet, they have
addresses from the globally unique address space (rather than, e.g.,
from a private address space of some sort). Therefore these attacks
cannot cause payload packets to be delivered to an address other than
the one intended.
However, attacks of this sort can result in policy violations. The
authorized transmitting endpoint(s) of a softwire may be following a
policy according to which only certain payload packets get sent
through the softwire. If unauthorized nodes are able to encapsulate
the payload packets so that they arrive at the receiving endpoint
looking as if they arrived from authorized nodes, then the properly
authorized policies have been side-stepped.
Attacks of the sort we are considering can also be used in Denial of
Service attacks on the receiving tunnel endpoints. However, such
attacks cannot be prevented by use of cryptographic
authentication/integrity techniques, as the need to do cryptography
on spoofed packets only makes the Denial of Service problem worse.
This section is largely based on the security considerations section
of RFC 4023, which also deals with encapsulations and tunnels.
14.2. Non-cryptographic techniques
If a tunnel lies entirely within a single administrative domain, then
to a certain extent, then there are certain non-cryptographic
techniques one can use to prevent spoofed packets from reaching a
tunnel's receiving endpoint. For example, when the tunnel
encapsulation is IP-based:
- The tunnel receiving endpoints can be given a distinct set of
addresses, and those addresses can be made known to the border
routers. The border routers can then filter out packets,
destined to those addresses, which arrive from outside the
domain.
- The tunnel transmitting endpoints can be given a distinct set of
addresses, and those addresses can be made know to the border
routers and to the tunnel receiving endpoints. The border routers
can filter out all packets arriving from outside the domain with
source addresses that are in this set, and the receiving
endpoints can discard all packets which appear to be part of a
softwire, but whose source addresses are not in this set.
If an MPLS-based encapsulation is used, the border routers can refuse
to accept MPLS packets from outside the domain, or can refused to
accept such MPLS packets whenever the top label corresponds to the
address of a tunnel receiving endpoint.
These techniques assume that within a domain, the network is secure
enough to prevent the introduction of spoofed packets from within the
domain itself. That may not always be the case. Also, these
techniques however can be difficult or impossible to use effectively
for tunnels that are not in the same administrative domain.
A different technique is to have the encapsulation header contain a
cleartext password. The 64-bit "cookie" of L2TPv3 [RFC3931] is
sometimes used in this way. This can be useful within an
administrative domain if it is regarded as infeasible for an attacker
to spy on packets that originate in the domain and that do not leave
the domain. An attacker would then not be able to discover the
password. An attacker could of course try to guess the password, but
if the password is an arbitrary 64-bit binary sequence, brute force
attacks which run through all the possible passwords would be
infeasible. This technique may be easier to manage than ingress
filtering is, and may be just as effective if the assumptions hold.
Like ingress filtering, though, it may not be applicable for tunnels
that cross domain boundaries.
Therefore it is necessary to consider the use of more cryptographic
techniques for setting up the tunnels and for passing data through
them.
14.3. Cryptographic techniques
If the path between the two endpoints of a tunnel is not adequately
secure, then
- If a control protocol is used to set up the tunnels (e.g., to
inform one tunnel endpoint of the IP address of the other), the
control protocol MUST have an authentication mechanism, and this
MUST be used when the tunnel is set up. If the tunnel is set up
automatically as the result of, for example, information
distributed by BGP, then the use of BGP's MD5-based
authentication mechanism [RFC2385] is satisfactory.
- Data transmission through the tunnel should be secured with
IPsec. In the remainder of this section, we specify the way
IPsec may be used, and the implementation requirements we mention
are meant to be applicable whenever IPsec is being used.
We consider only the case where IPsec is used together with an IP-
based tunneling mechanism. Use of IPsec with an MPLS-based tunneling
mechanism is for further study. In the case where the encapsulation
being used is MPLS-in-IP or MPLS-in-GRE, please see RFC 4023 for the
details.
When IPsec is used, the tunnel head and the tunnel tail should be
treated as the endpoints of a Security Association. For this
purpose, a single IP address of the tunnel head will be used as the
source IP address, and a single IP address of the tunnel tail will be
used as the destination IP address.
The encapsulated packets should be viewed as originating at the
tunnel head and as being destined for the tunnel tail; IPsec
transport mode SHOULD thus be used.
The IP header of the encapsulated packet becomes the outer IP header
of the resulting packet. That IP header is followed by an IPsec
header, which in turn is followed by the payload.
When IPsec is used to secure softwires, IPsec MUST provide
authentication and integrity. Thus, the implementation MUST support
ESP (IP Encapsulating Security Payload) will null encryption
[RFC4303]. ESP with encryption MAY be supported. If ESP is used,
the tunnel tail MUST check that the source IP address of any packet
received on a given SA is the one expected.
Since the softwires are set up dynamically as a byproduct of passing
routing information, key distribution MUST be done automatically by
means of IKE [RFC4306], operating in main mode with preshared keys.
The selectors associated with the SA are the source and destination
addresses of the encapsulation header, along with the IP protocol
number representing the encapsulation protocol being used.
It should be noted that the implementation of IPsec with automatic
keying is generally not considered to be an attractive option. The
combination of cryptography with encapsulation/decapsulation at high
speeds is rarely offered by vendors, and the management overhead of
supporting an automated keying infrastructure is rarely desired by
service providers.
15. 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.
15. Normative References 16. Normative References
[ENCAPS-SAFI] "BGP Information SAFI and BGP Tunnel Encapsulation [ENCAPS-SAFI] "BGP Information SAFI and BGP Tunnel Encapsulation
Attribute", P. Mohapatra and E. Rosen, draft-pmohapat-idr-info-safi- Attribute", P. Mohapatra and E. Rosen, draft-pmohapat-idr-info-
01.txt, February 2007. safi-01.txt, February 2007.
[RFC2003] "IP Encapsulation within IP", C. Perkins, October 1996. [RFC2003] "IP Encapsulation within IP", C. Perkins, October 1996.
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
S. Bradner, March 1997. S. Bradner, March 1997.
[RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li, [RFC2784] "Generic Routing Encapsulation (GRE)", D. Farinacci, T. Li,
S. Hanks, D. Meyer, P. Traina, RFC 2784, March 2000. S. Hanks, D. Meyer, P. Traina, RFC 2784, March 2000.
[RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A. [RFC3031] "Multiprotocol Label Switching Architecture", E. Rosen, A.
skipping to change at page 22, line 10 skipping to change at page 29, line 5
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[V4NLRI-V6NH] F. Le Faucheur, E. Rosen, "Advertising an IPv4 NLRI [V4NLRI-V6NH] F. Le Faucheur, E. Rosen, "Advertising an IPv4 NLRI
with an IPv6 Next Hop", draft-ietf-idr-v4nlri-v6nh-00.txt, October with an IPv6 Next Hop", draft-ietf-idr-v4nlri-v6nh-00.txt, October
2006. 2006.
[V6NLRI-V4NH] J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur, [V6NLRI-V4NH] J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge
Routers (6PE)", RFC 4798, February 2007. Routers (6PE)", RFC 4798, February 2007.
16. Informative References 17. Informative References
[RFC1195] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual [BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection",
Environments", RFC 1195, December 1990. draft-ietf-bfd-base-06.txt, March 2007.
[L3VPN-MCAST], "Multicast in MPLS/BGP IP VPNs", E. Rosen, R.
Aggarwal, draft-ietf-l3vpn-2547bis-mcast-04.txt, October 2006.
[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-02.txt, March 2007.
[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-02, June 2006.
[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.
[RFC3036] "LDP Specification", L. Andersson, P. Doolan, N. Feldman, [RFC3036] "LDP Specification", L. Andersson, P. Doolan, N. Feldman,
A. Fredette, B. Thomas, January 2001. A. Fredette, B. Thomas, January 2001.
[RFC4111] L. Fang, "Security Framework for Provider-Provisioned
Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4176] Y. El Mghazli, T. Nadeau, M. Boucadair, K. Chan, A. [RFC4176] Y. El Mghazli, T. Nadeau, M. Boucadair, K. Chan, A.
Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN)
Operations and Management", RFC 4176, October 2005. Operations and Management", RFC 4176, October 2005.
[RFC4271] Rekhter, Y,, Li T., Hares, S., "A Border Gateway Protocol 4 [RFC4271] Rekhter, Y,, Li T., Hares, S., "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006. (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.
[RFC4303] "IP Encapsulating Security Payload (ESP)", S. Kent, RFC
4303, December 2005.
[RFC4306] "Internet Key Exchange (IKEv2) Protocol", C. Kaufman, ed.,
RFC 4306, December 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4378] D. Allan and T. Nadeau, "A Framework for Multi-Protocol [RFC4378] D. Allan and T. Nadeau, "A Framework for Multi-Protocol
Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, Label Switching (MPLS) Operations and Management (OAM)", RFC 4378,
February 2006. February 2006.
[BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection", [RPF-VECTOR], "The RPF Vector TLV", IJ. Wijnands, draft-ietf-pim-rpf-
draft-ietf-bfd-base-06.txt, March 2007.. vector-03.txt, October 2006.
[SW-PROB] X. Li, "Softwire Problem Statement", draft-ietf-softwire- [SW-PROB] X. Li, "Softwire Problem Statement", draft-ietf-softwire-
problem-statement-03.txt, March 2007. problem-statement-03.txt, March 2007.
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
skipping to change at page 25, line 5 skipping to change at page 32, line 5
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, California 94089
USA USA
Email: jgs@juniper.net Email: jgs@juniper.net
17. Full Copyright Statement 18. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
18. Intellectual Property 19. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 39 change blocks. 
130 lines changed or deleted 497 lines changed or added

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