Internet Research Task Force F. Templin, Ed. (IRTF) Boeing Research & Technology Internet-Draft July 8, 2010 Intended status: Informational Expires: January 9, 2011 The Internet Routing Overlay Network (IRON) draft-templin-iron-08.txt Abstract Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes an Internet Routing Overlay Network for supporting sustainable growth through Provider Independent addressing while requiring no changes to end systems and no changes to the existing routing system. This document is a product of the IRTF Routing Research Group (RRG). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 9, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Templin Expires January 9, 2011 [Page 1] Internet-Draft IRON July 2010 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Internet Routing Overlay Network (IRON) . . . . . . . . . 5 3.1. IR(CP) - IRON Customer Premises Router . . . . . . . . . . 7 3.2. IR(BR) - IRON Border Router . . . . . . . . . . . . . . . 7 3.3. IR(GW) - IRON Gateway . . . . . . . . . . . . . . . . . . 8 4. IRON Organizational Principles . . . . . . . . . . . . . . . . 9 5. IRON Initialization . . . . . . . . . . . . . . . . . . . . . 10 5.1. IR(GW) Initialization . . . . . . . . . . . . . . . . . . 11 5.2. IR(BR) Initialization . . . . . . . . . . . . . . . . . . 11 5.3. IR(CP) Initialization . . . . . . . . . . . . . . . . . . 11 6. IRON Operation . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. IR(CP) Operation . . . . . . . . . . . . . . . . . . . . . 12 6.2. IR(BR) Operation . . . . . . . . . . . . . . . . . . . . . 14 6.3. IR(GW) Operation . . . . . . . . . . . . . . . . . . . . . 14 6.4. IRON Reference Operating Scenarios . . . . . . . . . . . . 15 6.4.1. Both Hosts Within EP-Addressed EUNs . . . . . . . . . 15 6.4.2. Mixed IRON and Non-IRON Hosts . . . . . . . . . . . . 21 6.5. Mobility, Multihoming and Traffic Engineering Considerations . . . . . . . . . . . . . . . . . . . . . . 24 6.5.1. Mobility Management . . . . . . . . . . . . . . . . . 24 6.5.2. Multihoming . . . . . . . . . . . . . . . . . . . . . 25 6.5.3. Inbound Traffic Engineering . . . . . . . . . . . . . 25 6.5.4. Outbound Traffic Engineering . . . . . . . . . . . . . 25 6.6. Renumbering Considerations . . . . . . . . . . . . . . . . 25 6.7. NAT Traversal Considerations . . . . . . . . . . . . . . . 25 7. Additional Considerations . . . . . . . . . . . . . . . . . . 26 8. Related Initiatives . . . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. IRON VPs Over Non-Native Internetworks . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 Templin Expires January 9, 2011 [Page 2] Internet-Draft IRON July 2010 1. Introduction Growth in the number of entries carried in the Internet routing system has led to concerns for unsustainable routing scaling [I-D.narten-radir-problem-statement]. Operational practices such as increased use of multihoming with IPv4 Provider-Independent (PI) addressing are resulting in more and more fine-grained prefixes injected into the routing system from more and more end user networks. Furthermore, the forthcoming depletion of the public IPv4 address space has raised concerns for both increased deaggregation (leading to yet further routing table entries) and an impending address space run-out scenario. At the same time, the IPv6 routing system is beginning to see growth in IPv6 Provider-Aggregated (PA) prefixes [BGPMON] which must be managed in order to avoid the same routing scaling issues the IPv4 Internet now faces. Since the Internet must continue to scale to accommodate increasing demand, it is clear that new routing methodologies and operational practices are needed. Several related works have investigated routing scaling issues and proposed solutions. Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in Increasing Scopes (AIS) [I-D.zhang-evolution] are global routing proposals that introduce routing overlays with Virtual Prefixes (VPs) to reduce the number of entries required in each router's Forwarding Information Base (FIB) and Routing Information Base (RIB). Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) [RFC5720] examines recursive arrangements of enterprise networks that can apply to a very broad set of use case scenarios [I-D.russert-rangers]. In particular, RANGER supports encapsulation and secure redirection by treating each layer in the recursive hierarchy as a virtual non-broadcast, multiple access (NBMA) "link". RANGER is an architectural framework that includes Virtual Enterprise Traversal (VET) [I-D.templin-intarea-vet] and the Subnetwork Adaptation and Encapsulation Layer (SEAL) (including the SEAL Control Message Protocol (SCMP)) [I-D.templin-intarea-seal] as its functional building blocks. This document proposes an Internet Routing Overlay Network (IRON) with goals of supporting sustainable growth while requiring no changes to the existing routing system. IRON borrows concepts from VA, AIS and RANGER, and further borrows concepts from the Internet Vastly Improved Plumbing (Ivip) [I-D.whittle-ivip-arch] architecture proposal along with its associated Translating Tunnel Router (TTR) mobility extensions [TTRMOB]. Indeed, the TTR model to a great degree inspired the IRON mobility architecture design discussed in this document. The Network Address Translator (NAT) traversal techniques adapted for IRON were inspired by the Simple Address Mapping for Premises Legacy Equipment (SAMPLE) proposal Templin Expires January 9, 2011 [Page 3] Internet-Draft IRON July 2010 [I-D.carpenter-softwire-sample]. IRON specifically seeks to provide scalable PI addressing without changing the current BGP [RFC4271] routing system. IRON observes the Internet Protocol standards [RFC0791][RFC2460]. Other network layer protocols that can be encapsulated within IP packets (e.g., OSI/CLNP [RFC1070], etc.) are also within scope. The IRON is a global overlay network routing system comprising Virtual Prefix Companies (VPCs) that own and manage Virtual Prefixes (VPs) from which End User Network (EUN) PI prefixes (EPs) are delegated to customer sites. The IRON is motivated by a growing customer demand for multihoming, mobility management and traffic engineering while using stable PI addressing to avoid network renumbering [RFC4192][RFC5887]. The IRON uses the existing IPv4 and IPv6 global Internet routing systems as virtual links for tunneling inner network protocol packets within outer IPv4 or IPv6 headers (see: Section 3). The IRON requires deployment of a small number of new routers that can often be simple commodity hardware platforms. No modifications to hosts, and no modifications to most routers are required. Note: This document is offered in compliance with Internet Research Task Force (IRTF) document stream procedures [RFC5743]; it is not an IETF product and is not a standard. The views in this document were considered controversial by the IRTF Routing Research Group (RRG) but the RG reached a consensus that the document should still be published. The document will undergo a period of review within the RRG and through selected expert reviewers prior to publication. The following sections discuss details of the IRON architecture. 2. Terminology This document makes use of the following terms: End User Network (EUN) an edge network that connects an organization's devices (e.g., computers, routers, printers, etc.) to the Internet and possibly also the IRON. Internet Service Provider (ISP) a service provider which physically connects customer EUNs to the Internet. Templin Expires January 9, 2011 [Page 4] Internet-Draft IRON July 2010 Provider Aggregated (PA) prefix a network layer address prefix delegated to an EUN by a service provider. Provider Independent (PI) prefix a network layer address prefix delegated to an EUN by a third party independently of the EUN's ISP arrangements. Virtual Prefix (VP) a highly-aggregated PI prefix block (e.g., an IPv4 /16, an IPv6 /20, etc.) that is owned and managed by a Virtual Prefix Company (VPC). Virtual Prefix Company (VPC) a company that owns and manages a set of VPs from which it delegates End User Network PI Prefixes (EPs) to EUNs Master Virtual Prefix database (MVPd) a distributed database that maintains VP-to-locator mappings for all VPs in the IRON. End User Network PI prefix (EP) a more-specific PI prefix derived from a VP (e.g., an IPv4 /28, an IPv6 /56, etc.) and delegated to an EUN by a VPC. EP Address (EPA) a network layer address taken from an EP address range and assigned to the interface of an end system in an EUN. locator an IP address taken from a non-EP address range and assigned to the interface of a router or end system within a public or private network. Locators taken from public IP address spaces are routable within the global Internet while locators taken from private IP address spaces are routable only within the network where the private IP addressing plan is deployed. Internet Routing Overlay Network (IRON) an overlay network configured over the global Internet. The IRON supports routing through encapsulation of inner packets with EPA addresses within outer headers that use locator addresses. 3. The Internet Routing Overlay Network (IRON) The Internet Routing Overlay Network (IRON) consists of IRON Routers (IRs) that use Virtual Enterprise Traversal (VET) and the Subnetwork Encapsulation and Adaptation Layer (SEAL) to encapsulate inner Templin Expires January 9, 2011 [Page 5] Internet-Draft IRON July 2010 network layer packets within outer IP and SEAL headers (see: Figure 1) for transmission over the global Internet. Each such IR connects to the IRON via a VET tunnel virtual interface used for automatic tunneling. +-------------------------+ | Outer IP Header with | ~ locator addresses ~ | (IPv4 or IPv6) | +-------------------------+ | SEAL Header | +-------------------------+ +-------------------------+ | Inner Packet Header | --> | Inner Packet Header | ~ with EP addresses ~ --> ~ with EP addresses ~ | (IPv4, IPv6, OSI, etc.) | --> | (IPv4, IPv6, OSI, etc.) | +-------------------------+ +-------------------------+ | | --> | | ~ Inner Packet Body ~ --> ~ Inner Packet Body ~ | | --> | | +-------------------------+ +-------------------------+ Inner packet before Outer packet after before encapsulation after encapsulation Figure 1: Encapsulation of Inner Packets Within Outer IP Headers The IRON is manifested through a business model in which Virtual Prefix Companies (VPCs) own and manage a set of IRs that are distributed throughout the Internet and serve highly-aggregated Virtual Prefixes (VPs). VPCs delegate sub-prefixes from their VPs which they lease to customers as End User Network PI prefixes (EPs). The customers in turn assign the EPs to their customer premises IRs which connect their End User Networks (EUNs) to the IRON. VPCs may have no affiliation with the ISP networks from which customers obtain their basic connectivity. Therefore, VPCs can open for business and begin serving their customers immediately without the need to coordinate their activities with ISPs or with other VPCs. The IRON requires no changes to end systems and no changes to most routers in the Internet. Instead, the IRON comprises IRs that are deployed either as new platforms or as modifications to existing platforms. IRs may be deployed incrementally without disturbing the existing Internet routing system, and act as waypoints (or "cairns") for navigating the IRON. The functional roles of IRs are described in the following sections. Templin Expires January 9, 2011 [Page 6] Internet-Draft IRON July 2010 3.1. IR(CP) - IRON Customer Premises Router An "IR(CP)" is a Customer Premises router (or host with embedded gateway function) that logically connects the customer's EUNs and their associated EPs to the IRON via tunnels. IR(CP)s obtain EPs from VPCs and use them to number subnets and interfaces within their EUNs. An IR(CP) can be deployed on the same physical platform that also connects the customer's EUNs to its ISPs, but it may also be a separate router or even a singleton end system located within the EUN. (This model applies even if the EUN connects to the ISP via a Network Address Translator (NAT) - see Section 6.7). An IR(CP) connects its EUNs to the IRON via tunnels as shown in Figure 2: .-. ,-( _)-. +--------+ .-(_ (_ )-. | IR(CP) |--(_ ISP ) +---+----+ `-(______)-' | <= T \ .-. .-. u \ ,-( _)-. ,-( _)-. n .-(_ (- )-. .-(_ (_ )-. n (_ Internet ) (_ EUN ) e `-(______)- `-(______)-' l ___ | s => (:::)-. +----+---+ .-(::::::::) | Host | .-(::::::::::::)-. +--------+ (:::: The IRON ::::) `-(::::::::::::)-' `-(::::::)-' Figure 2: IR(EP) Connecting EUN to the IRON 3.2. IR(BR) - IRON Border Router An "IR(BR)" is a Border Router that is managed by a VPC and that provides forwarding and mapping services for the EPs owned by their customer IR(CP)s. In typical deployments, a VPC will deploy many IR(BR)s in a globally-distributed fashion (e.g., see Figure 3) so that IR(CP) clients can discover those that are nearby. IR(BR)s often will require only a single physical network interface, and can be deployed on a variety of hardware platforms ranging from traditional high-end routers to commodity general-purpose processors. Templin Expires January 9, 2011 [Page 7] Internet-Draft IRON July 2010 +--------+ +--------+ | IR(BR) | | IR(BR) | | Boston | | Tokyo | +--------+ +--------+ +--------+ | IR(BR) | ___ | Seattle| (:::)-. +--------+ +--------+ .-(::::::::) | IR(BR) | .-(::::::::::::)-. | Paris | (:::: The IRON ::::) +--------+ `-(::::::::::::)-' +--------+ `-(::::::)-' +--------+ | IR(BR) | | IR(BR) | | Moscow | +--------+ | Sydney | +--------+ | IR(BR) | +--------+ | Cairo | +--------+ Figure 3: IR(VP) Global Distribution Example 3.3. IR(GW) - IRON Gateway An "IR(GW)" is a core router that is managed by a VPC and that acts as a gateway between the IRON and the native public Internet. Each VPC configures one or more IR(GW)s which advertise the company's VPs into the IPv4 and/or IPv6 global Internet BGP routing systems. An IR(GW) may be configured on the same physical platform as an IR(BR), or as a separate standalone platform. The IR(GW) role is depicted in Figure 4: Templin Expires January 9, 2011 [Page 8] Internet-Draft IRON July 2010 ,-( _)-. .-(_ (_ )-. (_ Internet ) `-(______)-' | +----+---+ | IR(GW) | +----+---+ _|_ (:::)-. .-(::::::::) +--------+ .-(::::::::::::)-. +--------+ | IR(BR) | (:::: The IRON ::::) | IR(BR) | +--------+ `-(::::::::::::)-' +--------+ `-(::::::)-' +--------+ | IR(BR) | +--------+ Figure 4: IR(GW) Connecting VPC to Native Internet 4. IRON Organizational Principles The IRON consists of the union of all VPC overlay networks worldwide. Each such overlay network represents a distinct "patch" on the Internet "quilt", where the patches are stitched together by tunnels over the links, routers, bridges, etc that connect the public Internet. When a new VPC overlay network is deployed, it becomes yet another patch on the quilt. The IRON is therefore a composite overlay network consisting of multiple individual patches, where each patch can be discussed independently of all others. Each VPC in the IRON maintains a set of IR(GW)s that connect its overlay network directly to the public IPv4 and/or IPv6 Internets. In particular, if the VPC serves IPv4 VPs the IR(GW)s must configure locator addresses on the public IPv4 Internet, and if the VPC serves IPv6 VPs the IR(GW)s must configure locator addresses on the public IPv6 Internet. Each IR(GW) advertises the VPC's IPv4 VPs into the IPv4 BGP routing system and advertises the VPC's IPv6 VPs into the IPv6 BGP routing system. IR(GW)s will therefore receive packets with EPA destination addresses sent by end systems in the Internet then (re)encapsulate and forward them to the correct EPA-addressed end systems connected to the VPC overlay network. Each VPC also manages a set of IR(BR)s that connect its overlay network directly to the public IPv4 and/or IPv6 Internets the same as Templin Expires January 9, 2011 [Page 9] Internet-Draft IRON July 2010 for IR(GW)s, except that IR(BR)s need not be BGP routers and can often be simple commodity hardware platforms. As such, the IR(BR) and IR(GW) functions can be deployed together on the same physical platform but they will more commonly be deployed on separate platforms to achieve economies of scale. Each IR(BR) maintains a working set of IR(CP)s for which it caches EP-to-IR(CP) mappings in its Forwarding Information Base (FIB). Each IR(BR) also in turn propagates the list of EPs in its working set to each of the VPC's IR(GW)s via a dynamic routing protocol. Each IR(BR) will therefore commonly maintain only partial topology information representing the EPs in its working set, while each IR(GW) will maintain a full EP-to- IR(BR) mapping table that represents reachability information for all EPs in the VPC overlay network. Customers establish IR(CPs) to connect their EUNs to the VPC overlay network. Unlike IR(GW)s and IR(BR)s, IR(CP)s may use private addresses behind one or several layers of NATs. The IR(CP) initially discovers a list of nearby IR(BR)s through an exchange with its VPC. It then forms tunnels with one or more of the IR(BR)s through initial exchanges followed by periodic keepalives, and adds each IR(BR) to its default routers list. When the IR(CP) configures a locator address behind a NAT (or, when the IR(CP) does not configure a locator of the same protocol version of its EPs), it uses encapsulation to forward all packets from its EUNs via one of the IR(BR)s in its default router list. The IR(BR)s in turn will forward the packets further toward their final destination. When the IR(CP) configures a locator on the public Internet with the same protocol version of its EPs, however, it can forward packets with EPA destination addresses directly to the IR(BR)s of its correspondents via encapsulation without involving one of the IR(BR)s in its default router list. (The IR(CP) must instead forward packets with non-EPA destination addresses to an IR(BR) in its default router list via encapsulation to avoid ISP ingress filtering.) The IRON can also be used to support VPs of network layer protocols that cannot be routed natively in the underlying Internetwork (e.g., OSI/CLNP within the public Internet, IPv6 within in IPv4-only private Internetworks, IPv4 within IPv6-only private Internetworks, etc.). In that case, however, the native routing capabilities of the Internetwork cannot be leveraged such that a more rigid structure that depends on a globally-distributed mapping database is required. Further details for support of IRON VPs over non-native Internetworks are discussed in Appendix A. 5. IRON Initialization IRON initialization entails the startup actions of IRs within the VPC Templin Expires January 9, 2011 [Page 10] Internet-Draft IRON July 2010 overlay network and customer EUNs. The following sections discuss these startups procedures. 5.1. IR(GW) Initialization Before its first operational use, each IR(GW) in the VPC company's overlay network is pre-provisioned with the list of VPs that it will serve as well as the locators for all IR(BR)s that also serve the VPs. The IR(GW) is also provisioned with BGP peerings the same as for any BGP router. Upon startup, the IR(GW) engages in BGP routing exchanges with its peers in the IPv4 and/or IPv6 Internets the same as for any BGP router. It then connects to all of the IR(BR)s that service its VPs for the purpose of discovering EP->IR(BR) mappings. After the IR(GW) has thus fully populated its EP->IR(BR) mapping information database, it is said to be "synchronized" wrt its VPs. The IR(GW) then advertises its synchronized VPs into the IPv4 and/or IPv6 Internet BGP routing systems and engages in ordinary packet forwarding operations. 5.2. IR(BR) Initialization Before its first operational use, each IR(BR) in the VPC company's overlay network is pre-provisioned with the list of VPs that it will serve as well as the locators for all IR(GW)s that also serve the VPs. In order to support route optimization, the IR(BR) must also be pre-provisioned with the list of all VPs in the IRON (i.e., and not just the VPs of this VPC) so that it can discern EPA and non-EPA addresses. Upon startup, the IR(BR) connects to all of the IR(GW)s that service its VPs for the purpose of reporting its EP->IR(BR) mappings. The IR(BR) then actively listens for IR(CP) customers which will create a two-way tunnel while registering its EP prefixes. When a new IR(CP) registers its EP prefixes, the IR(BR) informs all IR(GW)s of the new EP additions; when an existing IR(CP) unregisters its EP prefixes, the IR(BR) informs all IR(GW)s of the deletions. 5.3. IR(CP) Initialization Before its first operational use, each IR(CP) must obtain one or more EPs from a VPC along with a certificate and a public/private key pair from the VPC that it can later use to prove ownership of its EPs. This implies that each VPC must run its own key infrastructure to be used only for the purpose of verifying a customer's claimed right to use an EP. Hence, the VPC need not coordinate its key infrastructure with any other organizations. In order to support route Templin Expires January 9, 2011 [Page 11] Internet-Draft IRON July 2010 optimization, the IR(CP) must also be pre-provisioned with the list of all VPs in the IRON (i.e., and not just the VPs of this VPC) so that it can discern EPA and non-EPA addresses. Upon startup, the IR(CP) contacts its VPC (e.g., via a simple client/ server exchange) to discover a list of locators of the company's nearby IR(BRs). (This list is analogous to the ISATAP Potential Router List (PRL) [RFC5214].) The IR(CP) then selects a subset of IR(BR)s from this list and tests them through a qualification procedure. The IR(CP) then registers its EP prefixes with one or more qualified IR(BR)s and adds them to a default router list. 6. IRON Operation Following this IRON initialization, IRs engage in the steady-state process of receiving and forwarding packets. All IRs forward encapsulated packets over the IRON using the mechanisms of VET [I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal], while IR(GW)s and IR(BR)s additionally forward packets to and from the native IPv6 and IPv4 Internets. IRs also use the SEAL Control Message Protocol (SCMP) to coordinate with other IRs, including the process of sending and receiving redirect messages for route optimization. Each IR operates as specified in the following sub- sections. 6.1. IR(CP) Operation During its initialization phase, the IR(CP) qualifies candidate IR(BR)s by sending SEAL Control Message Protocol (SCMP) Router Solicitation (SRS) test messages to elicit SCMP Router Advertisement (SRA) messages. The IR(BR) will include the header of the soliciting SRS message in its SRA message so that the IR(CP) can determine the number of hops along the forward path. The IR(BR) also includes a metric in its SRA messages indicating its current load average so that the IR(CP) can avoid selecting IR(BR)s that are overloaded. The IR(CP) can also measure the round trip time between sending the SRS and receiving the SRA as an indication of round-trip delay. Finally, the IR(CP) examines the SRA messages to determine whether there is a NAT on the path to its candidate IR(BR)s via each of its ISP connections. The IR(CP) determines whether there is a NAT on the path by examining the address and UDP port number in the header of the soliciting SRS message that the IR(BR) will reflect in its SRA messages. If the locator and port number reflected in the SRA messages does not match the locator and port number the IR(CP) uses for tunneling, then the IR(CP) can know that it is behind a NAT. After the IR(CP) determines one or more preferred IR(BR)s, it Templin Expires January 9, 2011 [Page 12] Internet-Draft IRON July 2010 registers its EP-to-locator bindings with the IR(BR)s by sending SRS messages with signed certificates and prefix information to prove ownership of its EPs. The SRS message will elicit an SRA message from the IR(BR) that includes a non-zero default router lifetime and that signifies the establishment of a two-way tunnel. (A zero default router lifetime on the other hand signifies that the IR(BR) is currently unable to establish a two-way tunnel, e.g., due to heavy load.) The IR(CP) should send separate beacons to each IR(BR) via each of its ISP connections in order to establish multiple two-way tunnels for multihoming purposes. After the initial EP-to-locator registrations, the IR(CP) sends periodic SRS beacons to its IR(BR)s to keep its two-way tunnels alive. These beacons need not include signed certificates since prefix proof of ownership was already established in the initial exchange and the SEAL ID in the SEAL header can be used to confirm that the beacon was sent by the correct tunnel far end. If the IR(CP) ceases to receive SRA messages from an IR(BR) via a specific ISP connection, it marks the IR(BR) as unreachable for that locator. If the IR(CP) ceases to receive SRA messages from multiple IR(BR)s via a specific ISP connection, it marks the ISP connection as failed/ failing. The IR(CP) also uses the same SRS/SRA beaconing procedure to inform its IR(BR)s of a change in locator, e.g., due to changing to a new ISP connection during a mobility event. When an end system in an EUN has a packet to send, the packet is forwarded through the EUN via normal routing until it reaches the IR(CP), which then encapsulates the packet and forwards it either to one of its serving IR(BR)s or directly into the public Internet. In particular, if the IR(CP) is located behind a NAT, if the IR(CP) does not configure a locator of the same protocol version as the packet's destination, or if the destination address is a non-EPA address, the IR(CP) encapsulates the packet in an outer header with its locator as the source address and the locator of one of its serving IR(BR)s as the destination address then forwards the encapsulated packet to the IR(BR). Otherwise, the IR(CP) encapsulates the packet in an outer header with its locator as the source address and the destination address of the inner packet copied into the destination address of the outer packet, then forwards the packet into the public Internet via a default or more-specific route. This arrangement will ensure that the encapsulated packet is forwarded toward the final destination while bypassing the IR(CP)'s default routers in order to reduce path stretch. The IR(CP) uses the mechanisms specified in VET and SEAL to encapsulate each forwarded packet. The IR(CP) further uses the SCMP protocol to coordinate with other IRs, including accepting redirect messages that indicate a better next hop. When the IR(CP) receives Templin Expires January 9, 2011 [Page 13] Internet-Draft IRON July 2010 an SCMP redirect, it checks the identification field of the encapsulated message to verify that the redirect corresponds to a packet that it had previously sent and accepts the redirect if there is a match. Thereafter, subsequent packets forwarded by the source IR(CP) will follow a route-optimized path. 6.2. IR(BR) Operation After an IR(BR) is initialized, it responds to SRSs from IR(CP)s by sending SRAs as described in Section 6.1. When the IR(BR) receives an SRS with signed certificates and prefix information, it authenticates the message. If authentication fails, the IR(BR) discards the message. Otherwise, it creates tunnel state for this new IR(CP), records the EPs in its FIB, and records the locator address from the SCMP message as the link-layer address of the next hop. The IR(BR) next sends an SRA message back to the IR(CP) to complete the tunnel establishment. When the IR(BR) receives an encapsulated packet from one of its IR(CP) tunnel endpoints, it decapsulates the packet and examines the inner destination address. If the inner destination address is an EPA, the IR(BR) re-encapsulates the packet, sets the outer source address of the packet to one of its own locator address, sets the outer destination address of the packet to the inner destination address then forwards the encapsulated packet into the native Internet via a default or more-specific route. If the inner destination address is not an EPA, however, the IR(EP) does not re- encapsulate the packet but simply forwards it unencapsulated into the native Internet. When the IR(BR) receives an encapsulated packet from the Internet, if the inner destination address matches an EP in its FIB the IR(BR) 'A' re-encapsulates the packet using VET/SEAL and forwards it to the next-hop IR(CP) 'B' which in turn decapsulates the packet and forwards it to the correct end system in the EUN. If 'B' has left notice with 'A' that it has moved to a new IR(BR) 'C', however, 'A' will instead forward the re-encapsulated packet to 'C' and also send an SCMP redirect message back to the source of the packet. In this way, IR(CP)s can change between IR(BR)s (e.g., due to mobility events) without exposing EPA packets to loss. 6.3. IR(GW) Operation After an IR(GW) has synchronized its VPs (see: Section 5.1) it advertises the full set of the company's VP's into the IPv4 and/or IPv6 Internet BGP routing systems. The VPs will be seen as ordinary routing information in the BGP, and any packets originating from the IPv4 or IPv6 Internet destined to an EPA covered by one of the VPs Templin Expires January 9, 2011 [Page 14] Internet-Draft IRON July 2010 will be forwarded into the VPC's overlay network by an IR(GW). When an IR(GW) receives a packet from the Internet destined to an EPA covered by one of its VPs, it looks in its FIB for a matching EP to discover the locator of a next-hop IR(BR), then examines the packet format. If the packet is not a SEAL-encapsulated packet, the IR(GW) simply encapsulates the packet with its own locator as the outer source address and the locator of the IR(BR) as the outer destination address and forwards the packet to the IR(BR). If the packet is a SEAL-encapsulated packet, however, the IR(GW) sends an SCMP redirect message back to the source of the packet with the locator of the IR(BR) as the redirected target. It then rewrites the outer source address of the packet to one of its own locators, rewrites the outer destination address of the packet to the locator of the IR(BR) and forwards the (re)encapsulated packet to the IR(BR). In this way, the IR(GW) "bends" the initial encapsulated packets of a flow in flight to deflect them toward a correct IR(BR), while subsequent packets in the flow will be sent directly to the IR(BR) after the source receives a redirect. 6.4. IRON Reference Operating Scenarios The IRON is used to support communications when one or both hosts are located within EP-addressed EUNs regardless of whether the EPs are provisioned by the same VPC or by different VPCs . When both hosts are within IRON EUNs, route optimizations that eliminate the IR(GW) from the path are possible. When only one host is within an IRON EUN, however, the IR(GW) cannot be eliminated from the path. The following sections discuss the two scenarios. Note that it is sufficient to discuss the scenarios in a unidirectional fashion, i.e., by tracing packet flows only in the forward direction from the source host to destination host. The reverse direction can be considered separately, and incurs the same considerations as for the forward direction. 6.4.1. Both Hosts Within EP-Addressed EUNs When both hosts are within EP-addressed EUNs, the initial packets of the flow may need to involve an IR(GW) of the destination host but route optimization can eliminate the IR(GW) from the path for subsequent packets. The two sub-scenarios that exist occur based on whether or not the IR(CP) of the source host is behind a NAT (and/or configures a locator of the same version as the packet). The sub- cases are discussed in the following sections. Templin Expires January 9, 2011 [Page 15] Internet-Draft IRON July 2010 6.4.1.1. IR(CP) of Source Host Not Behind a NAT Figure 5 shows the flow of initial packets from host A to host B within two EP-addressed EUNs when the IR(CP) of the source host A configures a locator of the same protocol version as the inner packet and that is routable on the public Internet: ________________________________________ .-( .-. )-. .-( ,-( _)-. )-. .-( +=================+ _ +========+ )-. .( // (_|| Internet|| _) || ). .( // ||-(______)|| vv ). .( // || || +------------+ ). ( // vv || | IR(BR(B))) |====+ ) ( // +------------+ +------------+ \\ ) ( // .-. | IR(GW(B))) | .-. \\ ) ( //,-( _)-. +------------+ ,-( _)-\\ ) ( .||_ (_ )-. / .-(_ (_ ||. ) ( _|| ISP A .) / (redirect) (__ ISP B ||_)) ( ||-(______)-' / `-(______)|| ) ( || | / | vv ) ( +-----+-----+ <=/ +-----+-----+ ) | IR(CP(A)) | | IR(CP(B)) | +-----+-----+ The IRON +-----+-----+ | ( (Overlaid on the native Internet) ) | .-. .-( .-) .-. ,-( _)-. .-(________________________)-. ,-( _)-. .-(_ (_ )-. .-(_ (_ )-. (_ IRON EUN A ) (_ IRON EUN B ) `-(______)-' `-(______)-' | | +---+----+ +---+----+ | Host A | | Host B | +--------+ +--------+ Figure 5: IR(CP) of Source Host Not Behind a NAT In this scenario, host A sends its unencapsulated packets with destination address B on its network interface connected to EUN A. Routing with EUN A will direct the packets to IR(CP(A)) which then uses VET and SEAL to encapsulate them in outer headers with its locator address as the outer source address and B as the outer destination address (i.e., the inner and outer destination address will be the same). Since IR(CP(A)) configures a locator on the public Internet, it simply releases the encapsulated packets into the native Internet via the ISP connection that provided its locator. The ISP will pass the packets without filtering since the (outer) source address is topologically correct. Once the packets have been Templin Expires January 9, 2011 [Page 16] Internet-Draft IRON July 2010 released into the Internet, routing will direct them to the nearest IR(GW) that advertises reachability to a VP that covers destination address B (namely, IR(GW(B))). IR(GW(B)) will receive the encapsulated packets from IR(CP(A)) then check its FIB to discover an entry that covers destination address B with IR(BR(B)) as the next hop. IR(GW(B)) will then issue SCMP redirect messages to inform IR(CP(A)) that IR(BR(B)) is a better next hop (*). IR(GW(B) then rewrites the outer source address of the encapsulated packets to its own locator address and rewrites the destination address of the encapsulated packets to the locator address of IR(BR(B)). IR(BR(B) then releases these (re)encapsulated packets into the native Internet, where routing will direct them to IR(BR(B)). IR(BR(B)) will receive the encapsulated packets from IR(GW(B)) then check its FIB to discover an entry that covers destination address B with IR(CP(B)) as the next hop. IR(BR(B)) then rewrites the outer source address of the packets to its own locator address and rewrites the outer destination address to the locator address of IR(CP(B)). (If IR(CP(B)) is located behind a NAT, then IR(BR(B)) also rewrites the UDP destination port number in the encapsulating header in order to support NAT traversal.) IR(BR(B)) then releases these (re)encapsulated packets into the native Internet, where routing will direct them to IR(CP(B)). IR(CP(B)) will in turn decapsulate the packets and forward the inner packets to host B via EUN B. (*) Note that after the initial flow of packets, IR(CP(A)) will have received one or more SCMP redirect messages from IR(GW(B)) informing it of IR(BR(B)) as a better next hop. Thereafter, IR(CP(A)) will forward its encapsulated packets directly to the locator address of IR(BR(B)) without involving IR(GW(B)) as shown in Figure 6: Templin Expires January 9, 2011 [Page 17] Internet-Draft IRON July 2010 ________________________________________ .-( .-. )-. .-( ,-( _)-. )-. .-( +=============> .-(_ (_ )-.======+ )-. .( // (__ Internet _) || ). .( // `-(______)-' vv ). .( // +------------+ ). ( // | IR(BR(B))) |====+ ) ( // +------------+ \\ ) ( // .-. .-. \\ ) ( //,-( _)-. ,-( _)-\\ ) ( .||_ (_ )-. .-(_ (_ ||. ) ( _|| ISP A .) (__ ISP B ||_)) ( ||-(______)-' `-(______)|| ) ( || | | vv ) ( +-----+-----+ The IRON +-----+-----+ ) | IR(CP(A)) | (Overlaid on the native Internet) | IR(CP(B)) | +-----+-----+ +-----+-----+ | ( ) | .-. .-( .-) .-. ,-( _)-. .-(________________________)-. ,-( _)-. .-(_ (_ )-. .-(_ (_ )-. (_ IRON EUN A ) (_ IRON EUN B ) `-(______)-' `-(______)-' | | +---+----+ +---+----+ | Host A | | Host B | +--------+ +--------+ Figure 6: Non-NATted Scenario After Redirects 6.4.1.2. IR(CP) of Source Host Behind a NAT Figure 7 shows the flow of initial packets from host A to host B within two EP-addressed EUNs when the IR(CP) of the source host A is located behind a NAT, i.e., when it configures a locator that is not routable on the public Internet. In that case, IR(CP) is obliged to forward its packets through one of its serving IR(BR)s since it cannot use its locator as a source address for forwarding packets directly to the native Internet. Note that this scenario also applies to the case when the IR(CP) of source host A cannot configure a locator of the same protocol version as the inner network layer protocol. For example, if the IR(CP) configures only an IPv4 locator, but EUN A uses IPv6 natively, IR(CP) is obliged to forward its packets through a serving IR(BR) as though it were behind a NAT. Templin Expires January 9, 2011 [Page 18] Internet-Draft IRON July 2010 ________________________________________ .-( .-. )-. .-( ,-( _)-. )-. .-( +========+(_ (_ +=====+ )-. .( || (_|| Internet ||_) || ). .( || ||-(______)-|| vv ). .( +--------++--+ || || +------------+ ). ( +==>| IR(BR(A))) | vv || | IR(BR(B))) |====+ ) ( // +------------+ +--++----++--+ +------------+ \\ ) ( // .-. | IR(GW(B))) | .-. \\ ) ( //,-( _)-. +------------+ ,-( _)-\\ ) ( .||_ (_ )-. / .-(_ (_ ||. ) ( _|| ISP A .) / (redirect) (__ ISP B ||_)) ( ||-(______)-' / `-(______)|| ) ( || <> / <> vv ) ( +-----+-----+ <=/ +-----+-----+ ) | IR(CP(A)) | | IR(CP(B)) | +-----+-----+ The IRON +-----+-----+ | ( (Overlaid on the native Internet) ) | .-. .-( .-) .-. ,-( _)-. .-(________________________)-. ,-( _)-. .-(_ (_ )-. .-(_ (_ )-. (_ IRON EUN A ) (_ IRON EUN B ) `-(______)-' `-(______)-' | | +---+----+ +---+----+ | Host A | | Host B | +--------+ +--------+ Figure 7: IR(CP) of Source Host Behind a NAT In this scenario, host A sends its unencapsulated packets with destination address B on its network interface connected to EUN A. Routing with EUN A will direct the packets to IR(CP(A)) which then uses VET and SEAL to encapsulate them in outer headers with its locator address as the outer source address and the locator address of a serving IR(BR) (i.e., IR(BR(A)) as the outer destination address. The encapsulated packet will pass through a NAT, which will rewrite the packet's outer source address and source port according to the NAT state. The NAT will then release the translated packets into the ISP connection that provided its locator (where the packets may undergo multiple additional layers of NAT before being released into the public Internet). The ISP will pass the packets without filtering since the (outer) source address is topologically correct. Once the packets have been released into the native Internet, routing will direct them to IR(BR(A)). IR(BR(A)) receives the encapsulated packets from IR(CP(A)) then Templin Expires January 9, 2011 [Page 19] Internet-Draft IRON July 2010 rewrites the outer source address to its own locator address and rewrites the outer destination address to B (i.e., the inner and outer destination address will be the same). IR(BR(A)) then releases the (re)encapsulated packets into the native Internet, where routing will direct them to IR(GW(B)). IR(GW(B)) will receive the encapsulated packets from IR(BR(A)) then check its FIB to discover an entry that covers destination address B with IR(BR(B)) as the next hop. IR(GW(B)) will then issue SCMP redirect messages to inform IR(BR(A)) that IR(BR(B)) is a better next hop (*). IR(GW(B)) then rewrites the outer source address of the encapsulated packets to its own locator address and rewrites the outer destination address to the locator address of IR(BR(B)). IR(BR(B) then releases these (re)encapsulated packets into the native Internet, where routing will direct them to IR(BR(B)). IR(BR(B)) will receive the encapsulated packets from IR(GW(B)) then check its FIB to discover an entry that covers destination address B with IR(CP(B)) as the next hop. IR(BR(B)) then rewrites the outer source address of the packets to its own locator address and rewrites the outer destination address to the locator address of IR(CP(B)). (If IR(CP(B)) is located behind a NAT, then IR(BR(B)) also rewrites the UDP destination port number in the encapsulating header in order to support NAT traversal.) IR(BR(B)) then releases these (re)encapsulated packets into the native Internet, where routing will direct them to IR(CP(B)). IR(CP(B)) will in turn decapsulate the packets and forward the inner packets to host B via EUN B. (*) Note that after the initial flow of packets, IR(BR(A)) will have received one or more SCMP redirect messages from IR(GW(B)) informing it of IR(BR(B)) as a better next hop. Thereafter, IR(BR(A)) will forward its encapsulated packets directly to the locator address of IR(BR(B)) without involving IR(GW(B)) as shown in Figure 8: Templin Expires January 9, 2011 [Page 20] Internet-Draft IRON July 2010 ________________________________________ .-( .-. )-. .-( ,-( _)-. )-. .-( +====> .-(_ (_ )-.======+ )-. .( || (__ Internet _) || ). .( || `-(______)-' vv ). .( +--------++--+ +------------+ ). ( +==>| IR(BR(A))) | | IR(BR(B))) |====+ ) ( // +------------+ +------------+ \\ ) ( // .-. .-. \\ ) ( //,-( _)-. ,-( _)-\\ ) ( .||_ (_ )-. .-(_ (_ ||. ) ( _|| ISP A .) (__ ISP B ||_)) ( ||-(______)-' `-(______)|| ) ( || <> <> vv ) ( +-----+-----+ The IRON +-----+-----+ ) | IR(CP(A)) | (Overlaid on the native Internet) | IR(CP(B)) | +-----+-----+ +-----+-----+ | ( ) | .-. .-( .-) .-. ,-( _)-. .-(________________________)-. ,-( _)-. .-(_ (_ )-. .-(_ (_ )-. (_ IRON EUN A ) (_ IRON EUN B ) `-(______)-' `-(______)-' | | +---+----+ +---+----+ | Host A | | Host B | +--------+ +--------+ Figure 8: NATted Scenario After Redirects 6.4.2. Mixed IRON and Non-IRON Hosts When one host is within an IRON EUN and the other is in a non-IRON EUN (i.e., one that connects to the native Internet instead of the IRON), the IR elements involved depend on the packet flow directions. Note that the same scenario holds if there is a NAT between the IRON EUN and the native Internet, since communications must always involve one of the IRON EUN's serving IR(BR)s. The cases are described in the following sections: 6.4.2.1. From IRON Host A to Non-IRON Host B Figure 9 depicts the IRON reference operating scenario for packets flowing from Host A in an IRON EUN to Host B in a non-IRON EUN: Templin Expires January 9, 2011 [Page 21] Internet-Draft IRON July 2010 _________________________________________ .-( )-. )-. .-( +-------)----+ )-. .-( | | )-. .( +======>+ IR(BR(A)) +---------------+ ). .( // | | \ ). .( // +--------)---+ \ ). ( // ) \ ) ( // The IRON ) \ ) ( // .-. ) \ .-. ) ( //,-( _)-. ) \ ,-( _)-. ) ( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. ) ( _|| ISP A ) ) (_ | ISP B )) ( ||-(______)-' ) |-(______)-' ) ( || | )-. v | ) ( +-----+ ----+ )-. +-----+-----+ ) | IR(CP(A)) |)-. | Router B | +-----+-----+ +-----+-----+ | ( ) | .-. .-(____________________________________)-. .-. ,-( _)-. ,-( _)-. .-(_ (_ )-. .-(_ (_ )-. (_ IRON EUN A ) (_ non-IRON EUN ) `-(______)-' `-(___B___)-' | | +---+----+ +---+----+ | Host A | | Host B | +--------+ +--------+ Figure 9: From IRON Host A to Non-IRON Host B In this scenario, host A sends its unencapsulated packets with destination address B on its network interface connected to IRON EUN A. Routing with EUN A will direct the packets to IR(CP(A)) which then uses VET and SEAL to encapsulate them in outer headers with its locator address as the outer source address and the locator address of a serving IR(BR) (i.e., IR(BR(A)) as the outer destination address. The ISP will pass the packets without filtering since the (outer) source address is topologically correct. Once the packets have been released into the native Internet, routing will direct them to IR(BR(A)). IR(BR(A)) receives the encapsulated packets from IR(CP(A)) then simply decapsulates them and releases the unencapsulated packets into the native Internet. Once the packets are released into the native Internet, routing will direct them to the final destination B. Templin Expires January 9, 2011 [Page 22] Internet-Draft IRON July 2010 6.4.2.2. From Non-IRON Host B to IRON Host A Figure 9 depicts the IRON reference operating scenario for packets flowing from Host B in an Non-IRON EUN to Host A in an IRON EUN: _______________________________________ .-( )-. )-. .-( +-------)----+ )-. .-( | | )-. .( +=======+ IR(GW(A)) +<--------------+ ). .( // | | \ ). .( vv +--------)---+ \ ). ( +-----------+ ) \ ) ( | IR(BR(A)) | ) \ ) ( +-----------+ ) \ .-. ) ( //,-( _)-. IRON ) \ ,-( _)-. ) ( .||_ (_ )-. ) The Native Internet .-|_ (_ )-. ) ( _|| ISP A ) ) (_ | ISP B )) ( ||-(______)-' ) |-(______)-' ) ( vv | )-. | | ) ( +-----+ ----+ )-. +-----+-----+ ) | IR(CP(A)) |)-. | Router B | +-----+-----+ +-----+-----+ | ( ) | .-. .-(____________________________________)-. .-. ,-( _)-. ,-( _)-. .-(_ (_ )-. .-(_ (_ )-. (_ IRON EUN A ) (_ non-IRON EUN ) `-(______)-' `-(___B___)-' | | +---+----+ +---+----+ | Host A | | Host B | +--------+ +--------+ Figure 10: From Non-IRON Host B to IRON Host A In this scenario, host B sends its unencapsulated packets with destination address A on its network interface connected to IRON EUN B. Routing will direct the packets to IR(GW(A)) which then uses VET and SEAL to encapsulate them in outer headers with its locator address as the outer source address and the locator address of a serving IR(BR) (i.e., IR(BR(A)) as the outer destination address. IR(GW(A)) will then release the encapsulated packets into the native Internet, where routing will direct them to IR(BR(A)). IR(BR(A)) will receive the encapsulated packets from IR(GW(A)) then check its FIB to discover an entry that covers destination address A with IR(CP(A)) as the next hop. IR(BR(A)) then rewrites the outer Templin Expires January 9, 2011 [Page 23] Internet-Draft IRON July 2010 source address of the packets to its own locator address and rewrites the outer destination address to the locator address of IR(CP(A)). (If IR(CP(A)) is located behind a NAT, then IR(BR(A)) also rewrites the UDP destination port number in the encapsulating header in order to support NAT traversal.) IR(BR(A)) then releases these (re)encapsulated packets into the native Internet, where routing will direct them to IR(CP(A)). IR(CP(A)) will in turn decapsulate the packets and forward the inner packets to host A via EUN A. Note that this scenario always involves an IR(GW(A)) owned by the VPC that provides service to IRON EUN A. This scenario therefore imparts a cost that would need to be borne by either the VPC or its customers. 6.5. Mobility, Multihoming and Traffic Engineering Considerations While IR(BR)s and IR(GW)s can be considered as fixed infrastructure, IR(CP)s may need to move between different network points of attachment, connect to multiple ISPs, or explicitly manage their traffic flows. The following sections discuss mobility, multi-homing and traffic engineering considerations for IR(CP)s. 6.5.1. Mobility Management When an IR(CP) changes its network point of attachment (e.g., due to a mobility event), it configures a new locator. It then asks its VPC (e.g., via a short transaction protocol) for a new list of nearby IR(BR)s. If the IR(CP)'s current list of serving IR(BR)s are also included in the new list received from the VPC, this serves as indication that the IR(CP) has not moved far enough to warrant changing to a new set of serving IR(BR)s. Otherwise, the IR(CP) may wish to move to a new set of serving IR(BR)s in order to maintain optimal routing. To move to a new set of IR(BR)s, the IR(CP) first engages in the EP registration process with the new set of IR(BR)s and maintains the registrations through periodic SRS/SRA exchanges the same as described in Section 6.1. The IR(CP) then informs its former set of IR(BR)s that it has moved by providing them with the locator addresses of the new IR(BR)s. The IR(CP) then discontinues the SRS/ SRA beaconing process with the former IR(BR)s, which will garbage- collect the stale FIB entries when their lifetime expires. This will allow the former IR(BR)s to redirect existing correspondents to the new set of IR(BR)s so that no packets are lost. Templin Expires January 9, 2011 [Page 24] Internet-Draft IRON July 2010 6.5.2. Multihoming An IR(CP) may register with multiple IR(BR)s via multiple locators. It can assign metrics with its registrations to inform its IR(BR)s of preferred locators, and can select outgoing IR(BR)s and locators according to its local preferences. Multihoming is therefore naturally supported. 6.5.3. Inbound Traffic Engineering An IR(CP) can dynamically adjust the priorities of its prefix registrations with its serving IR(BR)s in order to influence inbound flows of traffic. It can also change between serving IR(BR)s when multiple IR(BR)s are available, but should strive for stability in its IR(BR) selection in order to limit routing churn. 6.5.4. Outbound Traffic Engineering An IR(CP) can register with multiple IR(BR)s via multiple locators. It can therefore select outgoing IR(BR)/locator pairs, e.g., based on current QoS considerations. 6.6. Renumbering Considerations As better link layer technologies and service plans emerge, customers will be motivated to select their service providers through healthy competition between ISPs. If a customer's EUN addresses are tied to a specific ISP, however, the customer may be forced to undergo a painstaking EUN renumbering process if it wishes to changes to a different ISP [RFC4192][RFC5887]. When a customer obtains EP prefixes from a VPC, it can change between ISPs seamlessly and without need to renumber. If the VPC itself applies unreasonable costing structures for use of the EPs, however, the customer may be compelled to seek a different VPC and would again be required to confront a renumbering scenario. The IRON approach to renumbering avoidance therefore depends on VPCs conducting ethical business practices with reasonable rates. 6.7. NAT Traversal Considerations The Internet today consists of a global public IPv4 routing and addressing system with non-IRON EUNs that use either public or private IPv4 addressing. The latter class of EUNs connect to the public IPv4 Internet via Network Address Translators (NATs). When an IR(CP) is located behind a NAT, its selects IR(BR)s using the same procedures as for IR(CP)s with public addresses, i.e., it will send SRS messages to IR(BR)s in order to get SRA messages in return. The Templin Expires January 9, 2011 [Page 25] Internet-Draft IRON July 2010 only requirement is that the IR(CP) must configure its SEAL encapsulation to use a transport protocol that supports NAT traversal, namely UDP. Since the IR(BR) maintains state about its IR(CP) customers, it can discover locator information for each IR(CP) by examining the UDP port number and IPv4 address in the outer headers of SRS messages. When there is a NAT in the path, the UDP port number and IPv4 address in the SRS message will correspond to state in the NAT box and might not correspond to the actual values assigned to the IR(CP). The IR(BR) can then encapsulate packets destined to hosts serviced by the IR(CP) within outer headers that use this IPv4 address and UDP port number. The NAT box will receive the packets, translate the values in the outer headers to match those assigned to the IR(CP), then forward the packets to the IR(CP). 7. Additional Considerations Considerations for the scalability of Internet Routing due to multihoming, traffic engineering and provider-independent addressing are discussed in [I-D.narten-radir-problem-statement]. Route optimization considerations for mobile networks are found in [RFC5522]. 8. Related Initiatives IRON builds upon the concepts RANGER architecture [RFC5720], and therefore inherits the same set of related initiatives. Virtual Aggregation (VA) [I-D.ietf-grow-va] and Aggregation in Increasing Scopes (AIS) [I-D.zhang-evolution] provide the basis for the Virtual Prefix concepts. Internet vastly improved plumbing (Ivip) [I-D.whittle-ivip-arch] has contributed valuable insights, including the use of real-time mapping. The use of IR(BR)s as mobility anchor points is directly influenced by Ivip's associated TTR mobility extensions [TTRMOB]. Numerous publications have proposed NAT traversal techniques. The NAT traversal techniques adapted for IRON were inspired by the Simple Address Mapping for Premises Legacy Equipment (SAMPLE) proposal [I-D.carpenter-softwire-sample]. Templin Expires January 9, 2011 [Page 26] Internet-Draft IRON July 2010 9. IANA Considerations There are no IANA considerations for this document. 10. Security Considerations Security considerations that apply to tunneling in general are discussed in [I-D.ietf-v6ops-tunnel-security-concerns]. Additional considerations that apply also to IRON are discussed in RANGER [RFC5720], VET [I-D.templin-intarea-vet] and SEAL [I-D.templin-intarea-seal]. IR(CP)s require a means for securely registering their EP-to-locator bindings with their VPC. Each VPC provides its customer IR(CP)s with a secure means for registering and re-registering their mappings. 11. Acknowledgements This ideas behind this work have benefited greatly from discussions with colleagues; some of which appear on the RRG and other IRTF/IETF mailing lists. Mohamed Boucadair, Wesley Eddy and Robin Whittle provided review input. 12. References 12.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 12.2. Informative References [BGPMON] net, B., "BGPmon.net - Monitoring Your Prefixes, http://bgpmon.net/stat.php", June 2010. [I-D.carpenter-softwire-sample] Carpenter, B. and S. Jiang, "Legacy NAT Traversal for IPv6: Simple Address Mapping for Premises Legacy Equipment (SAMPLE)", draft-carpenter-softwire-sample-00 (work in progress), June 2010. [I-D.ietf-grow-va] Templin Expires January 9, 2011 [Page 27] Internet-Draft IRON July 2010 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "FIB Suppression with Virtual Aggregation", draft-ietf-grow-va-02 (work in progress), March 2010. [I-D.ietf-v6ops-tunnel-security-concerns] Hoagland, J., Krishnan, S., and D. Thaler, "Security Concerns With IP Tunneling", draft-ietf-v6ops-tunnel-security-concerns-02 (work in progress), March 2010. [I-D.narten-radir-problem-statement] Narten, T., "On the Scalability of Internet Routing", draft-narten-radir-problem-statement-05 (work in progress), February 2010. [I-D.russert-rangers] Russert, S., Fleischman, E., and F. Templin, "Operational Scenarios for IRON and RANGER", draft-russert-rangers-03 (work in progress), June 2010. [I-D.templin-intarea-seal] Templin, F., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", draft-templin-intarea-seal-15 (work in progress), June 2010. [I-D.templin-intarea-vet] Templin, F., "Virtual Enterprise Traversal (VET)", draft-templin-intarea-vet-15 (work in progress), June 2010. [I-D.whittle-ivip-arch] Whittle, R., "Ivip (Internet Vastly Improved Plumbing) Architecture", draft-whittle-ivip-arch-04 (work in progress), March 2010. [I-D.zhang-evolution] Zhang, B. and L. Zhang, "Evolution Towards Global Routing Scalability", draft-zhang-evolution-02 (work in progress), October 2009. [RFC1070] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a subnetwork for experimentation with the OSI network layer", RFC 1070, February 1989. [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Templin Expires January 9, 2011 [Page 28] Internet-Draft IRON July 2010 Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4548] Gray, E., Rutemiller, J., and G. Swallow, "Internet Code Point (ICP) Assignments for NSAP Addresses", RFC 4548, May 2006. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", RFC 5522, October 2009. [RFC5720] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010. [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010. [RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, December 2009. [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010. [TTRMOB] Whittle, R. and S. Russert, "TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem, http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf", August 2008. Appendix A. IRON VPs Over Non-Native Internetworks The IRON architecture leverages the native Internet routing system by providing generally shortest-path routing when EPAs are taken from VPs that are routable. When the VPs are not routable within the native underlying Internetwork, however (e.g., when OSI/NSAP [RFC4548] VPs are used within a private IPv4 Internetwork) packets with EPA addresses covered by the VPs must be carried solely via tunnels within the IRON. In such an environment, the IR(GW) role is Templin Expires January 9, 2011 [Page 29] Internet-Draft IRON July 2010 deprecated since there is no native underlying Internetwork to support VP routing. This restricted model therefore entails only IR(CP)s and IR(BR)s. When IRON VPs are carried over a non-native Internetwork, a global mapping database is required to allow IR(BR)s to map VPs to locators which are assigned to the interfaces of other IR(BR)s. Each such non-routable VP in the IRON must therefore be represented in a globally distributed Master VP database (MVPd). The MVPd is maintained by a globally-managed assigned numbers authority in the same manner as the Internet Assigned Numbers Authority (IANA) currently maintains the master list of all top-level IPv4 and IPv6 delegations. The database can be replicated across multiple servers for load balancing much in the same way that FTP mirror sites are used to manage software distributions. Each VP in the MVPd is encoded as the tuple: "{address family, prefix, prefix-length, FQDN}", where: o "address family" is one of IPv4, IPv6, OSI/CLNP, etc. o "prefix" is the VP, e.g. - 2001:DB8::/32 (IPv6) [RFC3849], 192.2/16 (IPv4) [RFC5737], etc. o "prefix-length" is the length (in bits) of the associated VP o FQDN is a DNS Fully-Qualified Domain Name For each VP entry in the MVPd, the VPC maintains a FQDN in the DNS to map the VP to a list of IR(BR)s that serve it. Other IR(BR)s discover the mappings by resolving the FQDN into a list of resource records. Each resource record corresponds to an individual IR(BR), and encodes the tuple : "{address family, locator, WGS 84 coordinates}" where "address family" is the address family of the locator, "locator" is the routing locator assigned to an IR(BR) interface, and "WGS 84 coordinates" identify the physical location of the IR(BR). Upon startup, each IR(BR) managed by the VPC discovers the full set of VPs for the IRON by reading the MVPd. Each IR(BR) reads the MVPd from a nearby server upon startup time, and periodically checks the server for deltas since the database was last read. Upon reading the MVPd, each IR(BR) resolves the FQDN corresponding to each VP into a list of locators. Each locator is an address that is routable within the underlying Internetwork and assigned to an interface of an IR(BR) that serves the VP. For each VP, each IR(BR) sorts the list of locators to determine a Templin Expires January 9, 2011 [Page 30] Internet-Draft IRON July 2010 priority ranking (e.g., based on distance from the locator) and inserts each "VP->locator" mapping into its FIB in order of priority. The FIB entries must be configured such that packets with destination addresses covered by the VP are forwarded to the corresponding locator using encapsulation of the inner network layer packet in an outer header of a network layer protocol that is routable within the Internetwork. This is accomplished by configuring the routing table entry to use the locator addresses as the L2 address corresponding to an imaginary L3 next-hop address. Note that the VP and locator may be of different address families; hence, possible encapsulations include IPv6-in-IPv4, IPv4-in-IPv6, IPv6-in-IPv6, IPv4-in-IPv4, OSI/CLNP-in-IPv6, OSI/CLNP-in-IPv4, etc. After each IR(BR) reads in the list of VPs and sorts the information accordingly, it is said to be "synchronized with the IRON". Each IR(BR) next installs all EPs derived from its VPs into its FIB based on the mapping information received from the IR(CP)s each of its EUN customers. Author's Address Fred L. Templin (editor) Boeing Research & Technology entire. Box 3707 MC 7L-49 Seattle, WA 98124 USA Email: fltemplin@acm.org Templin Expires January 9, 2011 [Page 31]