BGP Enabled Services Z. Li
Internet-Draft China Mobile
Intended status: Standards Track March 9, 2017
Expires: September 10, 2017
Connecting IPv4 Islands over IPv6 MPLS Using IPv4 Provider Edge Routers
(4PE)
draft-li-bess-4pe-02
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 10, 2017 [Page 1]
Internet-Draft 4PE March 2017
This Internet-Draft will expire on September 10, 2017.
Copyright Notice
Copyright (c) 2017 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.
Li Expires September 10, 2017 [Page 2]
Internet-Draft 4PE March 2017
+--------------+
| 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]
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]
Li Expires September 10, 2017 [Page 3]
Internet-Draft 4PE March 2017
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.
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 IPv6 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.
Li Expires September 10, 2017 [Page 4]
Internet-Draft 4PE March 2017
+---------------------------------------------------------+
| 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):
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.
Li Expires September 10, 2017 [Page 5]
Internet-Draft 4PE March 2017
+---------------------------+
| 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.
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 <length, label, prefix > 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 10, 2017 [Page 6]
Internet-Draft 4PE March 2017
+--------------------------------------------------------------+
| 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 <Length, Label, Prefix>
......... 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 10, 2017 [Page 7]
Internet-Draft 4PE March 2017
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 from range
1-63, the registy of Subsequent Address Family Identifiers (SAFI)
Parameters. 4PE routers use this SAFI to transport IPv4 routes, the
corresponding MPLS label, IPv4 and IPv6 next hop addresses among 4PE
routers.
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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
Li Expires September 10, 2017 [Page 8]
Internet-Draft 4PE March 2017
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
<http://www.rfc-editor.org/info/rfc3107>.
[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,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<http://www.rfc-editor.org/info/rfc4760>.
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,
<http://www.rfc-editor.org/info/rfc4798>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for
Operating IPv6-Only MPLS Networks", RFC 7439,
DOI 10.17487/RFC7439, January 2015,
<http://www.rfc-editor.org/info/rfc7439>.
[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,
<http://www.rfc-editor.org/info/rfc7552>.
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 10, 2017 [Page 9]