| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on June 5, 2009.
This document describes a mechanism for scalable, tiered Internet routing, called TRIP. The goal of TRIP is to decrease the growth rate of the core Internet routing tables by increasing route aggregation and constraining the propagation of multihoming and traffic engineering routes.
TRIP accomplishes this goal by defining separate routing domains for edge networks and transit networks. All current, non-TRIP-aware networks and nodes are considered part of the transit domain. Edge network domains may be created by deploying TRIP at a domain-boundary routers or within IP (v4 or v6) endpoints.
In addition to defining the basic TRIP mechanism, this document describes an incremental deployment path that provides a means for endpoints in TRIP-enabled edge networks to talk directly to non-TRIP-aware end-points in transit domain. This is accomplished without the need to advertise edge network prefixes in the global routing tables or to create a separate global routing domain for edge network prefixes.
1.
Introduction
2.
Requirements Terminology
3.
TRIP Overview
3.1.
Example of a TRIP-Enabled Edge Network
3.2.
TRIP EID and GLOC Assignment
3.3.
TRIP DNS Configuration
3.4.
Example TRIP Packet Exchange
3.5.
GLOC DNS Record
4.
TRIP IPv6 Destination Option
5.
TRIP Translation Mechanisms
5.1.
Recognized Upper Layer Protocols
5.2.
Comparison to IPv4 NAT
6.
'No Translation Needed' ICMP Message
7.
DBR Transformations for IPv6
7.1.
IPv6 Edge-to-Transit Transformation
7.2.
IPv6 Transit-to-Edge Transformation
7.3.
ICMPv6 Error Handling
8.
TRIP Transformations for IPv4
8.1.
IPv4 Edge-to-Transit Transformation
8.2.
IPv4 Transit-to-Edge Transformation
8.3.
ICMP(v4) Message Handling
9.
Incremental Deployment of TRIP
10.
Security Considerations
11.
IANA Considerations
12.
Acknowledgements
13.
References
13.1.
Normative References
13.2.
Informative References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
The growth rate of the core BGP routing tables has been identified as a serious scaling problem for the Internet [I‑D.iab‑raws‑report] (Meyer, D., “Report from the IAB Workshop on Routing and Addressing,” April 2007.). The core BGP routing tables are growing faster than the number of Internet hosts for several reasons, including: (1) the introduction of IPv6 routes, including IPv6 routes to dual-stack networks that are already represented by IPv4 routes, (2) end-user demand for provider-independent addressing, which reduces the efficiency of route aggregation, and (3) the propagation of multihoming and traffic engineering (VPN) routes into the core BGP routing tables. End user requirements for (2) and (3) are in direct conflict with the route aggregation required for scalable Internet routing. The eFIT document (reference needed) describes this conflict in more detail and makes a sound argument that the number of routes propagated into the DFZ for these reasons can be reduced or eliminated by separating the address space used on transit networks from the address space used on edge networks.
This document describes a mechanism for scalable, tiered Internet routing, called TRIP. The goal of TRIP is to decrease the rate of growth of the core Internet routing tables by increasing route aggregation and constraining the propagation of multihoming and traffic engineering routes. TRIP also makes it possible to eliminate redundant IPv4 and IPv6 routes to dual-stack networks when both protocols are equally available at an edge network's Internet attachment points.
TRIP conceptually divides the IP (v4 and v6) address space into two sets: a set of topologically-assigned Global LOCators (GLOCs) that are used for routing across transit networks, and a set of provider-independent Endpoint IDentifiers (EIDs) that are used for both routing and end-point identification within TRIP-enabled edge networks. A TRIP-enabled edge network is created by deploying TRIP within one or more domain-boundary routers (DBRs) that create a border between the edge network and its attached transit network(s). TRIP can be implemented entirely within DBRs, without any modifications to endpoints or non-DBR routers.
TRIP can be deployed at any level of the topology, from an individual end node, to an end-user/ISP boundary, to an ISP/ISP boundary. As specified, TRIP creates exactly two addressing and routing domains, the edge network domain and the transit network domain. Further investigation would be required to determine how/if a TRIP-derived mechanism could be used to create more than two domains.
To allow TRIP to be incrementally deployed on individual networks or nodes, TRIP DBRs include mechanisms that allow endpoints on TRIP-enabled networks to communicate directly with non-TRIP-aware endpoints, and vice versa. These mechanisms do have some limitations, but will provide a level of service equal to or better than an IPv4 NAT. Many IPv4 enterprises have determined that such limitations are an acceptable price to pay for provider-independent internal addressing and/or local network topology hiding, both of which can be provided using the TRIP mechanism. A TRIP DBR could also be integrated with a stateful firewall function, creating a boundary router that provides essentially the same set of protections afforded by an IPv4 NAT, with the same or fewer limitations.
| TOC |
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 RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
TRIP is a tiered routing mechanism that divides the Internet into two addressing and routing domains: the transit network domain and the edge network domain. To accomplish this, TRIP conceptually divides the IP (v4 or v6) address space into a set of Global LOCators (GLOCs) that are used for routing within the transit domain, and a set of globally unique Endpoint IDentifiers that are used to globally identify individual endpoints. EIDs can be used for routing only within their local edge networks.
From a TRIP perspective, all of the nodes that are currently attached to the Internet are located in the transit domain, as their IP addresses can be used to route packets across the global Internet. Because their IP addresses can also be used for endpoint identification, their IP addresses currently serve as both GLOCs and EIDs. The incremental deployment of TRIP involves moving individual networks and nodes into the edge routing domain, where they will be represented by separate EIDs and GLOCs, while retaining their ability to communicate with nodes that remain in the transit domain.
The two separate routing domains are connected via Domain Boundary Routers (DBRs) that use the TRIP mechanism to forward packets from the edge network domain onto transit networks and from the transit network domain onto edge network. Except in cases where sufficent IPv4 address space is not available (see below), GBRs maintain a two-way, one-to-one mapping between GLOCs and EIDs.
| TOC |
The diagram below shows a multi-homed TRIP-enabled edge network. The network has two DBRs, connecting the edge network to two different Internet Service Providers (ISPs). The enterprise administrator has chosen to place a server (S) across the transit network/edge network boundary, so that it will be easily accessible from Internet nodes that remain in the transit domain, as well as from nodes in this and other TRIP-enabled edge networks. This example edge network also contains a set of internal routers (R) and hosts (H).
_________________________________________________________
\__ __/
\__ INTERNET __/
\__________________________________________/
^ ^
| ISP #2
ISP #1 TRANSIT
TRANSIT NETWORK
NETWORK v
| _________________________________
TRANSIT v | |
NETWORK +-----+ +-----+ +---+
- - - - - - - - - - - -|-DBR-|- - - - - |-DBR-|- - - | S | - - - -
TRIP-ENABLED +-----+ +-----+ +---+
EDGE | | |
NETWORK ______________|________________|___________|__________
| | |
+---+ +---+ +---+
| R | | R | | R |
+---+ +---+ +---+
| | |
______|______ ______|_______________|______________
| | | | | | | | |
H H H H H H H H H
Figure 1: Multi-homed TRIP-enabled edge network.
| TOC |
Each TRIP-enabled edge network will be assigned at least one globally unique, provider-independent EID prefix. Internal subnet prefixes and EIDs will be allocated from within the EID prefix(es). EIDs will be routable within the local network and can be used globally to identify nodes within the edge network. The EID prefix(es) will not be advertised in the transit domain by either of the edge network's ISPs, and will not be used for routing outside of the edge network.
Each ISP will assign at least one globally unique, globally routable GLOC prefix to the edge network. Although GLOCs will not be allocated directly to the internal network nodes, the GLOC prefix should be large enough to allow a unique GLOC to be associated with each edge network EID. Except in cases were insufficient IPv4 address space is available (see below), each DBR will maintain a two-way, one-to-one mapping between the GLOC(s) and EID(s) associated with each node on its attached edge network(s). In cases where topology hiding is not required, this mapping may be a simple prefix-to-prefix mapping, with the same subnet and host (or IID) values being used for corresponding GLOCs and EIDs.
In the example edge network represented in Figure 1, each node in the edge network will be assigned at least one EID from the local EID prefix. The EID(s) will be assigned directly to each node using a current IP address assignment mechanism, such as manual configuration, DHCP or IPv6 Address Autoconfiguration. The nodes inside the edge nework are unmodified IP nodes, so they will treat the EIDs as their IP addresses.
There will also be at least two GLOC Prefixess assigned to the site, one assigned by ISP #1 (GLOC Prefix #1), and one assigned by ISP #2 (GLOC Prefix #2). The DBR attached to ISP #1 will associate a GLOC from GLOC Prefix #1 with each EID in the edge network, and the DBR attached to ISP #2 will associate a GLOC from GLOC Prefix #2 with each EID in the edge network. ISPs will advertise the GLOC prefixes into the global Internet routing tables (perhaps as part of a larger aggregation), and the GLOCs will be used to route traffic to/from edge network nodes across the global Internet. GLOCs will not be assigned directly to edge network nodes, and they will not be used for identification or routing within the edge network.
The server that is located at the edge network/transit network boundary will be assigned at least one EID from the edge network's EID prefix on its edge network interface. Both GBRs will associate GLOCs with the server's EID(s), as for any other edge network node. However, the server will also be assigned an address from GLOC Prefix #2 which will serve as both the GLOC and the EID for the server's transit network interface. Nodes in the transit network that wish to reach the server will send packets to the server's transit network EID/GLOC for server identification and routing. Nodes within the local edge network will use the server's edge network EID for both identification and routing. Nodes in other TRIP-enabled edge networks will use the server's edge network EID for identification, and their packets will be routed to either one of the GLOCs corresponding to that EID.
| TOC |
The DNS will be configured to return the EIDs in response to A and AAAA record queries for nodes in TRIP-enabled edge networks. The DNS configuration for nodes on transit networks will be unmodified, and the DNS will continue to return IP addresses (which can be used as EIDs and GLOCs) for transit network nodes.
A new DNS record, the GLOC record, is defined below and can be used to map an EID to its corresponding GLOC. For TRIP to function properly, a GLOC record must be configured for each edge network EID, and transit network nodes must not be represented by GLOC records in the DNS.
| TOC |
When a host in a TRIP-enabled edge network chooses to initiate communication with a node outside of the edge network, it will first determine the EID for the destination node, perhaps by performing a DNS look-up. The sending host will construct an IP packet that contains the EID of the remote node as the destination address and the EID of the sending host as the source address. Since the destination address is not on the local subnet, the sending host will forward the packet to its default router. The packet will then be routed normally through the edge network towards the Internet, until it reaches a DBR.
When the DBR receives a packet from an edge network that will be forwarded onto a transit network, it will use its local mapping to determine the local GLOC associated with the source EID. The GBR will also look up the GLOC associated with the destination EID by checking the local cache or, if necessary, by performing a DNS query using the GLOC DNS record defined later in this document.
If the destination GLOC lookup is successful, then the destination node is located in a TRIP-enabled edge network domain. In this case, the GBR will perform an IP-version-dependent SPRINT transformation that will result in the source and destination GLOCs being copied into the source and destination address fields of the outermost IP header, and the original source and destination EIDs being stored elsewhere (either in a tunneled IPv4 header, or in an IPv6 SPRINT Destination Option defined later in this document. The packet will then be forwarded towards the destination GLOC). This will result in the packet traversing a remote GBR, where it will be transformed back into its original form and forwarded to its final destination on an edge network attached to the remote GBR..
If the GLOC look-up is unsuccesful, then the destination node is presumed to be in the transit network domain, where its destination GLOC will be the same as its destination EID. In that case, the GBR performs a different IP-version-dependent transformation that will result in the packet being sent to its original destination EID/GLOC from the source GLOC. Because there will be no remote GBR to reverse the transformation, the local GBR will also modify the next-layer checksums to reflect the new source address in the IP header, and it will replace any source addresses used in upper layer protocols with the source GLOC, so that reply packets can be routed to the correct edge network from the transit domain. This transformation is very similar to the the transformation performed by an IPv4 NAT box.
When a GBR receives a packet with one of its local GLOCs as its destination address, the GBR first determines whether the packet was sent from a remote GBR or from a transit node. If the packet was sent from a remote GBR, the packet will contain all of the information necessary to reverse the IP-version-specific SPRINT transformation and forward the packet to the original destination EID with the IP header in its original form. No changes to the upper layers will be required. In this case, the GBR will also cache the EID-to-GLOC mapping, so that it can be used for return traffic.
If the packet was not sent from a remote GBR, the local GBR uses its internal mapping to map the destination GLOC to the corresponding local EID. It copies the EID into the destination address field of the IP header and performs a NAT-like transformation to adjust the next-layer checksums before forwarding the packet to its final destination.
This mechanism results in a very clean separation between edge network routing domains and the transit network domain. Edge network (EID) prefixes are never adverstised in the transit routing domain, and transit domain (GLOC) prefixes are never advertised within edge networks. With the exception of transit domain nodes whose EIDs and GLOCs are identical, edge network addresses (EIDs) are never used as the source or destination addresses of IP packets being routed through the transit domain, and transit network addresses (GLOCs) are never used as source or destination addresses of IP packets being routed through edge network domains.
| TOC |
Note: This section will define a GLOC DNS records that is used for mapping EIDs to GLOCs if/when I find (or become?) someone with enough DNS clue to write it.
| TOC |
For IPv6 packets, TRIP uses a IPv6 Destination Option to hold the EIDs while the packet is being routed across the transit domain. This option also includes a "Cache Time-To-Live" field that indicates the amount of time, in seconds that a remote DBR should cache the EID to GLOC mapping information contained in this packet.
+ - - - - - - - - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Version|4|T|S|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source EID or GLOC +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination EID or GLOC +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBD: Need to add explanation of destination option fields.
| TOC |
TBD
| TOC |
TBD
| TOC |
TBD
| TOC |
TBD
| TOC |
This section describes how DBRs process IPv6 packets.
| TOC |
When a DBR receives a packet from an edge network that will be forwarded onto the transit network, it performs the following steps:
| TOC |
When a DBR receives an IPv6 packet (typically from the transit network) whose destination address matches one of the DBR's local GLOCs, the DBR will perform the following steps:
| TOC |
| TOC |
Due to protocol and operational difference between IPv4 and IPv6, TRIP operates somewhat differently for IPv4 packets than it does for IPv6.
| TOC |
For IPv4 edge networks, IPv4 addresses are used for EIDs, but GLOCs may be either IPv4 or IPv6 addresses. Because IPv4 does not provide an equivalent to IPv6 destination options, IP-in-IP encapsulation is used between TRIP-enabled IPv4 networks, with the version of the outer IP header being dependent upon the IP version of the GLOC.
More detail TBD.
| TOC |
TBD
| TOC |
| TOC |
TBD
| TOC |
TBD
| TOC |
TBD
| TOC |
Aspects of this work were inspired by earlier work in this area, including: ENCAPS, GSE, HIP [I‑D.ietf‑hip‑base] (Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, “Host Identity Protocol,” October 2007.), SHIM6 [I‑D.ietf‑shim6‑proto] (Nordmark, E. and M. Bagnulo, “Shim6: Level 3 Multihoming Shim Protocol for IPv6,” February 2009.), eFit, and LISP [I‑D.farinacci‑lisp] (Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” March 2009.).
The following people provided advice or review comments that substantially improved this document: TBD.
This document was written using the xml2rfc tool described in RFC 2629 [RFC2629] (Rose, M., “Writing I-Ds and RFCs using XML,” June 1999.).
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC2640] | Curtin, B., “Internationalization of the File Transfer Protocol,” RFC 2640, July 1999 (TXT). |
| TOC |
| [I-D.farinacci-lisp] | Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” draft-farinacci-lisp-12 (work in progress), March 2009 (TXT). |
| [I-D.iab-raws-report] | Meyer, D., “Report from the IAB Workshop on Routing and Addressing,” draft-iab-raws-report-02 (work in progress), April 2007 (TXT). |
| [I-D.ietf-hip-base] | Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, “Host Identity Protocol,” draft-ietf-hip-base-10 (work in progress), October 2007 (TXT). |
| [I-D.ietf-shim6-proto] | Nordmark, E. and M. Bagnulo, “Shim6: Level 3 Multihoming Shim Protocol for IPv6,” draft-ietf-shim6-proto-12 (work in progress), February 2009 (TXT). |
| [RFC2629] | Rose, M., “Writing I-Ds and RFCs using XML,” RFC 2629, June 1999 (TXT, HTML, XML). |
| TOC |
| Margaret Wasserman | |
| Sandstorm Enterprises | |
| 14 Summer St. 4th Floor | |
| Malden, MA 02148 | |
| USA | |
| Phone: | +1 781 333-3213 |
| Email: | mrw@sandstorm.net |
| URI: | http://www.sandstorm.net |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.