返回首页

RFC 4659 - BGP-MPLS IP Virtual Private Network (VPN) Extensi

时间:2006-11-02 来源: 作者: 点击:
NetworkWorkingGroupJ.DeClercq RequestforComments:4659 Alcatel Category:StandardsTrack D.Ooms OneSparrow M.Carugi NortelNetworks F.LeFaucheur CiscoSystems September2006 BGP-MPLSIPVirtualPrivateNetwork(VPN)ExtensionforIPv6VPN StatusofThisMemo Thisdocum
  Network Working Group                                       J. De Clercq
Request for Comments: 4659                                         Alcatel
Category: Standards Track                                          D. Ooms
                                                                             OneSparrow
                                                                                 M. Carugi
                                                                       Nortel Networks 
                                                                         F. Le Faucheur
                                                                          Cisco Systems
                                                                      September 2006

    BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes a method by which a Service Provider may use
   its packet-switched backbone to provide Virtual Private Network (VPN)
   services for its IPv6 customers.  This method reuses, and extends
   where necessary, the "BGP/MPLS IP VPN" method for support of IPv6.
   In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4
   VPN routes over the service provider backbone, and MPLS is used to
   forward IPv4 VPN packets over the backbone.  This document defines an
   IPv6 VPN address family and describes the corresponding IPv6 VPN
   route distribution in "Multiprotocol BGP".

   This document defines support of the IPv6 VPN service over both an
   IPv4 and an IPv6 backbone, and for using various tunneling techniques
   over the core, including MPLS, IP-in-IP, Generic Routing
   Encapsulation (GRE) and IPsec protected tunnels.  The inter-working
   between an IPv4 site and an IPv6 site is outside the scope of this
   document.

Table of Contents

   1. Introduction ....................................................2
   2. The VPN-IPv6 Address Family .....................................4
   3. VPN-IPv6 Route Distribution .....................................5
      3.1. Route Distribution Among PEs by BGP ........................5
      3.2. VPN IPv6 NLRI Encoding .....................................6
           3.2.1. BGP Next Hop encoding ...............................6
                  3.2.1.1. BGP Speaker Requesting IPv6 Transport ......7
                  3.2.1.2. BGP Speaker Requesting IPv4 Transport ......8
      3.3. Route Target ...............................................8
      3.4. BGP Capability Negotiation .................................8
   4. Encapsulation ...................................................8
   5. Address Types ..................................................10
   6. Multicast ......................................................11
   7. Carriers’ Carriers .............................................11
   8. Multi-AS Backbones .............................................11
   9. Accessing the Internet from a VPN ..............................13
   10. Management VPN ................................................14
   11. Security Considerations .......................................14
   12. Quality of Service ............................................15
   13. Scalability ...................................................15
   14. IANA Considerations ...........................................15
   15. Acknowledgements ..............................................15
   16. References ....................................................16
      16.1. Normative References .....................................16
      16.2. Informative References ...................................16

