draft-ietf-softwire-mesh-framework-05.txt   draft-ietf-softwire-mesh-framework-06.txt 
Network Working Group J. Wu Network Working Group J. Wu
Internet Draft Y. Cui Internet Draft Y. Cui
Intended Status: Standards Track X. Li Intended Status: Standards Track Tsinghua University
Expires: March 18, 2009 Tsinghua University Expires: August 16, 2009
C. Metz C. Metz
E. Rosen (Editor) E. Rosen
S. Barber
P. Mohapatra
Cisco Systems, Inc. Cisco Systems, Inc.
J. Scudder February 16, 2009
Juniper Networks, Inc.
September 18, 2008
Softwire Mesh Framework Softwire Mesh Framework
draft-ietf-softwire-mesh-framework-05.txt draft-ietf-softwire-mesh-framework-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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
skipping to change at page 3, line 35 skipping to change at page 3, line 35
11.1 One-to-One Mappings ................................... 20 11.1 One-to-One Mappings ................................... 20
11.1.1 Using PIM in the Core ................................. 20 11.1.1 Using PIM in the Core ................................. 20
11.1.2 Using mLDP and Multicast MPLS in the Core ............. 21 11.1.2 Using mLDP and Multicast MPLS in the Core ............. 21
11.2 MVPN-like Schemes ..................................... 22 11.2 MVPN-like Schemes ..................................... 22
12 Inter-AS Considerations ............................... 23 12 Inter-AS Considerations ............................... 23
13 IANA Considerations ................................... 24 13 IANA Considerations ................................... 24
14 Security Considerations ............................... 24 14 Security Considerations ............................... 24
14.1 Problem Analysis ...................................... 24 14.1 Problem Analysis ...................................... 24
14.2 Non-cryptographic techniques .......................... 26 14.2 Non-cryptographic techniques .......................... 26
14.3 Cryptographic techniques .............................. 27 14.3 Cryptographic techniques .............................. 27
15 Acknowledgments ....................................... 28 15 Contributors .......................................... 28
16 Normative References .................................. 28 16 Acknowledgments ....................................... 29
17 Informative References ................................ 29 17 Normative References .................................. 30
18 Full Copyright Statement .............................. 32 18 Informative References ................................ 31
19 Intellectual Property ................................. 33
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 12, line 29 skipping to change at page 12, line 29
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
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
encapsulation header be added to the original packet. The resulting
packet is therefore always longer than the encapsulation payload. As
an operational matter, the Maximum Transmission Unit (MTU) of the
softwire's path SHOULD be large enough so that (a) no packet will
need to be fragmented before being encapsulated, and (b) no
encapsulated packet will need to be fragmented while it is being
forwarded along a softwire. A general discussion of MTU issues in
the context of tunneled forwarding may be found in [RFC4459].
5. Distribution of Inter-AFBR Routing Information 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.
skipping to change at page 14, line 17 skipping to change at page 14, line 27
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 than 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 IPv4 do the same for the IPv4 address family, i.e., to use the labeled
address family instead of the IPv4 address family. The use of the IPv4 address family instead of the IPv4 address family. The use of
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 is
not considered part of this framework. not considered part of this framework.
skipping to change at page 16, line 15 skipping to change at page 16, line 16
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, 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 packets 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 packets through a softwire
- if the route which is the best match for a particular packet's - if the route which is the best match for a particular packet's
skipping to change at page 18, line 45 skipping to change at page 18, line 48
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
the [RFC4378] or in other words creating and generating softwire echo [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.
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 softwires end-point reachability, with the loss of reachability being
signaled to the softwires application on the local AFBR thus enabling signaled to the softwires 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 verses time to trade-offs between scalability of such mechanisms versus time to
detection of loss of endpoint reachability for such automated detection of loss of endpoint reachability for such automated
mechanisms. 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 based
on the [RFC4176] framework. 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
skipping to change at page 21, line 10 skipping to change at page 21, line 10
A's "BGP next hop" for the route to the root of the tree. The RPF 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 Vector allows the core routers to forward PIM Join/Prune messages
upstream towards the root of the tree, even though they do not upstream towards the root 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" 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 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 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. 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 In the case where E-IP is IPv4 and I-IP is IPv6, it may be possible
this translation algorithmically. A can translate the IPv4 S and G to do this translation algorithmically. A can translate the IPv4 S
into the corresponding IPv4-mapped IPv6 addresses [RFC4291], and then into the corresponding IPv4-mapped IPv6 address [RFC4291], and then B
B can translate them back. The precise circumstances under which can translate it back. At the time of this writing, there is no such
these translations are done would be a matter of policy. thing as an IPv4-mapped IPv6 multicast address, but if such a thing
were to be standardized, then A could also translate the IPv4 G into
IPv6, and B could translate it back. The precise circumstances under
which these translations are to be done would be a matter of policy.
Obviously, this translation procedure does not generalize to the case 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 need to signal the upstream AFBR that it needs a
multicast tunnel for (S,G). The upstream AFBR must then assign 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).
skipping to change at page 23, line 8 skipping to change at page 23, line 11
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 softwires 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 consists 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 containing all the other AFBRs as receivers. and 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
skipping to change at page 24, line 18 skipping to change at page 24, line 21
AS, so that a transit core does not extend more than one AS. 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 which 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. be done, and encapsulations may need to be "stacked" (i.e., multiple
layers of encapsulation may need to be used).
For instance, consider packet P with destination IP address D. 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.
skipping to change at page 24, line 41 skipping to change at page 24, line 45
This document has no actions for IANA. This document has no actions for IANA.
14. Security Considerations 14. Security Considerations
14.1. Problem Analysis 14.1. Problem Analysis
In the Softwires mesh framework, the data packets that are In the Softwires 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 Softwires "payload") may or may
not need such security features as authentication, integrity, not need such security features as authentication, integrity,
confidentiality, or playback 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 which
affect the I-IP encapsulation headers, rather than those which affect affect the I-IP encapsulation headers, rather than those which 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", i.e., traveling through softwires, they must appear "in the clear".
they do not have any confidentiality requirement.
In the Softwires mesh framework, for each tunnel receiving endpoint, In the Softwires mesh framework, for each tunnel receiving endpoint,
there are one or more "valid" transmitting endpoints, where the valid there are one or more "valid" transmitting endpoints, where the valid
transmitting endpoints are those which are authorized to tunnel transmitting endpoints are those which are authorized to tunnel
packets to the receiving endpoint. If the encapsulation header has packets to the receiving endpoint. If the encapsulation header has
no guarantee of authentication or integrity, then it is possible to no guarantee of authentication or integrity, then it is possible to
have spoofing attacks, in which unauthorized nodes send encapsulated have spoofing attacks, in which unauthorized nodes send encapsulated
packets to the receiving endpoint, giving the receiving endpoint the packets to the receiving endpoint, giving the receiving endpoint the
invalid impression the encapsulated packets have really traveled invalid impression the encapsulated packets have really traveled
through the softwire. Replay attacks are also possible. 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 receiving
endpoint of a softwire decapsulates the payload and does further endpoint of a softwire decapsulates the payload and does further
routing based on the IP destination address of the payload. Since routing based on the IP destination address of the payload. Since
the payload packets are traveling through the Internet, they have the payload packets are traveling through the Internet, they have
addresses from the globally unique address space (rather than, e.g., addresses from the globally unique address space (rather than, e.g.,
from a private address space of some sort). Therefore these attacks from a private address space of some sort). Therefore these attacks
cannot cause payload packets to be delivered to an address other than cannot cause payload packets to be delivered to an address other than
the one intended. the one appearing in the destination IP address field of 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 of
Service attacks on the receiving tunnel endpoints. However, such 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
more costly than the decapsulation/forwarding mechanisms. So if one
tries to eliminate a flooding attack on the decapsulation/forwarding
mechanisms by discarding packets that do not pass a cryptographic
integrity test, one ends up just trading one kind of attack for
another.)
This section is largely based on the security considerations section 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 14.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, then
to a certain extent, then there are certain non-cryptographic to a certain extent, then 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
skipping to change at page 28, line 9 skipping to change at page 28, line 12
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. [RFC4301] section 5.2 step 4.
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], operating in main mode with preshared keys. means of IKEv2 [RFC4306]. If a PKI (Public Key Infrastructure) is
If a PKI (Public Key Infrastructure) is not available, the IPsec not available, the IPsec Tunnel Authenticator sub-TLV described in
Tunnel Authenticator sub-TLV described in [ENCAPS-IPSEC] MUST be used [ENCAPS-IPSEC] MUST be used and validated before setting up an SA.
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.
15. Acknowledgments 15. Contributors
Xing Li
Tsinghua University
Department of Electronic Engineering, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: xing@cernet.edu.cn
Simon Barber
Cisco Systems, Inc.
250 Longwater Avenue
Reading, ENGLAND, RG2 6GB
United Kingdom
Email: sbarber@cisco.com
Pradosh Mohapatra
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
USA
Email: pmohapat@cisco.com
John Scudder
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
Email: jgs@juniper.net
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.
16. Normative References Authors' Addresses
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: jianping@cernet.edu.cn
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: yong@csnet1.cs.tsinghua.edu.cn
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
USA
Email: chmetz@cisco.com
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
USA
Email: erosen@cisco.com
17. Normative References
[ENCAPS-IPSEC] "BGP IPSec Tunnel Encapsulation Attribute", L. Berger, [ENCAPS-IPSEC] "BGP IPSec Tunnel Encapsulation Attribute", L. Berger,
R. White, E. Rosen, draft-ietf-softwire-encaps-ipsec-01.txt, April R. White, E. Rosen, draft-ietf-softwire-encaps-ipsec-01.txt, April
2008. 2008.
[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-ietf-softwire-encaps- Attribute", P. Mohapatra and E. Rosen, draft-ietf-softwire-encaps-
safi-03.txt, June 2008. safi-05.txt, February 2009.
[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 29, line 13 skipping to change at page 30, line 48
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001. December 2001.
[RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling [RFC3931] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC4023] "Encapsulating MPLS in IP or Generic Routing Encapsulation [RFC4023] "Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", T. Worster, Y. Rekhter, E. Rosen, RFC 4023, March 2005. (GRE)", T. Worster, Y. Rekhter, E. Rosen, RFC 4023, 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-softwire-v4nlri-v6nh-01.txt, April with an IPv6 Next Hop", draft-ietf-softwire-v4nlri-v6nh-02.txt,
2008. January 2009.
[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.
17. Informative References 18. Informative References
[BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection", [BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-08.txt, March 2008. draft-ietf-bfd-base-09.txt, February 2009.
[L3VPN-MCAST], "Multicast in MPLS/BGP IP VPNs", E. Rosen, R. [L3VPN-MCAST], "Multicast in MPLS/BGP IP VPNs", E. Rosen, R.
Aggarwal, draft-ietf-l3vpn-2547bis-mcast-07.txt, July 2008. Aggarwal, draft-ietf-l3vpn-2547bis-mcast-07.txt, July 2008.
[L3VPN-MCAST-BGP], "BGP Encodings and Procedures for Multicast in [L3VPN-MCAST-BGP], "BGP Encodings and Procedures for Multicast in
MPLS/BGP IP VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C. MPLS/BGP IP VPNs", R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, C.
Kodeboniya, draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt, June 2008. Kodeboniya, draft-ietf-l3vpn-2547bis-mcast-bgp-05.txt, June 2008.
[MLDP] "Label Distribution Protocol Extensions for Point-to- [MLDP] "Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched Paths", I. Multipoint and Multipoint-to-Multipoint Label Switched Paths", I.
skipping to change at page 29, line 49 skipping to change at page 31, line 38
[RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998. [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April 1998.
[RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature [RFC2385] "Protection of BGP Sessions via the TCP MD5 Signature
Option", A. Heffernan, RFC 2385, August 1998. Option", A. Heffernan, RFC 2385, August 1998.
[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] Y. Rekhter, T. Li, S. Hares, "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. [RFC4291] "IP Version 6 Addressing Architecture", R. Hinden, S.
Deering, RFC 4291, February 2006. Deering, RFC 4291, February 2006.
[RFC4301], "Security Architecture for the Internet Protocol", S. [RFC4301], "Security Architecture for the Internet Protocol", S.
Kent, K. Seo, RFC 4301, December 2005. Kent, K. Seo, RFC 4301, December 2005.
[RFC4302] "IP Authentication Header", S. Kent, RFC 4302, December [RFC4302] "IP Authentication Header", S. Kent, RFC 4302, December
2005. 2005.
[RFC4303] "IP Encapsulating Security Payload (ESP)", S. Kent, RFC [RFC4303] "IP Encapsulating Security Payload (ESP)", S. Kent, RFC
4303, December 2005. 4303, December 2005.
[RFC4306] "Internet Key Exchange (IKEv2) Protocol", C. Kaufman, ed., [RFC4306] "Internet Key Exchange (IKEv2) Protocol", C. Kaufman, ed.,
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] E. Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
Networks (VPNs)", RFC 4364, February 2006. (VPNs)", RFC 4364, February 2006.
[RFC4378] D. Allan and T. Nadeau, "A Framework for Multi-Protocol [RFC4378] D. Allan, T. Nadeau, "A Framework for Multi-Protocol Label
Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, Switching (MPLS) Operations and Management (OAM)", RFC 4378, February
February 2006. 2006.
[RFC5036] "LDP Specification", L. Andersson, I. Minei, B. Thomas, [RFC4459] P. Savola, "MTU and Fragmentation Issues with In-the-
October 2007. 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, [RPF-VECTOR], "The RPF Vector TLV", IJ. Wijnands, A. Boers, E. Rosen,
draft-ietf-pim-rpf-vector-06.txt, February 2008. draft-ietf-pim-rpf-vector-08.txt, January 2009.
[SW-PROB] X. Li, S. Dawkins, D. Ward, A. Durand, "Softwire Problem [SW-PROB] X. Li, S. Dawkins, D. Ward, A. Durand, "Softwire Problem
Statement", RFC 4925, July 2007. Statement", RFC 4925, July 2007.
Authors' Addresses
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: jianping@cernet.edu.cn
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: yong@csnet1.cs.tsinghua.edu.cn
Xing Li
Tsinghua University
Department of Electronic Engineering, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: xing@cernet.edu.cn
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
USA
Email: chmetz@cisco.com
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
USA
Email: erosen@cisco.com
Simon Barber
Cisco Systems, Inc.
250 Longwater Avenue
Reading, ENGLAND, RG2 6GB
United Kingdom
Email: sbarber@cisco.com
Pradosh Mohapatra
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
USA
Email: pmohapat@cisco.com
John Scudder
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
Email: jgs@juniper.net
18. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
19. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
 End of changes. 32 change blocks. 
57 lines changed or deleted 162 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/