INTERNET DRAFT J. De Clercq, G. Gastaud
<draft-ietf-ngtrans-bgp-tunnel-01.txt> T. Nguyen, D. Ooms
Alcatel
S. Prevost
BT
March, 2001
Expires September, 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 (in this
document an IPv6 island typically consists of a number of IPv6 sites
and a Provider Edge (PE) router to which the sites are connected) 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. The IPv6 island needs
one dual stack MP-BGP-speaking edge router, e.g. the PE 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.
Table of Contents
Ooms Expires September 2001 [Page 1]
Internet Draft draft-ietf-ngtrans-bgp-tunnel-01.txt March 2001
1. Introduction
2. Terminology
3. Overview
4. Reference architecture
5. IPv6 Site Prefix Distribution
6. Tunneling
7. PE requirements
8. Comparison to MPLS/BGP VPNs
9. Security considerations
Changes
00->01: editorial changes
extended section 4
1. Introduction
[TRANS] specifies a method to create automatic tunnels by using
IPv4-compatible IPv6 addresses. This method is restricted to the
case in which the destination coincides with the endpoint of the
tunnel (host-to-host or router-to-host tunnels). It has the
disadvantage that it requires an IPv4 address per host.
This document specifies a mechanism for IPv6 islands to communicate
with each other over an IPv4 core network without explicit tunnel
set-up, requiring only one IPv4 address per IPv6 island. The
mechanism is intended as a transition tool used during the period of
co-existence of IPv4 and IPv6.
The method in this document enables automatic tunnels for the
router-to-router case in constrast to the automatic tunneling
described in [TRANS] where the tunnel end-point is the final
destination.
2. Terminology
The terminology of [IPV6] and [TRANS] applies to this document. We
also use some of the terminology of [VPN].
In this document an 'IPv6 island' is an IPv6-upgraded network (which
can be cross-AS). A typical example of one island would be one or
more Customer IPv6 sites connected via their Customer Edge (CE)
router to one dual stack Provider Edge (PE) router.
3. Overview
Dual stack edge routers exchange via MP-BGP IPv6 reachability
Ooms Expires September 2001 [Page 2]
Internet Draft draft-ietf-ngtrans-bgp-tunnel-01.txt March 2001
information with their peers in other IPv6 islands. So, these edge
routers 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 together with reachability
information by MP-BGP, data can be 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. Note that one IPv6 island can contain multiple IPv6
sites.
No extra routes will be injected in the core network by applying this
mechanism.
The hosts in the IPv6 island have native IPv6 addresses. This is
different from e.g. 6to4 [6TO4], which requires that special
addresses (6to4 addresses) are allocated to the IPv6 hosts.
This method can also be looked at as a simplified instantiation of
the general solution proposed for IPv6 VPNs over an IPv4 backbone
[V6VPN].
4. Reference architecture
An ISP providing IPv6 services to some of its customers. However, its
network core has not been upgraded 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 ISP provides
global IPv6 connectivity through its peering relationship with an
upstream ISP, or by peering relationships with other IPv6 ISPs in the
default free routing zone (DFZ).
A dual stack router in the providers network is connected to an
upstream IPv6 ISP or forms part of the IPv6 backbone network, such as
the 6bone. The ISP exchanges IPv6 reachability of its IPv6 allocated
prefix using MP-BGP to its IPv6 upstream provider or into the IPv6
DFZ. The IPv6 prefixes received from the upstream provider or from
the DFZ can be redistributed within the ISP using MP-BGP.
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 router and the PE router for a CE IPv6 site
to exchange its reachability. A customer site may connect to the
Ooms Expires September 2001 [Page 3]
Internet Draft draft-ietf-ngtrans-bgp-tunnel-01.txt March 2001
provider network over more than one interface.
The method in this document can be used for customers that have
already an IPv4 service from the network provider and require an
upgrade to an IPv6 service, as well as for customers that require
only IPv6 connectivity. In both cases the network provider allocates
global IPv6 addresses to the site. It is assumed that all nodes in
the IPv6 island have a global IPv6 address.
5. IPv6 Prefix Distribution
Between a CE and a PE routing protocols are needed to convey IPv6
site prefixes to the ISP and vice versa. 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. Outbound traffic of an IPv6 site is sent to
one of the CE routers (and therefore to the associated PE routers).
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.
6. Tunneling
The use of an IPv4-compatible IPv6 address [V6ADDR] as the MP-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 MP-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).
Ooms Expires September 2001 [Page 4]
Internet Draft draft-ietf-ngtrans-bgp-tunnel-01.txt March 2001
When there are many peers, the number of tunnels could be a concern.
However, there is no state required beyond the MP-BGP state.
Considerations on 'common tunneling techniques' and 'automatic
tunneling techniques' in [TRANS] are valid for the mechanism
described in this document.
7. 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.
8. 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).
9. Security considerations
This proposal can use the security features of BGP and any policy
defined in the ISP domain.
Ooms Expires September 2001 [Page 5]
Internet Draft draft-ietf-ngtrans-bgp-tunnel-01.txt March 2001
References
[6TO4] B. Carpenter, K. Moore, "Connection of IPv6 domains via IPv4
Clouds", RFC3056, February 2001.
[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 Antwerp, Belgium
E-mail: dirk.ooms@alcatel.be
Gerard Gastaud
Alcatel
10 rue Latecoere, BP 57, 78141 Velizy Cedex, France
Ooms Expires September 2001 [Page 6]
Internet Draft draft-ietf-ngtrans-bgp-tunnel-01.txt March 2001
E-mail: gerard.gastaud@alcatel.fr
Jeremy De Clercq
Alcatel
Fr. Wellesplein 1, 2018 Antwerp, Belgium
E-mail: jeremy.de_clercq@alcatel.be
Stuart Prevost
BT
Futures Testbed, B29 Room 136, BT Adastral Park,
Ipswich, Suffolk IP5 3RE, England
E-mail: stuart.prevost@bt.com
Ooms Expires September 2001 [Page 7]
