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

Versions: 00

INTERNET DRAFT                                             Tri T. Nguyen
<draft-nguyen-ngtrans-bgp-tunnel-00.txt>                       Dirk Ooms
                                                          Gerard Gastaud
                                                        Jeremy De Clercq
                                                                 Alcatel
                                                           October, 2000
                                                     Expires April, 2001

          Connecting IPv6 Domains across IPv4 Clouds with BGP


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.


Abstract

   This document specifies a mechanism for IPv6 islands to communicate
   with each other over an IPv4 core network without explicit tunnel
   setup, requiring only one IPv4 address (and a derived IPv4-compatible
   IPv6 address) per IPv6 island or per set of IPv6 islands connected to
   the same edge router. The hosts in the IPv6 islands can use native
   IPv6 addresses.  The method uses MP-BGP in the edge routers to
   exchange IPv6 reachability information between the IPv6 islands.


1. Introduction

   [TRANS] specifies a method of automatic tunnels by using IPv4-
   compatible IPv6 addresses.  This method is restricted to the case in



Nguyen                     Expires April 2001                   [Page 1]


Internet Draft   draft-nguyen-ngtrans-bgp-tunnel-00.txt     October 2000


   which the destination coincides with the endpoint of the tunnel
   (host-to-host or router-to-host).  It has the disadvantage that it
   requires an IPv4 address per host.

   This memo specifies a mechanism for IPv6 islands to communicate with
   each other over an IPv4 core network without explicit tunnel set-up.
   The mechanism is intended as a transition tool used during the period
   of co-existence of IPv4 and IPv6.

   The method relies on BGP in the IPv4 network edge routers to exchange
   IPv6 reachability information between the IPv6 islands. The provider
   edge BGP routers are dual-stack and have at least an IPv4 address on
   the core network side and an IPv6 address at the IPv6 island side.

   Based on the information distributed by BGP, the data is
   automatically tunneled over the IPv4 cloud to its destination IPv6
   island.  This method requires only one IPv4 address (and a derived
   IPv4-compatible IPv6 address) per IPv6 island or per set of IPv6
   islands connected to the same edge router.

   The hosts in the IPv6 islands can have native IPv6 addresses, this is
   different from e.g. 6to4 [6TO4], which requires that IPv4-
   translatable addresses are allocated to the IPv6 hosts.

   This method can be looked at as a simplified instantiation of the
   general solution proposed for IPv6 VPNs over a IPv4 backbone [V6VPN].


2. Terminology

   The terminology of [IPV6] and [TRANS] applies to this document. We
   also use some of the terminology of [VPN].


3. Reference architecture

   The ISP provides IPv6 services to some of its customers. However, its
   network core has not been updated to IPv6. The provider has upgraded
   some routers in some POPs to be dual stack routers. The dual stack
   routers provide access to IPv6 customers and may provide access to
   IPv4 customers in addition.

   The ISP also has access to the global IPv6 Internet.

   The interface between the Customer Edge (CE) router and the Provider
   Edge (PE) router is a native IPv6 interface which can be physical or
   logical. It is assumed that in most cases, a routing protocol IGP or
   EGP runs between the CE and PE for a customer site to exchange the



Nguyen                     Expires April 2001                   [Page 2]


Internet Draft   draft-nguyen-ngtrans-bgp-tunnel-00.txt     October 2000


   site reachability. A customer site may connect to the provider
   network over more than one interface.

   It is assumed that all nodes in the IPv6 island have a global IPv6
   address.


4. IPv6 Site Prefix Distribution

   Routing protocols between a CE and a PE are needed to convey site
   prefixes to the ISP and conversely; for the mechanism described here,
   there is no specific requirement towards these protocols. Following
   the IPv6 addressing for global unicast aggregatable address [GUCST],
   the ISP is likely to have delegated some of its address space to the
   customer.  Routing in an island for destinations outside this island
   is such that this outbound traffic is sent to one of the island CE
   (and therefore to the associated PE).

   The distribution of IPv6 island prefixes to the other IPv6 islands
   happens via [MP-BGP]. The session between IBGP peers is transported
   over IPv4 since every peer PE is dual stack and Route Reflectors (if
   used) are likely to be IPv4 only. The use of IPv4-compatible IPv6
   addresses [V6ADDR] as the BGP next hop address allows to circumvent
   the problem of [MP-BGP] where the next hop has to be of the same
   family as the NLRI. The IPv4 address in the IPv4-compatible IPv6
   address of the PE is the IPv4 address of the PE.

   The MP-BGP AFI will be IPv6 (value 2), the SAFI will be one of the
   basic values: unicast, multicast or both (1,2 or 3).

   When the number of PEs is not too high, it is possible for PEs to
   peer in a mesh fashion. Otherwise Route Reflectors are used and the
   PEs are configured with some Route Reflector identity.