1.  Introduction

   This document describes a method by which a Service Provider may use
   its packet-switched backbone to provide Virtual Private Network
   services for its IPv6 customers.

   This method reuses, and extends where necessary, the "BGP/MPLS IP
   VPN" method [BGP/MPLS-VPN] for support of IPv6.  In particular, this
   method uses the same "peer model" as [BGP/MPLS-VPN], in which the
   customers’ edge routers ("CE routers") send their IPv6 routes to the
   Service Provider’s edge routers ("PE routers").  BGP ("Border Gateway
   Protocol", [BGP, BGP-MP]) is then used by the Service Provider to
   exchange the routes of a particular IPv6 VPN among the PE routers
   that are attached to that IPv6 VPN.  Eventually, the PE routers
   distribute, to the CE routers in a particular VPN, the IPv6 routes
   from other CE routers in that VPN.  As with IPv4 VPNs, a key
   characteristic of this "peer model" is that the (IPv6) CE routers
   within an (IPv6) VPN do not peer with each other; there is no
   "overlay" visible to the (IPv6) VPN’s routing algorithm.

   This document adopts the definitions, acronyms, and mechanisms
   described in [BGP/MPLS-VPN].  Unless it is stated otherwise, the
   mechanisms of [BGP/MPLS-VPN] apply and will not be re-described here.

   A VPN is said to be an IPv6 VPN when each site of this VPN is IPv6
   capable and is natively connected over an IPv6 interface or sub-
   interface to the Service Provider (SP) backbone via a Provider Edge
   device (PE).

   A site may be both IPv4 capable and IPv6 capable.  The logical
   interface on which packets arrive at the PE may determine the IP
   version.  Alternatively, the same logical interface may be used for
   both IPv4 and IPv6, in which case a per-packet lookup at the Version
   field of the IP packet header determines the IP version.

   This document only concerns itself with handling of IPv6
   communication between IPv6 hosts located on IPv6-capable sites.
   Handling of IPv4 communication between IPv4 hosts located on IPv4-
   capable sites is outside the scope of this document and is covered in
   [BGP/MPLS-VPN].  Communication between an IPv4 host located in an
   IPv4- capable site and an IPv6 host located in an IPv6-capable site
   is outside the scope of this document.

   In a similar manner to how IPv4 VPN routes are distributed in
   [BGP/MPLS-VPN], BGP and its extensions are used to distribute routes
   from an IPv6 VPN site to all the other PE routers connected to a site
   of the same IPv6 VPN.  PEs use "VPN Routing and Forwarding tables"
   (VRFs) to maintain the reachability information and forwarding
   information of each IPv6 VPN separately.

   As is done for IPv4 VPNs [BGP/MPLS-VPN], we allow each IPv6 VPN to
   have its own IPv6 address space, which means that a given address may
   denote different systems in different VPNs.  This is achieved via a
   new address family, the VPN-IPv6 Address Family, in a fashion similar
   to that of the VPN-IPv4 address family, defined in [BGP/MPLS-VPN],
   which prepends a Route Distinguisher to the IP address.

   In addition to its operation over MPLS Label Switched Paths (LSPs),
   the IPv4 BGP/MPLS VPN solution has been extended to allow operation
   over other tunneling techniques, including GRE tunnels, IP-in-IP
   tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3], and IPsec
   protected tunnels [2547-IPsec].  In a similar manner, this document
   allows support of an IPv6 VPN service over MPLS LSPs, as well as over
   other tunneling techniques.

   This document allows support for an IPv6 VPN service over an IPv4
   backbone, as well as over an IPv6 backbone.  The IPv6 VPN service
   supported is identical in both cases.

   The IPv6 VPN solution defined in this document offers the following
   benefits:

      o From both the Service Provider perspective and the customer
        perspective, the VPN service that can be supported for IPv6
        sites is identical to the one that can be supported for IPv4
        sites.

      o From the Service Provider perspective, operations of the IPv6
        VPN service require the exact same skills, procedures, and
        mechanisms as those for the IPv4 VPN service.

      o Where both IPv4 VPNs and IPv6 VPN services are supported over an
        IPv4 core, the same single set of MP-BGP peering relationships
        and the same single PE-PE tunnel mesh MAY be used for both.

      o The IPv6 VPN service is independent of whether the core runs
        IPv4 or IPv6.  This is so that the IPv6 VPN service supported
        before and after a migration of the core from IPv4 to IPv6 is
        undistinguishable to the VPN customer.

   Note that supporting IPv4 VPN services over an IPv6 core is not
   covered by this document.

2.  The VPN-IPv6 Address Family

   The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes
   from multiple "address families".  We introduce the notion of the
   "VPN-IPv6 address family", which is similar to the VPN-IPv4 address
   family introduced in [BGP/MPLS-VPN].

   A VPN-IPv6 address is a 24-octet quantity, beginning with an 8-octet
   "Route Distinguisher" (RD) and ending with a 16-octet IPv6 address.

   The purpose of the RD is solely to allow one to create distinct
   routes to a common IPv6 address prefix, which is similar to the
   purpose of the RD defined in [BGP/MPLS-VPN].  In the same way as it
   is possible per [BGP/MPLS-VPN], the RD can be used to create multiple
   different routes to the very same system.  This can be achieved by
   creating two different VPN-IPv6 routes that have the same IPv6 part
   but different RDs.  This allows the provider’s BGP to install
   multiple different routes to the same system and allows policy to be
   used to decide which packets use which route.

   Also, if two VPNs were to use the same IPv6 address prefix
   (effectively denoting different physical systems), the PEs would
   translate these into unique VPN-IPv6 address prefixes using different
   RDs.  This ensures that if the same address is ever used in two
   different VPNs, it is possible to install two completely different
   routes to that address, one for each VPN.

   Since VPN-IPv6 addresses and IPv6 addresses belong to different
   address families, BGP never treats them as comparable addresses.

   A VRF may have multiple equal-cost VPN-IPv6 routes for a single IPv6
   address prefix.  When a packet’s destination address is matched in a
   VRF against a VPN-IPv6 route, only the IPv6 part is actually matched.

   The Route Distinguisher format and encoding is as specified in
   [BGP/MPLS-VPN].

   When a site is IPv4 capable and IPv6 capable, the same RD MAY be used
   for the advertisement of IPv6 addresses and IPv4 addresses.
   Alternatively, a different RD MAY be used for the advertisement of
   the IPv4 addresses and of the IPv6 addresses.  Note, however, that in
   the scope of this specification, IPv4 addresses and IPv6 addresses
   will always be handled in separate contexts, and that no IPv4-IPv6
   interworking issues and techniques will be discussed.

