[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/