Network working group X. Xu Internet Draft Huawei Category: Standard Track P. Francis Expires: February 2011 MPI-SWS Y. Cui Tsinghua University August 24, 2010 Simple Tunnel Endpoint Signaling in BGP draft-xu-softwire-tunnel-endpoint-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 24, 2011. Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Xu, et al. Expires February 24, 2011 [Page 1] Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010 Abstract The Softwire Mesh Framework provides a solution for intra-Autonomous System (AS) softwire, but not inter-AS softwire. The ability to provide inter-AS softwire extends the benefits of softwire to a larger scale. Indeed, the above Framework discusses the possibility of inter-AS softwire, but does not provide a solution. This document defines a specific BGP Extended Community attribute called the Tunnel Endpoint attribute, which allows for inter-AS softwire. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Terminology.................................................3 2. Problem Statement...........................................3 3. Inter-AS Softwire Mesh Solution.............................4 4. Syntax of the Tunnel Endpoint Attribute.....................6 5. Summary of Inter-AS Softwire Rules..........................6 6. Security Considerations.....................................7 7. IANA Considerations.........................................7 8. Acknowledgments.............................................7 9. References..................................................7 Authors' Addresses.............................................8 Xu, et al. Expires February 24, 2011 [Page 2] Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010 1. Terminology This document uses the terms defined in [RFC2663] e.g., "I-IP" (Internal IP), "E-IP" (External IP) and ''AFBR'' (Address Family Border Router). Below are terms specific to this document: - Non-AFBR ASBR: a special AFBR which only needs to operate E-IP control plane, but not E-IP date-plane. That's to say, on the control plane, the non-AFBR ASBR MUST be dual-stack and support extended MP-BGP for softwire signalling, on the data plane, it only supports I-IP address family. 2. Problem Statement The Softwire Mesh Framework [RFC5565] mainly discusses softwire mesh solution for intra-AS scenario, where a "transit core" consists of a single Autonomous System (AS). The ability to provide inter-AS softwire extends the benefits of intra-AS softwire, namely that I-IP P routers do not need to operate the E-IP protocol (routing and forwarding), to a larger scale. For example, an operator who owns multiple ASes could form Inter-AS softwire mesh in its network. In the Softwire Mesh Framework [RFC5565], three options are suggested to deal with the inter-AS scenario: a) Don't do it; require AFBRs to be deployed at the edge of each AS so that a transit core does not extend to more than one AS. b) 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 ASes. c) Ensure that an Autonomous System Border Router (ASBR) that is not an AFBR does not change the next-hop field of the routes for which encapsulation is needed. In option a, forwarding performance is reduced due to the extra tunneling/detunneling operations on each AS edges. In option b, AFBRs would have to afford to have the number of BGP neighbors implied by inter-AS full mesh. Hence it is not scalable. In option c, all those non-AFBR ASBRs would have to be upgraded to support this particular capability. Besides, this option is a substantial departure from the existing BGP control plane. Since BGP Xu, et al. Expires February 24, 2011 [Page 3] Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010 requires that the IGP have routes to all possible BGP next-hops, this approach increases the load on the IGP in unpredictable ways, and weakens the separation between IGP and BGP. 3. Inter-AS Softwire Mesh Solution This document suggests an alternative approach for inter-AS softwire mesh which follows the "spirit" of approach 3 that tunneling operations are not required on every AS edge. However, it uses a new extended community attribute called Tunnel Endpoint Attribute, to carry the tunnel endpoint address (i.e., I-IP address of the AFBR). In contrast to approach 3, this approach fits much better into current BGP operation because it doesn't change the semantics of the BGP next-hop field. Besides, there is no need to upgrade non-AFBR ASBRs in the middle ASes since the extended communities attribute is a transitive optional BGP attribute. +-----------------+ +-------+ | AS1(IPv4-only) | | IPv6 | +------+ | |Client |----| AFBR | | |Network| |IPv4/6| | +-------+ +------+ +--------+ | CN1 R11 | |Non-AFBR| | +---| ASBR |----+ +--------+ R12 | +--------+R21 +---|Non-AFBR|----+ | | ASBR | | | +--------+ | | AS2(IPv4-only) | | +--------+ | | |Non-AFBR| | +---| ASBR |----+ +--------+ R22 | +--------+ R31 +---|Non-AFBR|----+ CN2 | | ASBR | | +-------+ +------+ +--------+ | | IPv6 | | AFBR | | |Client |----|IPv4/6| | |Network| +------+ | +-------+ R32 | AS3(IPv4-only) | +-----------------+ Figure 1: Inter-AS Softwire Scenario Xu, et al. Expires February 24, 2011 [Page 4] Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010 In a scenario as shown in Figure 1, the Tunnel Endpoint Attribute works as follows: AFBR R11 for instance would advertise an IPv6 prefix for Client Network CN1 in a BGP update, and attach a Tunnel Endpoint Attribute conveying its own IPv4 address to the update. This attribute would be carried along BGP until it reaches AFBR R32. AFBR R32 would then learn to forward IPv6 packets destined for CN1 to AFBR R11 using an IPv4 tunnel. Given that the non-AFBR ASBRs never actually forward IPv6 packets, it is entirely possible to FIB-suppress the IPv6 prefixes so as to isolate FIB size from the routing table growth in IPv6. It could also be done for instance by implementing IPv6 forwarding capability in software only, or by having no IPv6 forwarding capability at all. This mode of operation reduces the hardware costs of those non-AFBR ASBRs since they do not need to accommodate high-performance IPv6 forwarding in hardware, or accommodate IPv6 forwarding at all. +-----------------+ +-------+ | AS1(IPv4-only) | | IPv6 | +------+ | |Client +----+ AFBR | | |Network| |IPv4/6| | +-------+ +------+ +------+ | CN1 R11 | | AFBR | | +----|IPv4/6|-----+ +------+ R12 | +----+ R21 +-----|IPv6|------+ | +----+ | | | | AS2(IPv6-only) | | | | +----+ | +-----|IPv6|------+ +----+ R22 | +------+ R31 +----| AFBR |-----+ CN2 | |IPv4/6| | +-------+ +------+ +------+ | | IPv6 | | AFBR | | |Client |----|IPv4/6| | |Network| +------+ | +-------+ R32 | AS3(IPv4-only) | +-----------------+ Figure 2: Transit Core Containing E-IP ASes Xu, et al. Expires February 24, 2011 [Page 5] Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010 In some special scenario where the transit core contains some E-IP AS domains, as shown in Figure 2, to avoid stacked tunneling, once the E-IP route enters an E-IP AS domain, the Tunnel Endpoint Attribute associated with the E-IP routes MUST be removed by the AFBR. For example, R12 MUST remove the Tunnel Endpoint Attribute from the E-IP routes for CN1 before advertising them to R21 through E-IP BGP sessions. When multiple specific routes with different tunnel endpoint addresses are aggregated, the aggregating router MUST attach a Tunnel Endpoint Attribute with its own address as the tunnel endpoint to the aggregated route. Note that the aggregating router MUST be an AFBR because it advertises itself as the tunnel endpoint. Where the tunnel type and/or additional tunnel parameters (i.e. for GRE or L2TP) MUST be signaled, the mechanisms defined in [RFC5512] could be used to signal these parameters. The two approaches for tunnel signaling including the Tunnel Encapsulation Attribute and the BGP Encapsulation Extended Community work well in inter-AS scenario since these two attributes are transitive across ASes. 4. Syntax of the Tunnel Endpoint Attribute This document proposes a new IPv4 address specific extended community attribute [RFC4360] and a new IPv6 address specific extended community attribute [I-D.ietf-l3vpn-v6-ext-communities] respectively to be used as the Tunnel Endpoint Attribute for IPv6- over-IPv4 scenario and IPv4-over-IPv6 scenario respectively. The value of the high-order octet for the IPv4 type field is 0x01 and for the IPv6 type field it is 0x00 since the Tunnel Endpoint Attribute MUST be transitive across ASes. The value of the low-order octet for the type field (i.e. the Sub-Type) is (TBD by IANA) for IPv4 and (TBD by IANA) for IPv6. The Global Administrator field is set to the Tunnel Endpoint address (i.e., one of the egress AFBR's I-IP addresses which are routable in the transit network). The Local Administrator field is set to zero and ignored upon receipt. 5. Summary of Inter-AS Softwire Rules a) All AFBRs MUST attach the Tunnel Endpoint Attribute to E-IP routes that enter the I-IP network domain. b) All AFBRs MUST remove the Tunnel Endpoint Attribute associated to E-IP routes that enter the E-IP network domain. c) If an AFBR selects a route associated with a Tunnel Endpoint Attribute as the best path, then the AFBR MUST tunnel packets Xu, et al. Expires February 24, 2011 [Page 6] Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010 matching that route towards the tunnel endpoint address associated with that route. d) Non-AFBR ABSRs SHOULD NOT remove the Tunnel Endpoint Attribute from the route update. e) When aggregating two or more specific routes with different Tunnel Endpoint Attributes into an aggregated route, the aggregating router MUST strip the original Tunnel Endpoint Attributes, and attach its own Tunnel Endpoint Attribute to the aggregated route. 6. Security Considerations If an AFBR chooses to disregard the I-IP tunnel route when selecting the E-IP route, then the AS path taken by a packet may be different from the AS path used to select the route. This, however, SHOULD rarely if ever result in a security violation per se. It would require that for some reason the security policy for selecting I-IP paths and E-IP paths to be different and incompatible. An AS can avoid this security issue either by having compatible security policies for both E-IP and I-IP routes, or by taking into account the I-IP tunnel route when selecting the E-IP route. The mechanisms described in the security considerations of the Softwire Mesh Framework [RFC5565] apply to the inter-domain softwire described here. 7. IANA Considerations A new Sub-Type of the Address Specific BGP Extended Communities Attribute of IPv4 and IPv6 respectively SHOULD be issued by IANA for the Tunnel Endpoint Attribute as described in Section 2. 8. Acknowledgments The authors would like to thank Eric Rosen, Spencer Dawkins and Yiu Lee for their valuable comments. 9. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. Xu, et al. Expires February 24, 2011 [Page 7] Internet-Draft Simple Tunnel Endpoint Signaling in BGP February 2010 [I-D.ietf-l3vpn-v6-ext-communities] Rekhter, Y., "IPv6 Address Specific BGP Extended Communities Attribute", draft-ietf-l3vpn-v6-ext-communities-02 (work in progress), March 2009. [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009. [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009. [I-D.draft-xu-tunnel] Xu, X., and Francis, P, "Simple Tunnel Endpoint Signaling in BGP ", draft-xu-tunnel-00.txt (work in progress), February 2009. Authors' Addresses Xiaohu Xu Huawei Technologies, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085, P.R. China Phone: +86 10 82836073 Email: xuxh@huawei.com Paul Francis Max Planck Institute for Software Systems Gottlieb-Daimler-Strasse Kaiserslautern 67633 Germany Phone: +49 631 930 39600 Email: francis@mpi-sws.org Yong Cui Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-10-6278-5822 Email: yong@csnet1.cs.tsinghua.edu.cn Xu, et al. Expires February 24, 2011 [Page 8]