3.  VPN-IPv6 Route Distribution

3.1.  Route Distribution Among PEs by BGP

   As described in [BGP/MPLS-VPN], if two sites of a VPN attach to PEs
   that are in the same Autonomous System, the PEs can distribute VPN
   routes to each other by means of an (IPv4) internal Border Gateway
   Protocol (iBGP) connection between them.  Alternatively, each PE can
   have iBGP connections to route reflectors.  Similarly, for IPv6 VPN
   route distribution, PEs can use iBGP connections between them or use
   iBGP connections to route reflectors.  For IPv6 VPN, the iBGP
   connections MAY be over IPv4 or over IPv6.

   The PE routers exchange, via MP-BGP [BGP-MP], reachability
   information for the IPv6 prefixes in the IPv6 VPNs and thereby
   announce themselves as the BGP Next Hop.

   The rules for encoding the reachability information and the BGP Next
   Hop address are specified in the following sections.

3.2.  VPN IPv6 NLRI Encoding

   When distributing IPv6 VPN routes, the advertising PE router MUST
   assign and distribute MPLS labels with the IPv6 VPN routes.
   Essentially, PE routers do not distribute IPv6 VPN routes, but
   Labeled IPv6 VPN routes [MPLS-BGP].  When the advertising PE then
   receives a packet that has this particular advertised label, the PE
   will pop this label from the MPLS stack and process the packet
   appropriately (i.e., forward it directly according to the label or
   perform a lookup in the corresponding IPv6-VPN context).

   The BGP Multiprotocol Extensions [BGP-MP] are used to advertise the
   IPv6 VPN routes in the MP_REACH Network Layer Reachability
   Information (NLRI).  The Address Family Identifier (AFI) and
   Subsequent Address Family Identifier (SAFI) fields MUST be set as
   follows:

      - AFI: 2; for IPv6

      - SAFI: 128; for MPLS labeled VPN-IPv6

   The NLRI field itself is encoded as specified in [MPLS-BGP].  In the
   context of this extension, the prefix belongs to the VPN-IPv6 Address
   Family and thus consists of an 8-octet Route Distinguisher followed
   by an IPv6 prefix as specified in Section 2, above.

