Network Working Group M. Wasserman Internet-Draft Sandstorm Enterprises Expires: June 5, 2009 December 2, 2008 Tiered Routing for IPv4 and IPv6 (TRIP) draft-mrw-ram-trip-00.txt Status of this Memo 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. Abstract 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 Wasserman Expires June 5, 2009 [Page 1] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 3. TRIP Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Example of a TRIP-Enabled Edge Network . . . . . . . . . . 5 3.2. TRIP EID and GLOC Assignment . . . . . . . . . . . . . . . 5 3.3. TRIP DNS Configuration . . . . . . . . . . . . . . . . . . 7 3.4. Example TRIP Packet Exchange . . . . . . . . . . . . . . . 7 3.5. GLOC DNS Record . . . . . . . . . . . . . . . . . . . . . 8 4. TRIP IPv6 Destination Option . . . . . . . . . . . . . . . . . 9 5. TRIP Translation Mechanisms . . . . . . . . . . . . . . . . . 9 5.1. Recognized Upper Layer Protocols . . . . . . . . . . . . . 9 5.2. Comparison to IPv4 NAT . . . . . . . . . . . . . . . . . . 9 6. 'No Translation Needed' ICMP Message . . . . . . . . . . . . . 10 7. DBR Transformations for IPv6 . . . . . . . . . . . . . . . . . 10 7.1. IPv6 Edge-to-Transit Transformation . . . . . . . . . . . 10 7.2. IPv6 Transit-to-Edge Transformation . . . . . . . . . . . 11 7.3. ICMPv6 Error Handling . . . . . . . . . . . . . . . . . . 13 8. TRIP Transformations for IPv4 . . . . . . . . . . . . . . . . 13 8.1. IPv4 Edge-to-Transit Transformation . . . . . . . . . . . 14 8.2. IPv4 Transit-to-Edge Transformation . . . . . . . . . . . 14 8.3. ICMP(v4) Message Handling . . . . . . . . . . . . . . . . 14 9. Incremental Deployment of TRIP . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Wasserman Expires June 5, 2009 [Page 2] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 1. Introduction 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]. 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- Wasserman Expires June 5, 2009 [Page 3] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 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. 2. Requirements Terminology 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]. 3. TRIP Overview 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. Wasserman Expires June 5, 2009 [Page 4] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 3.1. Example of a TRIP-Enabled Edge Network 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. 3.2. TRIP EID and GLOC Assignment 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 Wasserman Expires June 5, 2009 [Page 5] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 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, Wasserman Expires June 5, 2009 [Page 6] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 and their packets will be routed to either one of the GLOCs corresponding to that EID. 3.3. TRIP DNS Configuration 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. 3.4. Example TRIP Packet Exchange 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 Wasserman Expires June 5, 2009 [Page 7] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 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. 3.5. GLOC DNS Record 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. Wasserman Expires June 5, 2009 [Page 8] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 4. TRIP IPv6 Destination Option 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. 5. TRIP Translation Mechanisms TBD 5.1. Recognized Upper Layer Protocols TBD 5.2. Comparison to IPv4 NAT TBD Wasserman Expires June 5, 2009 [Page 9] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 6. 'No Translation Needed' ICMP Message TBD 7. DBR Transformations for IPv6 This section describes how DBRs process IPv6 packets. 7.1. IPv6 Edge-to-Transit Transformation When a DBR receives a packet from an edge network that will be forwarded onto the transit network, it performs the following steps: 1. If there is already a TRIP IPv6 Destination Option in the packet, indicating that another DBR has previously processed the packet, the DBR checks the destination GLOC to see if it matches one of the local GLOCs. If the packet is not addressed to one of the DBRs local GLOCs, the DBR forwards the packet onto the transit network without further processing. If the packet is addressed to one of the DBRs local GLOCs, the DBR processes the packet as if it were received from the transit network (see below). 2. The DBR uses its local EID to GLOC mapping information to map the source EID (from the source address field of the IP header) to a GLOC. If this mapping does not succeed, this indicates a configuration problem within the edge network, and the packet will be discarded. ICMP error? 3. The DBR will then attempt to lookup the destination GLOC associated with the destination EID. To accomplish this, the GBR MAY check the local cache to see if it has an existing EID to GLOC mapping for the destination EID (from the destination address of the IP header). If not, it performs a DNS query using the GLOC DNS record to map the destination EID to a destination GLOC. If a GLOC is returned, the GBR MAY cache the implied EID- to-GLOC mapping for the length of time indicated by the TTL in the DNS response. If a DNS response was received indicating that there is no GLOC corresponding to the destination EID, the GBR MAY also cache that information for up to one hour. If no response is received from the DNS query, the packet is processed as if no GLOC was returned, but the result MUST NOT be cached. If the GLOC lookup is successful, the GBR knows that the destination is located in a TRIP-enabled edge network. Otherwise, the GBR assumes that the destination is located in the transit domain, where the destination EID can also be used as the destination GLOC. Wasserman Expires June 5, 2009 [Page 10] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 4. The DBR inserts a TRIP Source IPv6 Destination Option into the packet. It clears the "IPv4" field (sets it to zero) to indicate that the original packet was an IPv6 packet. It copies the original source EID into the "Source EID or GLOC" field and clears the "Source" flag (sets it to 0) to indicate that the "Source EID or GLOC" field currently contains the source EID. It also copies the destination EID into the "Destination EID or GLOC field" and clears the "Destination" flag, to indicate that the "Destination EID or GLOC" currently contains an EID. 5. The GBR copies the source GLOC into the source address field of the IPv6 header. 6. If the packet is being sent to a TRIP-enabled edge network, the GBR copies the destination GLOC into the destination address field of the IPv6 header. The GBR will clear the "Translated" flag in the TRIP Destination Option, because the remote DBR will restore the packet to its original form, so there is no need to modify the next-layer checksums or to translate source addresses in upper layer packets. 7. If the packet is being sent to a destination in the transit domain, the GBR will adjust the next header checksum to compensate for the source address change. If the next header is not recognixed, the checksum will not be changed. It will also translate source addresses used in the upper layer protocol from the original EID to the source GLOC. If an upper layer protocol is not recognized, no translation will be performed. A list of the next and upper layer protocols that TRIP DBRs are required to recognize is included in a later section. If any adjustment or translation has occurred, the DBR will set the "Translated" flag in the TRIP Destination Option to indicate that the packet has been translated to match the new source address. 8. The DBR will forward the resulting packet onto the transit network, where it will be routed using the destination GLOC, which is now the destination address in the IPv6 header. 7.2. IPv6 Transit-to-Edge Transformation 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: 1. The DBR will first determine whether there is a TRIP Destination Option present in the packet. If a TRIP Destination Option is present, that indicates that this packet was sent from a TRIP- enabled edge network. If not, the packet must have been sent Wasserman Expires June 5, 2009 [Page 11] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 from a node in the transit domain. 2. If the TRIP Destination Option is not present, the DBR performs the following steps: * The DBR MAY cache an indication that the IPv6 source address refers to an EID that is located in the transit network domain, or it may refresh the timeout for an existing cache entry for this EID. The resulting cache entry MUST NOT have a lifetime of more than 1 hour. * The DBR looks in its local mapping table to map the destination GLOC (contained in the IPv6 destination address field) to a local EID and copies that EID into the IPv6 destination address field. * If the next header value is recognized, the DBR adjusts the next-layer checksum to reflect the modified destination address and fowards the resulting packet onto the edge network. 3. If the TRIP Destination Option is present, the DBR will peform the following checks to determine how/if the packet should be processed: * The DBR will check the "IPv4" flag to determine if the original packet was an IPv4 packet. If so, the GBR will check the IPv4 destination address to determine if it matches one of the local IPv4 EIDs. If so, the GBR will remove the outer IPv6 header and all associated extension headers and forward the IPv4 packet onto the edge network. * The DBR will check the "Translated" flag in the TRIP Destination Option to mae sure that translation was not performed on this packet. If the flag is set, that indicates that the remote DBR was unaware that the destination was on a TRIP-enabled Edge Network. In this case, the packet is dropped and an ICMP "No Translation Required" message is returned to the IPv6 source address of the packet. * The DBR will check the "Destination flag and the "Destination EID or GLOC" field in the TRIP Destination Option to determine if the field contains an EID that matches the EID prefix assigned to (one of) the GBRs attached edge network(s). the GBR will drop the packet. ICMP error message? Wasserman Expires June 5, 2009 [Page 12] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 4. If the packet has passed all of the previous checks without being dropped or forwarded, the DBR will perform the following steps: * The DBR will check the "Source" flag in the TRIP Destination Option to determine if the source EID is currently stored in the TRIP Destination Option (flag is 0) or in the source address field of the IPv6 packet (flag is 1). The DBR then knows that the source GLOC is stored in the other location. Once the DBR knows which address is which, it MAY cache a GLOC to EID mapping, or refresh an existing cache entry for the mapping, so that the DBR will be able to send return traffic to the source EID without performing a DNS lookup. The lifetime of the cache entry MUST NOT exceed the the length of time indicated by the "Cache TTL" field in the TRIP Destination Option. * The GBR will copy the destination EID into the destination address field of the IPv6 packet. It will store the destination GLOC in the "Destination EID or GLOC" field of the TRIP Destination Option and set the "Destination" flag to indicate that the field currently contains a GLOC. * If the source address field in the IPv6 header currently contains a GLOC, the DBR will copy the source EID into the source address field of the IPv6 packet. It will store the source GLOC in the "Source EID or GLOC" field of the TRIP Destination Option and set the "Source" flag to indicate that the field currently contains a GLOC. * Question: For AH to work properly, would the DBR need to remove the TRIP Source option and the IPv6 Routing Header and restore the Next Header field in the IPv6 header to its original value? * The GBR will resulting packet on to the edge network. 7.3. ICMPv6 Error Handling 8. TRIP Transformations for IPv4 Due to protocol and operational difference between IPv4 and IPv6, TRIP operates somewhat differently for IPv4 packets than it does for IPv6. Wasserman Expires June 5, 2009 [Page 13] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 8.1. IPv4 Edge-to-Transit Transformation 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. 8.2. IPv4 Transit-to-Edge Transformation TBD 8.3. ICMP(v4) Message Handling 9. Incremental Deployment of TRIP TBD 10. Security Considerations TBD 11. IANA Considerations TBD 12. Acknowledgements Aspects of this work were inspired by earlier work in this area, including: ENCAPS, GSE, HIP [I-D.ietf-hip-base], SHIM6 [I-D.ietf-shim6-proto], eFit, and LISP [I-D.farinacci-lisp]. 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]. 13. References Wasserman Expires June 5, 2009 [Page 14] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2640] Curtin, B., "Internationalization of the File Transfer Protocol", RFC 2640, July 1999. 13.2. Informative References [I-D.farinacci-lisp] Farinacci, D., Fuller, V., Oran, D., Meyer, D., and S. Brim, "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-10 (work in progress), November 2008. [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. [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. [I-D.ietf-shim6-proto] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work in progress), February 2008. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Author's Address 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 Wasserman Expires June 5, 2009 [Page 15] Internet-Draft Tiered Routing for IPv4 and IPv6 (TRIP) December 2008 Full Copyright Statement Copyright (C) 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. Intellectual Property 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. Wasserman Expires June 5, 2009 [Page 16]