draft-ietf-softwire-mesh-framework-03.txt   draft-ietf-softwire-mesh-framework-04.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 X. Li
Expires: July 14, 2008 Tsinghua University Expires: September 31, 2008 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.
January 14, 2008 March 31, 2008
Softwire Mesh Framework Softwire Mesh Framework
draft-ietf-softwire-mesh-framework-03.txt draft-ietf-softwire-mesh-framework-04.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 33 skipping to change at page 3, line 33
10.2 MIBs .................................................. 19 10.2 MIBs .................................................. 19
11 Softwire Multicast .................................... 19 11 Softwire Multicast .................................... 19
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 .......................... 25 14.2 Non-cryptographic techniques .......................... 26
14.3 Cryptographic techniques .............................. 27 14.3 Cryptographic techniques .............................. 27
15 Acknowledgments ....................................... 28 15 Acknowledgments ....................................... 28
16 Normative References .................................. 28 16 Normative References .................................. 28
17 Informative References ................................ 29 17 Informative References ................................ 29
18 Full Copyright Statement .............................. 32 18 Full Copyright Statement .............................. 32
19 Intellectual Property ................................. 32 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 20, line 28 skipping to change at page 20, line 28
both IPv4 or are both IPv6. If it scales satisfactorily for that both IPv4 or are both IPv6. If it scales satisfactorily for that
case, it should also scale satisfactorily for the case where the case, it should also scale satisfactorily for the case where the
client network and the transit core support different versions of IP. client network and the transit core support different versions of IP.
11.1.1. Using PIM in the Core 11.1.1. Using PIM in the Core
When an AFBR receives an E-IP PIM control message from one of its When an AFBR receives an E-IP PIM control message from one of its
CEs, it would translate it from E-IP to I-IP, and forward it towards CEs, it 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 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 not generally have a route to the source of the tree, the AFBR must
create include an "RPF Vector" in the PIM message. create include an "RPF (Reverse Path Forwarding) Vector" [RPF-VECTOR]
in the PIM message.
Suppose an AFBR A receives an E-IP PIM Join/Prune message from a CE, Suppose an AFBR A receives an E-IP PIM Join/Prune message from a CE,
for either an (S,G) tree or a (*,G) tree. The AFBR would have to for either an (S,G) tree or a (*,G) tree. The AFBR would have to
"translate" the PIM message into an I-IP PIM message. It would then "translate" the PIM message into an I-IP PIM message. It would then
send it to the neighbor which is the next hop along the route to the send it to the neighbor 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 (S,G) or (*,G) tree. In the case of an (S,G) tree the
root of the tree is S; in the case of a (*,G) tree the root of the root of the tree is S; in the case of a (*,G) tree the root of the
tree is the Rendezvous Point (RP) for the group G. tree is the Rendezvous Point (RP) for the group G.
Note that the address of the root of the tree will be an E-IP Note that the address of the root of the tree will be an E-IP
skipping to change at page 21, line 37 skipping to change at page 21, line 39
IPv4 or IPv6 over a transit core of the opposite protocol. However, IPv4 or IPv6 over a transit core of the opposite protocol. However,
it only works when the client multicasts are SSM, since it provides it only works when the client multicasts are SSM, since it provides
no method for mapping a client "prune a source off the (*,G) tree" no method for mapping a client "prune a source off the (*,G) tree"
operation into an operation on the (S',G') tree. This method also operation into an operation on the (S',G') tree. This method also
requires additional signaling. The BGP-based signaling of [L3VPN- requires additional signaling. The BGP-based signaling of [L3VPN-
MCAST-BGP] is one signaling method that could be used. Other MCAST-BGP] is one signaling method that could be used. Other
signaling methods could be defined as well. signaling methods could be defined as well.
11.1.2. Using mLDP and Multicast MPLS in the Core 11.1.2. Using mLDP and Multicast MPLS in the Core
If the transit core implements mLDP [mLDP] and supports multicast If the transit core implements mLDP (LDP Extensions for Point-to-
MPLS, then client Single-Source Multicast (SSM) trees can be mapped Multipoint and Multipoint-to-Multipoint LSPs, [mLDP]) and supports
one-to-one onto P2MP LSPs. multicast MPLS, then client Single-Source Multicast (SSM) trees can
be mapped one-to-one onto P2MP (Point-to-Multipoint) LSPs.
When an AFBR A receives a E-IP PIM Join/Prune message for (S,G) from 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 one of its CEs, where G is an SSM group it would use mLDP to join a
P2MP LSP. The root of the P2MP LSP would be the AFBR B that is A's P2MP LSP. The root of the P2MP LSP would be the AFBR B that is A's
BGP next hop on the route to S. In mLDP, a P2MP LSP is uniquely BGP next hop on the route to S. In mLDP, a P2MP LSP is uniquely
identified by a combination of its root and a "FEC (Forwarding identified by a combination of its root and a "FEC (Forwarding
Equivalence Class) identifier". The original (S,G) can be Equivalence Class) identifier". The original (S,G) can be
algorithmically encoded into the FEC identifier, so that all AFBRs algorithmically encoded into the FEC identifier, so that all AFBRs
that need to join the P2MP LSP for (S,G) will generate the same FEC that need to join the P2MP LSP for (S,G) will generate the same FEC
identifier. When the root of the P2MP LSP (AFBR B) receives such an identifier. When the root of the P2MP LSP (AFBR B) receives such an
skipping to change at page 27, line 25 skipping to change at page 27, line 27
distributed by BGP, then the use of BGP's MD5-based distributed by BGP, then the use of BGP's MD5-based
authentication mechanism [RFC2385] is satisfactory. authentication mechanism [RFC2385] is satisfactory.
- Data transmission through the tunnel should be secured with - Data transmission through the tunnel should be secured with
IPsec. In the remainder of this section, we specify the way IPsec. In the remainder of this section, we specify the way
IPsec may be used, and the implementation requirements we mention IPsec may be used, and the implementation requirements we mention
are meant to be applicable whenever IPsec is being used. are meant to be applicable whenever IPsec is being used.
We consider only the case where IPsec is used together with an IP- We consider only the case where IPsec is used together with an IP-
based tunneling mechanism. Use of IPsec with an MPLS-based tunneling based tunneling mechanism. Use of IPsec with an MPLS-based tunneling
mechanism is for further study. In the case where the encapsulation mechanism is for further study.
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 If it is deemed necessary to use tunnels that are protected by IPsec,
tunnel head and as being destined for the tunnel tail; IPsec the tunnel type SHOULD be negotiated by the tunnel endpoints using
transport mode SHOULD thus be used. the procedures specified in [ENCAPS-IPSEC]. That document allows the
use of IPsec tunnel mode, but also allows one to treat the tunnel
head and the tunnel tail as the endpoints of a Security Association,
and to use IPsec transport mode.
The IP header of the encapsulated packet becomes the outer IP header In order to use IPsec transport mode, encapsulated packets should be
of the resulting packet. That IP header is followed by an IPsec viewed as originating at the tunnel head and as being destined for
header, which in turn is followed by the payload. the tunnel tail. A single IP address of the tunnel head will be used
as the source IP address, and a single IP address of the tunnel tail
will be used as the destination IP address. This technique can be
used to to carry MPLS packets through an IPsec Security Association,
but first encapsulating the MPLS packets in MPLS-in-IP or MPLS-in-GRE
[RFC4023] and then applying IPsec transport mode.
When IPsec is used to secure softwires, IPsec MUST provide When IPsec is used to secure softwires, IPsec MUST provide
authentication and integrity. Thus, the implementation MUST support authentication and integrity. Thus, the implementation MUST support
ESP (IP Encapsulating Security Payload) with null encryption either ESP (IP Encapsulating Security Payload) with null encryption
[RFC4303]. ESP with encryption MAY be supported. If ESP is used, [RFC4303] or else AH (IP Authentication Header) [RFC4302]. ESP with
the tunnel tail MUST check that the source IP address of any packet encryption MAY be supported. If ESP is used, the tunnel tail MUST
received on a given SA is the one expected. check that the source IP address of any packet received on a given SA
(IPsec Security Association) is the one expected.
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 IKE [RFC4306], operating in main mode with preshared keys. means of IKE [RFC4306], operating in main mode with preshared keys.
If a PKI (Public Key Infrastructure) is not available, the IPsec
Tunnel Authenticator sub-TLV described in [ENCAPS-IPSEC] MUST be used
and validated before setting up an SA.
The selectors associated with the SA are the source and destination 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.
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 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.
16. Normative References 16. Normative References
[ENCAPS-IPSEC] "BGP IPSec Tunnel Encapsulation Attribute", L. Berger,
R. White, E. Rosen, draft-ietf-softwire-encaps-ipsec-00.txt, March
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-idr-encaps- Attribute", P. Mohapatra and E. Rosen, draft-ietf-softwire-encaps-
safi-00.txt, August 2007. safi-00.txt, January 2008.
[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 28, line 49 skipping to change at page 29, line 8
Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta, RFC 3032, Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta, RFC 3032,
January 2001. January 2001.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G.
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
(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-idr-v4nlri-v6nh-01.txt, October with an IPv6 Next Hop", draft-ietf-softwire-v4nlri-v6nh-00.txt,
2007. January 2008.
[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 17. Informative References
[BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection", [BFD] D. Katz and D. Ward, "Bidirectional Forwarding Detection",
draft-ietf-bfd-base-06.txt, March 2007. draft-ietf-bfd-base-08.txt, March 2008.
[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-06.txt, January 2008. Aggarwal, draft-ietf-l3vpn-2547bis-mcast-06.txt, January 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-04.txt, November 2007. Kodeboniya, draft-ietf-l3vpn-2547bis-mcast-bgp-04.txt, November 2007.
[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.
Minei, K. Kompella, IJ. Wijnands, B. Thomas, draft-ietf-mpls-ldp- Minei, K. Kompella, IJ. Wijnands, B. Thomas, draft-ietf-mpls-ldp-
p2mp-03, July 2007. p2mp-04, February 2008.
[RFC1195] "Use of OSI IS-IS for Routing in TCP/IP and Dual [RFC1195] "Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments", R. Callon, RFC 1195, December 1990. Environments", R. Callon, RFC 1195, December 1990.
[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.
[RFC5036] "LDP Specification", L. Andersson, P. Doolan, N. Feldman,
A. Fredette, B. Thomas, January 2001.
[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. [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
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] 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.
[RPF-VECTOR], "The RPF Vector TLV", IJ. Wijnands, draft-ietf-pim-rpf- [RFC5036] "LDP Specification", L. Andersson, I. Minei, B. Thomas,
vector-05.txt, November 2007. October 2007.
[SW-PROB] X. Li, "Softwire Problem Statement", draft-ietf-softwire- [RPF-VECTOR], "The RPF Vector TLV", IJ. Wijnands, A. Boers, E. Rosen,
problem-statement-03.txt, March 2007. draft-ietf-pim-rpf-vector-06.txt, February 2008.
[SW-PROB] X. Li, S. Dawkins, D. Ward, A. Durand, "Softwire Problem
Statement", RFC 4925, July 2007.
Authors' Addresses 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
 End of changes. 24 change blocks. 
48 lines changed or deleted 58 lines changed or added

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