3.2.1.  BGP Next Hop encoding

   The encoding of the BGP Next Hop depends on whether the policy of the
   BGP speaker is to request that IPv6 VPN traffic be transported to
   that BGP Next Hop using IPv6 tunneling ("BGP speaker requesting IPv6
   transport") or using IPv4 tunneling ("BGP speaker requesting IPv4
   transport").

   Definition of this policy (to request transport over IPv4 tunneling
   or IPv6 tunneling) is the responsibility of the network operator and
   is beyond the scope of this document.  Note that it is possible for
   that policy to request transport over IPv4 (resp. IPv6) tunneling
   while the BGP speakers exchange IPv6 VPN reachability information
   over IPv6 (resp. IPv4).  However, in that case, a number of
   operational implications are worth considering.  In particular, an
   undetected fault affecting the IPv4 (resp. IPv6) tunneling data path
   and not affecting the IPv6 (resp. IPv4) data path could remain
   undetected by BGP, which in turn may result in black-holing of
   traffic.

   Control of this policy is beyond the scope of this document and may
   be based on user configuration.

3.2.1.1.  BGP Speaker Requesting IPv6 Transport

   When the IPv6 VPN traffic is to be transported to the BGP speaker
   using IPv6 tunneling (e.g., IPv6 MPLS LSPs, IPsec-protected IPv6
   tunnels), the BGP speaker SHALL advertise a Next Hop Network Address
   field containing a VPN-IPv6 address

      - whose 8-octet RD is set to zero, and

      - whose 16-octet IPv6 address is set to the global IPv6 address of
        the advertising BGP speaker.

   This is potentially followed by another VPN-IPv6 address

      - whose 8-octet RD is set to zero, and

      - whose 16-octet IPv6 address is set to the link-local IPv6
        address of the advertising BGP speaker.

   The value of the Length of the Next Hop Network Address field in the
   MP_REACH_NLRI attribute shall be set to 24 when only a global address
   is present, and to 48 if a link-local address is also included in the
   Next Hop field.

   If the BGP speakers peer using only their link-local IPv6 address
   (for example, in the case where an IPv6 CE peers with an IPv6 PE,
   where the CE does not have any IPv6 global address, and where eBGP
   peering is achieved over the link-local addresses), the "unspecified
   address" ([V6ADDR]) is used by the advertising BGP speaker to
   indicate the absence of the global IPv6 address in the Next Hop
   Network Address field.

   The link-local address shall be included in the Next Hop field if and
   only if the advertising BGP speaker shares a common subnet with the
   peer the route is being advertised to [BGP-IPv6].

   In all other cases, a BGP speaker shall advertise to its peer in the
   Next Hop Network Address field only the global IPv6 address of the
   next hop.

   As a consequence, a BGP speaker that advertises a route to an
   internal peer may modify the Network Address of Next Hop field by
   removing the link-local IPv6 address of the next hop.

   An example scenario where both the global IPv6 address and the link-
   local IPv6 address shall be included in the BGP Next Hop address
   field is that where the IPv6 VPN service is supported over a multi-
   Autonomous System (AS) backbone with redistribution of labeled VPN-

   IPv6 routes between Autonomous System Border Routers (ASBR) of
   different ASes sharing a common IPv6 subnet: in that case, both the
   global IPv6 address and the link-local IPv6 address shall be
   advertised by the ASBRs.

3.2.1.2.  BGP Speaker Requesting IPv4 Transport

   When the IPv6 VPN traffic is to be transported to the BGP speaker
   using IPv4 tunneling (e.g., IPv4 MPLS LSPs, IPsec-protected IPv4
   tunnels), the BGP speaker SHALL advertise to its peer a Next Hop
   Network Address field containing a VPN-IPv6 address:

      - whose 8-octet RD is set to zero, and

      - whose 16-octet IPv6 address is encoded as an IPv4-mapped IPv6
        address [V6ADDR] containing the IPv4 address of the advertising
        BGP speaker.  This IPv4 address must be routable by the other
        BGP Speaker.

3.3.  Route Target

   The use of route target is specified in [BGP/MPLS-VPN] and applies to
   IPv6 VPNs.  Encoding of the extended community attribute is defined
   in [BGP-EXTCOM].

3.4.  BGP Capability Negotiation

   In order for two PEs to exchange labeled IPv6 VPN NLRIs, they MUST
   use BGP Capabilities Negotiation to ensure that they both are capable
   of properly processing such NLRIs.  This is done as specified in
   [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol
   BGP), with AFI and SAFI values as specified above, in Section 3.2.

4.  Encapsulation

   The ingress PE Router MUST tunnel IPv6 VPN data over the backbone
   towards the Egress PE router identified as the BGP Next Hop for the
   corresponding destination IPv6 VPN prefix.

   When the 16-octet IPv6 address contained in the BGP Next Hop field is
   encoded as an IPv4-mapped IPv6 address (see Section 3.2.1.2), the
   ingress PE MUST use IPv4 tunneling unless explicitly configured to do
   otherwise.  The ingress PE MAY optionally allow, through explicit
   configuration, the use of IPv6 tunneling when the 16-octet IPv6
   address contained in the BGP Next Hop field is encoded as an IPv4-
   mapped IPv6 address.  This would allow support of particular
   deployment environments where IPv6 tunneling is desired but where
   IPv4-mapped IPv6 addresses happen to be used for IPv6 reachability of
   the PEs instead of Global IPv6 addresses.

   When the 16-octet IPv6 address contained in the BGP Next Hop field is
   not encoded as an IPv4-mapped address (see Section 3.2.1.1), the
   ingress PE MUST use IPv6 tunneling.

   When a PE receives a packet from an attached CE, it looks up the
   packet’s IPv6 destination address in the VRF corresponding to that
   CE.  This enables it to find a VPN-IPv6 route.  The VPN-IPv6 route
   will have an associated MPLS label and an associated BGP Next Hop.
   First, this MPLS label is pushed on the packet as the bottom label.
   Then, this labeled packet is encapsulated into the tunnel for
   transport to the egress PE identified by the BGP Next Hop.  Details
   of this encapsulation depend on the actual tunneling technique, as
   follows:

   As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunneling is done
   using IPv4 tunnels or IPv6 tunnels (resp. IPv4 GRE tunnels or IPv6
   GRE tunnels), encapsulation of the labeled IPv6 VPN packet results in
   an MPLS-in-IP (resp. MPLS-in-GRE) encapsulated packet as specified in
   [MPLS-in-IP/GRE].  When tunneling is done using L2TPv3, encapsulation
   of the labeled IPv6 VPN packet results in an MPLS-in-L2TPv3-
   encapsulated packet, as specified in [MPLS-in-L2TPv3].

   As with MPLS/BGP for IPv4 VPNs, when tunneling is done using an IPsec
   secured tunnel [2547-IPsec], encapsulation of the labeled IPv6 VPN
   packet results in an MPLS-in-IP- or MPLS-in-GRE-encapsulated packet
   [MPLS-in-IP/GRE].  The IPsec Transport Mode is used to secure this
   IPv4 or GRE tunnel from ingress PE to egress PE.

   When tunneling is done using IPv4 tunnels (whether IPsec secured or
   not), the Ingress PE Router MUST use the IPv4 address that is encoded
   in the IPv4-mapped IPv6 address field of the BGP next hop field as
   the destination address of the prepended IPv4 tunneling header.  It
   uses one of its IPv4 addresses as the source address of the prepended
   IPv4 tunneling header.

   When tunneling is done using IPv6 tunnels (whether IPsec secured or
   not), the Ingress PE Router MUST use the IPv6 address that is
   contained in the IPv6 address field of the BGP next hop field as the
   destination address of the prepended IPv6 tunneling header.  It uses
   one of its IPv6 addresses as the source address of the prepended IPv6
   tunneling header.

   When tunneling is done using MPLS LSPs, the LSPs can be established
   using any label distribution technique (LDP [LDP], RSVP-TE [RSVP-TE],
   etc.).

   When tunneling is done using MPLS LSPs, the ingress PE Router MUST
   directly push the LSP tunnel label on the label stack of the labeled
   IPv6 VPN packet (i.e., without prepending any IPv4 or IPv6 header).
   This pushed label corresponds to the LSP starting on the ingress PE
   Router and ending on the egress PE Router.  The BGP Next Hop field is
   used to identify the egress PE router and in turn the label to be
   pushed on the stack.  When the IPv6 address in the BGP Next Hop field
   is an IPv4-mapped IPv6 address, the embedded IPv4 address will
   determine the tunnel label to push on the label stack.  In any other
   case, the IPv6 address in the BGP Next Hop field will determine the
   tunnel label to push on the label stack.

   To ensure interoperability among systems that implement this VPN
   architecture, all such systems MUST support tunneling using MPLS LSPs
   established by LDP [LDP].

5.  Address Types

   Since Link-local unicast addresses are defined for use on a single
   link only, those may be used on the PE-CE link, but they are not
   supported for reachability across IPv6 VPN Sites and are never
   advertised via MultiProtocol-Border Gateway Protocol (MP-BGP) to
   remote PEs.

   Global unicast addresses are defined as uniquely identifying
   interfaces anywhere in the IPv6 Internet.  Global addresses are
   expected to be commonly used within and across IPv6 VPN Sites.  They
   are obviously supported by this IPv6 VPN solution for reachability
   across IPv6 VPN Sites and advertised via MP-BGP to remote PEs and are
   processed without any specific considerations to their global scope.

   Quoting from [UNIQUE-LOCAL]: "This document defines an IPv6 unicast
   address format that is globally unique and is intended for local
   communications [IPv6].  These addresses are called Unique Local IPv6
   Unicast Addresses and are abbreviated in this document as Local IPv6
   addresses.  They are not expected to be routable on the global
   Internet.  They are routable inside of a more limited area such as a
   site.  They may also be routed between a limited set of sites."

   [UNIQUE-LOCAL] also says in its Section 4.7: "Local IPv6 addresses
   can be used for inter-site Virtual Private Networks (VPN) if
   appropriate routes are set up.  Because the addresses are unique
   these VPNs will work reliably and without the need for translation.
   They have the additional property that they will continue to work if
   the individual sites are renumbered or merged."

   In accordance with this, Unique Local IPv6 Unicast Addresses are
   supported by the IPv6 VPN solution specified in this document for
   reachability across IPv6 VPN Sites.  Hence, reachability to such
   Unique Local IPv6 Addresses may be advertised via MP-BGP to remote
   PEs and processed by PEs in the same way as Global Unicast addresses.

   Recommendations and considerations for which of these supported
------分隔线----------------------------
顶一下
(2)
100%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容