draft-ietf-softwire-mesh-framework-02.txt   draft-ietf-softwire-mesh-framework-03.txt 
Network Working Group J. Wu Network Working Group J. Wu
Internet Draft Y. Cui Internet Draft Y. Cui
Expiration Date: January 2008 X. Li Intended Status: Standards Track X. Li
Tsinghua University Expires: July 14, 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
Softwire Mesh Framework Softwire Mesh Framework
draft-ietf-softwire-mesh-framework-02.txt draft-ietf-softwire-mesh-framework-03.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 6, line 30 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 (Label Distribution Protocol, [RFC3036]) and RSVP-TE-based LDP-based (Label Distribution Protocol, [RFC5036]) and RSVP-TE-based
([RFC3209]), L2TPv3 [RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003]. ([RFC3209]), L2TPv3 [RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003].
The framework will also accommodate the use of IPsec tunneling, when The framework will also accommodate the use of IPsec tunneling, when
that is necessary 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
skipping to change at page 13, line 38 skipping to change at page 13, line 38
In the case where the NLRI is in the IPv4 address family, and the NH In the case where the NLRI is in the IPv4 address family, and the NH
is in the IPv6 address family, [V4NLRI-V6NH] explains how to encode is in the IPv6 address family, [V4NLRI-V6NH] explains how to encode
the NH. the NH.
If a BGP speaker sends an update for an NLRI in the E-IP family, and If a BGP speaker sends an update for an NLRI in the E-IP family, and
the update is being sent over a BGP session that is running on top of the update is being sent over a BGP session that is running on top of
the I-IP network layer, and the BGP speaker is advertising itself as the I-IP network layer, and the BGP speaker is advertising itself as
the NH for that NLRI, then the BGP speaker MUST, unless explicitly the NH for that NLRI, then the BGP speaker MUST, unless explicitly
overridden by policy, specify the NH address in the I-IP family. The overridden by policy, specify the NH address in the I-IP family. The
address family of the NH MUST not be changed by a Route Reflector. address family of the NH MUST NOT be changed by a Route Reflector.
In some cases (e.g., when [V4NLRI-V6NH] is used), one cannot follow In some cases (e.g., when [V4NLRI-V6NH] is used), one cannot follow
this rule unless one's BGP peers have advertised a particular BGP this rule unless one's BGP peers have advertised a particular BGP
capability. This leads to the following softwires deployment capability. This leads to the following softwires deployment
restriction: if a BGP Capability is defined for the case in which an restriction: if a BGP Capability is defined for the case in which an
E-IP NLRI has an I-IP NH, all the AFBRs in a given transit core MUST E-IP NLRI has an I-IP NH, all the AFBRs in a given transit core MUST
advertise that capability. advertise that capability.
If an AFBR has multiple IP addresses, the network administrators If an AFBR has multiple IP addresses, the network administrators
usually have considerable flexibility in choosing which one the AFBR usually have considerable flexibility in choosing which one the AFBR
skipping to change at page 26, line 12 skipping to change at page 26, line 12
tunnel's receiving endpoint. For example, when the tunnel tunnel's receiving endpoint. For example, when the tunnel
encapsulation is IP-based: encapsulation is IP-based:
- The tunnel receiving endpoints can be given a distinct set of - The tunnel receiving endpoints can be given a distinct set of
addresses, and those addresses can be made known to the border addresses, and those addresses can be made known to the border
routers. The border routers can then filter out packets, routers. The border routers can then filter out packets,
destined to those addresses, which arrive from outside the destined to those addresses, which arrive from outside the
domain. domain.
- The tunnel transmitting endpoints can be given a distinct set of - The tunnel transmitting endpoints can be given a distinct set of
addresses, and those addresses can be made know to the border addresses, and those addresses can be made known to the border
routers and to the tunnel receiving endpoints. The border routers routers and to the tunnel receiving endpoints. The border routers
can filter out all packets arriving from outside the domain with can filter out all packets arriving from outside the domain with
source addresses that are in this set, and the receiving source addresses that are in this set, and the receiving
endpoints can discard all packets which appear to be part of a endpoints can discard all packets which appear to be part of a
softwire, but whose source addresses are not in this set. softwire, but whose source addresses are not in this set.
If an MPLS-based encapsulation is used, the border routers can refuse If an MPLS-based encapsulation is used, the border routers can refuse
to accept MPLS packets from outside the domain, or can refused to to accept MPLS packets from outside the domain, or can refuse to
accept such MPLS packets whenever the top label corresponds to the accept such MPLS packets whenever the top label corresponds to the
address of a tunnel receiving endpoint. address of a tunnel receiving endpoint.
These techniques assume that within a domain, the network is secure These techniques assume that within a domain, the network is secure
enough to prevent the introduction of spoofed packets from within the enough to prevent the introduction of spoofed packets from within the
domain itself. That may not always be the case. Also, these domain itself. That may not always be the case. Also, these
techniques however can be difficult or impossible to use effectively techniques however can be difficult or impossible to use effectively
for tunnels that are not in the same administrative domain. for tunnels that are not in the same administrative domain.
A different technique is to have the encapsulation header contain a A different technique is to have the encapsulation header contain a
skipping to change at page 26, line 44 skipping to change at page 26, line 44
to spy on packets that originate in the domain and that do not leave to spy on packets that originate in the domain and that do not leave
the domain. An attacker would then not be able to discover the the domain. An attacker would then not be able to discover the
password. An attacker could of course try to guess the password, but password. An attacker could of course try to guess the password, but
if the password is an arbitrary 64-bit binary sequence, brute force if the password is an arbitrary 64-bit binary sequence, brute force
attacks which run through all the possible passwords would be attacks which run through all the possible passwords would be
infeasible. This technique may be easier to manage than ingress infeasible. This technique may be easier to manage than ingress
filtering is, and may be just as effective if the assumptions hold. filtering is, and may be just as effective if the assumptions hold.
Like ingress filtering, though, it may not be applicable for tunnels Like ingress filtering, though, it may not be applicable for tunnels
that cross domain boundaries. that cross domain boundaries.
Therefore it is necessary to consider the use of more cryptographic Therefore it is necessary to also consider the use of cryptographic
techniques for setting up the tunnels and for passing data through techniques for setting up the tunnels and for passing data through
them. them.
14.3. Cryptographic techniques 14.3. Cryptographic techniques
If the path between the two endpoints of a tunnel is not adequately If the path between the two endpoints of a tunnel is not adequately
secure, then secure, then
- If a control protocol is used to set up the tunnels (e.g., to - If a control protocol is used to set up the tunnels (e.g., to
inform one tunnel endpoint of the IP address of the other), the inform one tunnel endpoint of the IP address of the other), the
skipping to change at page 27, line 45 skipping to change at page 27, line 45
The encapsulated packets should be viewed as originating at the The encapsulated packets should be viewed as originating at the
tunnel head and as being destined for the tunnel tail; IPsec tunnel head and as being destined for the tunnel tail; IPsec
transport mode SHOULD thus be used. transport mode SHOULD thus be used.
The IP header of the encapsulated packet becomes the outer IP header The IP header of the encapsulated packet becomes the outer IP header
of the resulting packet. That IP header is followed by an IPsec of the resulting packet. That IP header is followed by an IPsec
header, which in turn is followed by the payload. header, which in turn is followed by the payload.
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) will null encryption ESP (IP Encapsulating Security Payload) with null encryption
[RFC4303]. ESP with encryption MAY be supported. If ESP is used, [RFC4303]. ESP with encryption MAY be supported. If ESP is used,
the tunnel tail MUST check that the source IP address of any packet the tunnel tail MUST check that the source IP address of any packet
received on a given SA is the one expected. received on a given SA 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.
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
skipping to change at page 28, line 24 skipping to change at page 28, line 24
service providers. 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-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- Attribute", P. Mohapatra and E. Rosen, draft-ietf-idr-encaps-
safi-01.txt, February 2007. safi-00.txt, August 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 28, line 50 skipping to change at page 28, line 50
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.
[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-01.txt, October
2006. 2007.
[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-06.txt, March 2007.
[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-04.txt, October 2006. 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-02.txt, March 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-02, June 2006. p2mp-03, July 2007.
[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.
[RFC3036] "LDP Specification", L. Andersson, P. Doolan, N. Feldman, [RFC5036] "LDP Specification", L. Andersson, P. Doolan, N. Feldman,
A. Fredette, B. Thomas, January 2001. 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.
skipping to change at page 30, line 19 skipping to change at page 30, line 19
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- [RPF-VECTOR], "The RPF Vector TLV", IJ. Wijnands, draft-ietf-pim-rpf-
vector-03.txt, October 2006. vector-05.txt, November 2007.
[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
skipping to change at page 32, line 22 skipping to change at page 32, line 22
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
18. Full Copyright Statement 18. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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
 End of changes. 17 change blocks. 
19 lines changed or deleted 21 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/