5. Tunneling

   The use of an IPv4-compatible IPv6 address [V6ADDR] as the BGP next
   hop address allows a PE that has to forward a packet to automatically
   determine the IPv4 endpoint of the tunnel by looking at the BGP
   routing info.

   If this transition method is used to connect to the public IPv6
   Internet, normal IPv4 tunnels [TUNNEL] do the job (no need for more
   secure LSPs or IPsec tunnels).

   When there are many peers, the number of tunnels could be a concern.
   However, there is no state required beyond the BGP state.



Nguyen                     Expires April 2001                   [Page 3]


Internet Draft   draft-nguyen-ngtrans-bgp-tunnel-00.txt     October 2000


   Considerations on 'common tunneling techniques' and 'automatic
   tunneling techniques' in [TRANS] are valid for the mechanism
   described in this document.


6. PE requirements

   The dual stack PE has to run MP-BGP. The address of the peer-PEs or
   the Route Reflector need to be configured.

   The PE must perform IPv4 encapsulation on packets whose next hop is
   an IPv4-compatible IPv6 address.  A PE must be able to do IPv4
   decapsulation.

7. Comparison to MPLS/BGP VPNs

   The described mechanism is a simplified instantiation of the solution
   for MPLS/BGP VPNs [VPN, V6VPN]. The method in this draft aims at
   enabling connections to the public IPv6 Internet, which could be
   viewed as one large 'public' VPN.  Since there is only one VPN
   connecting hosts with globally unique addresses that do not need
   island-to-island security, things are much simplified:

   - Since the IPv6 addresses are globally unique, there is no need for
   a Route Distinguisher (RD).

   - No need for VPN Routing and Forwarding (VRF) tables, the route info
   is in the normal routing table and when the BGP next-hop is a IPv4-
   compatible IPv6 address the data is tunneled in IPv4 to this BGP
   next-hop.

   - No need for a Route Target.

   - No need for the VPN SAFIs.

   - No need to carry labels in MP-BGP.  The method in this draft could
   be extended to using LSPs in stead of IP tunnels, but this wouldn't
   change anything to the MP-BGP behavior (there will never be a
   'bottom' label).


8. Security considerations

   This proposal can use the security features of BGP and any policy
   defined in the ISP domain.


References



Nguyen                     Expires April 2001                   [Page 4]


Internet Draft   draft-nguyen-ngtrans-bgp-tunnel-00.txt     October 2000


[6TO4]  B. Carpenter, K. Moore, "Connection of IPv6 domains via IPv4
        Clouds without Explicit Tunnels"", draft-ietf-ngtrans-6to4-
        05.txt, May 2000.

[GUCST] Deering, S., R. Hinden, and M. O'dell, "An IPv6 Aggregatable
        Global Unicast Address Format" , RFC2374.

[IPV6]  Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC2460.

[MP-BGP]T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol Exten-
        sions for BGP-4", RFC2858.

[VPN]   Rosen E., Rekhter Y., Brannon S., Chase C., De Clercq J.,
        Hitchin P., Marshall , Srinivasan V., "BGP/MPLS VPNs", draft-
        rosen-rfc2547bis-02.txt (work in progress).

[TRANS] R. Gilligan & E. Nordmark, "Transition Mechanisms for IPv6 Hosts
        and Routers", RFC2893.

[TUNNEL]W. Simpson, "IP in IP Tunneling", RFC1853.

[V6ADDR]Deering, S., and R. Hinden, "IP Version 6 Addressing Architec-
        ture", draft-ietf-ipngwg-addr-arch-v3-02.txt.

[V6VPN] Nguyen T., Gastaud G., Ooms D.,"BGP-MPLS VPN extension for IPv6
        VPN over an IPv4 infrastructure", draft-nguyen-bgp-ipv6-vpn-
        00.txt, October 2000


Authors' Addresses

   Tri T. Nguyen
   Alcatel
   Level 20 Noth Point Tower, 100 Miller Street,
   North Sydney NSW 2060, Australia
   E-mail: tri.t.nguyen@alcatel.com

   Dirk Ooms
   Alcatel
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium
   E-mail: dirk.ooms@alcatel.be

   Gerard Gastaud
   Alcatel
   10 rue Latecoere, BP 57, 78141 Velizy Cedex, France
   E-mail: gerard.gastaud@alcatel.fr




Nguyen                     Expires April 2001                   [Page 5]


Internet Draft   draft-nguyen-ngtrans-bgp-tunnel-00.txt     October 2000


   Jeremy De Clercq
   Alcatel
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium
   E-mail: jeremy.de_clercq@alcatel.be















































Nguyen                     Expires April 2001                   [Page 6]


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