BGP Enabled Services Z. Li Internet-Draft China Mobile Intended status: Standards Track March 8, 2016 Expires: September 9, 2016 Connecting IPv4 Islands over IPv6 MPLS Using IPv4 Provider Edge Routers (4PE) draft-li-bess-4pe-01 Abstract This document explains how to interconnect IPv4 islands over a Multiprotocol Label Switching (MPLS)-enabled IPv6-only core. This approach relies on IPv4 Provider Edge routers (4PE), which are Dual Stacks in order to connect to IPv4 islands and to the MPLS core. The 4PE routers exchange the IPv4 reachability information transparently over the core using the Multiprotocol Border Gateway Protocol (MP- BGP). MP-BGP is extended to do this. A new Subsequence Address Family Identifier (SAFI) with corresponding new format Network Layer Reachability Information (NLRI), is introduced. The BGP Next Hop field is used to convey the IPv4 address of the 4PE router, a field is added in Network Layer Reachability Information (NLRI) to convey the IPv6 address of the 4PE router, so that dynamically established IPv6-signaled MPLS Label Switched Paths (LSPs) can be used without explicit tunnel configuration. Requirements Language 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 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." Li Expires September 9, 2016 [Page 1] Internet-Draft 4PE March 2016 This Internet-Draft will expire on September 9, 2016. Copyright Notice Copyright (c) 2016 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. 4PE SAFI . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Exchange IPv4 reachability information among 4PE routers . . 6 5. Transport IPv4 packets among 4PE routers . . . . . . . . . . 7 6. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Consideration . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction After IPv6 [RFC2460] is widely deployed, IPv6-only networks and nodes will become dominate. How to provide the connectivity for the remaining IPv4-only islands through the IPv6-only MPLS network will become a problem, as depicted in the following figure. +-------------------+ |IPv4-only island A CE--4PE-----------------------+ +-------------------+ | | +--------------------+ |IPv6-only MPLS network 4PE--CE IPv4-only island C| +-------------------+ | | +--------------------+ |IPv4-only island B CE--4PE-----------------------+ +-------------------+ IPv6 Provider Edge Routers (6PE), as specified in [RFC4798], are used to connect IPv6 islands over IPv4 MPLS network. However, [RFC7439] Li Expires September 9, 2016 [Page 2] Internet-Draft 4PE March 2016 pointed out that there is no solution to address the above problem. So, in this document, 4PE is proposed to meet this gap. 2. Protocol Overview Each IPv4 island is connected to at least one Provider Edge router that is located on the border of the IPv6-only MPLS network. We call such a router a IPv4 Provider Edge router (4PE). The 4PE router MUST be IPv4 and IPv6 dual stack. At least one IPv4 address MUST be configured for the 4PE to connect the IPv4-only island. And at least one IPv6 address on the IPv6-ony MPLS network side MUST be configured. The configured IPv6 address needs to be routable in the IPv6-only network, and there needs to be a label bound via an IPv6 label distribution protocol to this IPv6 route. The configured IPv4 address MUST be unique among the IPv4 islands. As a result of this, every considered 4PE router knows which MPLS label (we call it forwarding label) to use to send packets to any other 4PE router. Note that [RFC5036] updated by [RFC7552] fulfills these requirements. We call the 4PE router receiving IPv4 packets from an IPv4 island an ingress 4PE router (relative to these IPv4 packets). We call a 4PE router forwarding IPv4 packets to an IPv4 island an egress 4PE router (relative to these IPv4 packets). Interconnecting IPv4 islands over an IPv6 MPLS network mainly includes the following two steps: 1. Exchange IPv4 reachability information among 4PE routers with MP- BGP [RFC4760] The IPv4 routes MUST not be injected in the IPv6-only MPLS network. The 4PE routers MUST exchange the IPv4 routes over MP-BGP sessions running over IPv6. To do so, a new Subsequence Address Family Identifier (SAFI) with corresponding new format Network Layer Reachability Information (NLRI), is introduced in this document. We call this new SAFI 4PE SAFI, the detail of which is illustrated in section 3. The MP-BGP Address Family Identifier (AFI) used MUST be IPv4 (value 1). The MP- BGP Network Address of Next Hop MUST be the 4PE IPv4 address from which the 4PE receives the IPv4 routes of the IPv4 island. The IPv6 address of the 4PE, the IPv4 routes of the IPv4 island, and the corresponding MPLS label for the IPv4 routes (we call it 4PE label) MUST be encoded in the NLRI. Li Expires September 9, 2016 [Page 3] Internet-Draft 4PE March 2016 The reason to allocate MPLS label for the IPv4 route is to reduce the requirements for the IPv6-only MPLS network, as explained in [RFC4798]. Here it is. While this approach could theoretically operate in some situations using a single level of labels, there are significant advantages in using a second level of labels that are bound to IPv4 prefixes via MP- BGP advertisements. For instance, the use of a second level label allows Penultimate Hop Popping (PHP) on the IPv4 Label Switch Router (LSR) upstream of the egress 4PE router, without any IPv4 capabilities on the penultimate router. This is because it still transmits MPLS packets even after the PHP (instead of having to transmit IPv4 packets and encapsulate them appropriately). 2. Transport IPv4 packets from the ingress 4PE router to the egress 4PE router over the IPv6-signaled LSPs The ingress 4PE router MUST forward IPv4 data over the IPv6-signaled LSP towards the egress 4PE router identified by the IPv6 address advertised in the new introduced NLRI for the corresponding IPv4 route. 3. 4PE SAFI As depicted in the following figure, 4PE SAFI is proposed to carry the IPv4 routes for the IPv4-only island, the MPLS label for the IPv4 routes, the IPv4 and IPv6 IP addresses of the 4PE router . +---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Reserved (1 octet) | +---------------------------------------------------------+ | Network Layer Reachability Information (variable) | +---------------------------------------------------------+ The use and meaning of these fields are as follows: Address Family Identifier (AFI): Li Expires September 9, 2016 [Page 4] Internet-Draft 4PE March 2016 This field MUST be 1, to indicate IPv4 routes are carried in the NLRI. This is in accordance with [RFC4760] Subsequent Address Family Identifier (SAFI): This field is used to indicate the new introduced 4PE SAFI. The value for this field is be assigned by IANA. Length of Next Hop Network Address: This field MUST be 4, to indicate an IPv4 address is encoded in the "Network Address of Next Hop" field. Network Address of Next Hop: This field MUST be one of the 4PE IPv4 address from which the 4PE receives the IPv4 routes of the IPv4 island. Reserved: A 1 octet field that MUST be set to 0, and SHOULD be ignored upon receipt. Network Layer Reachability Information (NLRI): The format and meaning of this field is specified in the following. +---------------------------+ | IPv6 Next Hop (16 octets) | +---------------------------+ | Length (1 octet) | +---------------------------+ | Label (3 octets) | +---------------------------+ ............................. +---------------------------+ | Prefix (variable) | +---------------------------+ The "IPv6 Next Hop" field MUST be the IPv6 address of the 4PE, through which the corresponding 4PE can be reached in the IPv6-only MPLS network. The "Label" field MUST be the MPLS label allocated by the 4PE for the IPv4 routes carried in the Prefix field. This label is called 4PE label. Li Expires September 9, 2016 [Page 5] Internet-Draft 4PE March 2016 The "Prefix" field MUST be used to carry the IPv4 routes for the IPv4-only island. The "Length" field indicates the length in bits of the Prefix plus the Label. One or more triples of the form can be encoded in this NLRI. The use and meaning of the fields in this NLRI, except IPv6 Next Hop, are in accordance with [RFC3107]. 4. Exchange IPv4 reachability information among 4PE routers 4PE routers MUST encode the IPv4 routes for the IPv4-only island in the UPDATE message of [RFC4271]. MP_REACH_NLRI (Type Code 14) and MP_UNREACH_NLRI (Type Code 15) defined in [RFC4760] MUST be used for route advertisement and withdraw respectively. 4PE SAFI defined in this document MUST be used in MP_REACH_NLRI or MP_UNREACH_NLRI to complete the exchange of IPv4 routes. For advertisement, the 4PE router sets the fields of MP_REACH_NLRI as following, and then send the UPDATE message to its 4PE peers (or Route Reflectors(RR) in the network where RRs are deployed) over the MP-BGP session established on IPv6. Li Expires September 9, 2016 [Page 6] Internet-Draft 4PE March 2016 +--------------------------------------------------------------+ | Address Family Identifier (2 octets, value = 1) | +--------------------------------------------------------------+ | Subsequent Address Family Identifier | | (1 octet, value = 4PE SAFI ) | +--------------------------------------------------------------+ | Length of Next Hop Network Address (1 octet, value = 4) | +--------------------------------------------------------------+ | Network Address of Next Hop (variable, value = IPv4 address | | of 4PE router, from which IPv4 routes are received) | +--------------------------------------------------------------+ | Reserved (1 octet, value = 0) | +--------------------------------------------------------------+ | IPv6 Next Hop (16 octets, value = IPv6 address of the 4PE | | router, through which the 4PE can be reached in the | | IPv6-only MPLS network) | +--------------------------------------------------------------+ | Length (1 octet, | | value = the length in bits of the Prefix plus the Label) | +--------------------------------------------------------------+ | Label (3 octets, value = MPLS label allocated by the 4PE | | router for the IPv4 routes carried in the Prefix field) | +--------------------------------------------------------------+ | Prefix (variable, | | value = the IPv4 route to be carried to 4PE MP-BGP peers) | +--------------------------------------------------------------+ ......... (if needed, more triples of ......... can be encoded here) +--------------------------------------------------------------+ When receiving the UPDATE message, the 4PE MP-BGP peer treats the message as per [RFC4760] and [RFC3107]. Since the 4PE router can learn IPv4 routes from other 4PE routers through 4PE SAFI defined in this document, and from the IPv4-only island directly connected to it, 4PE routers MUST distinguish those two kinds of IPv4 routes. Further, the 4PE MP-BGP peer MUST establish the relation between Network Address of Next Hop and IPv6 Next Hop carried in the 4PE SAFI. Through this relation, 4PE routers can get IPv6 Next Hop using Network Address of Next Hop. The method or data structure used to do this is out of scope of this document. 5. Transport IPv4 packets among 4PE routers When ingress 4PE router receives IPv4 packet, it treats the IPv4 packet as normal IPv4 router does except for the following steps. If the matching IPv4 route for this packet is learned from other 4PE routers through the 4PE SAFI defined in this document, the 4PE router has further to get the IPv6 Next Hop using the IPv4 next hop of the Li Expires September 9, 2016 [Page 7] Internet-Draft 4PE March 2016 matching IPv4 route. Then, ingress 4PE router uses the IPv6 Next Hop to lookup in its IPv6 routing table to get the IPv6-signaled LSP to reach the egress 4PE router. Next, ingress 4PE router encapsulates the received IPv4 packet using two labels as shown in the figure below. Finally, ingress 4PE router forwards the encapsulated packet to egress 4PE router through the IPv6-signaled LSP. +------------------------+ | Forwarding label | +------------------------+ | 4PE label | +------------------------+ | IPv4 packet | +------------------------+ When the packet reaches egress 4PE router, only 4PE label is left since the forwarding label is popped up by the penultimate hop toward egress 4PE router. Egress 4PE router pops up the 4PE label, looks up in the IPv4 routing table using the destination address of the IPv4 packet, and then forwards the IPv4 packets to the IPv4-only island. 6. IANA Requirements IANA is requested to assign a new SAFI for the 4PE SAFI. 4PE routers use this SAFI to transport IPv4 routes, the corresponding MPLS label, IPv4 and IPv6 next hop addresses among 4PE routers. The following number is suggested. Value Meaning 9 4PE SAFI 7. Security Consideration This document raises no new security issues. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . Li Expires September 9, 2016 [Page 8] Internet-Draft 4PE March 2016 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . 8.2. Informative References [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, DOI 10.17487/RFC4798, February 2007, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for Operating IPv6-Only MPLS Networks", RFC 7439, DOI 10.17487/RFC7439, January 2015, . [RFC7552] Asati, R., Pignataro, C., Raza, K., Manral, V., and R. Papneja, "Updates to LDP for IPv6", RFC 7552, DOI 10.17487/RFC7552, June 2015, . Author's Address Zhenqiang Li China Mobile No.32 Xuanwumenxi Ave., Xicheng District Beijing 100032 P.R. China Email: li_zhenqiang@hotmail.com Li Expires September 9, 2016 [Page 9]