IPv6 Operations F. Baker Internet-Draft Cisco Systems Intended status: Informational M. Azinger Expires: April 19, 2007 ARIN AC October 16, 2006 Multihomed IPv6 prefix delegation, aggregation, and distribution draft-baker-v6ops-l3-multihoming-analysis-00 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 April 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document presents IETF commentary to the Registry and ISP communities on how to maximize aggregation while supporting multihoming. Multihomed networks fall broadly into two categories, those that are in some senses comparable to an ISP and those that are simply edge networks or VPNs of edge networks. The best solution for multihoming may be different for these differing categories of networks. Baker & Azinger Expires April 19, 2007 [Page 1] Internet-Draft IPv6 multihoming trade-offs October 2006 Requirements Language 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IETF IPv6 delegation advice history . . . . . . . . . . . . . 4 2.1. On Scalability . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Problems with large routing tables . . . . . . . . . . . . 6 2.3. The desirability of traffic engineering in IP routing . . 7 2.4. IETF historical thought on delegations . . . . . . . . . . 8 3. Tradeoffs in Address Multihomed Prefix delegation and Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Provider-independent prefixes . . . . . . . . . . . . . . 10 3.1.1. Discussion of PI multihoming . . . . . . . . . . . . . 11 3.1.2. Site-multihoming architectural analysis for PI multihoming . . . . . . . . . . . . . . . . . . . . . 11 3.2. Provider-assigned prefixes . . . . . . . . . . . . . . . . 13 3.2.1. Discussion of PA multihoming with multiple advertisements of the PA prefix . . . . . . . . . . . 14 3.2.2. Site-multihoming architectural requirements analysis for PA multihoming with prefix advertisement to multiple providers . . . . . . . . . 16 3.3. Site Multihoming by IPv6 Intermediation (shim6) . . . . . 18 3.3.1. Discussion of PA multihoming with aggregated prefix advertisement . . . . . . . . . . . . . . . . . 19 3.3.2. Site-multihoming architectural requirements analysis for PA multihoming following the shim6 model . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4. Exchange-based addressing . . . . . . . . . . . . . . . . 21 3.4.1. Exchange-based addressing implementation . . . . . . . 22 3.4.2. Enumerability of exchange-based addressing . . . . . . 23 3.4.3. Site-multihoming architectural requirements analysis for exchange-based multihoming . . . . . . . 24 4. IETF recommendations on prefix delegation, aggregation, and filtering . . . . . . . . . . . . . . . . . . . . . . . . 25 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Baker & Azinger Expires April 19, 2007 [Page 2] Internet-Draft IPv6 multihoming trade-offs October 2006 1. Introduction This document attempts to address the question: 'what is the best advice that the IETF can give the Registry and ISP communities on how to maximize IPv6 prefix aggregation while supporting multihoming?' It is, in a sense, an expansion on three pre-existing documents: o IAB/IESG Recommendations on IPv6 Address Allocations to Sites [RFC3177] o Requirements for IPv6 Prefix Delegation [RFC3769] o Architectural Approaches to Multi-homing for IPv6 [RFC4177] Specifically we attempt to include the details and suggestions that these documents are missing, or at least some of them. This is a fairly complex question, because in it the ideals intended by the IETF in the IPv6 addressing architecture meet the business realities that the service providers face, and as is often true in such cases, theory and practical reality diverge. We will also look at the specific requirements that IPv6 Multihoming practices must meet as described in [RFC3582], in terms of redundancy, portability, load sharing, performance, policy, simplicity, transport-layer survivability, impact on DNS, datagram filtering, and scalability; on this last point, one must consider issues related to the impact on routers, impact on hosts, interactions between hosts and the routing system, operations and management, and cooperation between transit providers. Important to note is that there are at least two major types of multihomed edge networks - big ones and small ones. Fortune 500 companies can often be looked upon as an ISP-like central networking service with a number of departmental "customers". They are often geographically distributed, buy services from a variety of global and regional ISPs, and have multiple interconnections to the global Internet. Edge networks that can be viewed in this way are perhaps best treated as if they were ISPs in their own right, which is an argument for allocating them their own Autonomous System Number and IPv6 prefix like an ISP does, and expecting them to communicate with their ISPs using BGP. On the other hand, significant attention has been placed on companies of 50-100 employees and other smaller offices, which predominate the business community. It is relatively unusual for these to multihome at this time, but this is expected to change. For purposes of nomenclature, these smaller companies are referred to as SOHO (small office/home office) networks in this document, which is a wider definition than that term is generally used for, but the alternative of "SOHO plus small-to-medium sized Baker & Azinger Expires April 19, 2007 [Page 3] Internet-Draft IPv6 multihoming trade-offs October 2006 companies" seems cumbersome. The principal characteristics of a "SOHO" network as the term is used here includes a single point of attachment to the Internet and a relatively simple internal structure. Medium-sized companies with a presence in several cities can be thought of as multiple SOHO networks connected by a VPN for the purposes of analysis. The requirements of an ISP-like company and a SOHO-like company are fairly different; one solution for multihoming need not fit all multihomed networks. This document's structure is as follows: o Review the IETF's history of advice to the registries regarding IPv6 prefix delegation, and the underlying theory it is based on, in Section 2, o Attempt to enumerate the trade-offs inherent in various algorithms that are in use or have been proposed in Section 3, and o Make specific recommendations regarding delegation, aggregation, distribution, and filtering in Section 4. 2. IETF IPv6 delegation advice history The IPv6 address space was originally delegated to the IANA by the IETF in [RFC1881]. In that document, the IETF stated that it expected the IANA to further delegate the address space to various entities and serve the needs of the Internet as a service to the community. [RFC2008] gives an overview of the scaling properties of the Internet Routing System, and argues in favor using hierarchical routing to good advantage in it. [RFC3582] similarly gives a concrete discussion of the objectives of the design of IPv4 and IPv6 multihoming. The reader is presumed to be familiar with contents and recommendations of these documents, which are not repeated here. IPv6 differs from IPv4 in the size of an address and the size of a prefix, but follows the same logic in its design. Further to that architecture, the IETF has given other advice, mostly with a view to enabling the widespread deployment of IPv6. 2.1. On Scalability Scaling the Internet is far from the only reason that the IETF worries about prefix count in the default-free zone; avoiding abuse and problems caused by deaggregation are probably even more important. But scaling concerns are important and a common concern. Baker & Azinger Expires April 19, 2007 [Page 4] Internet-Draft IPv6 multihoming trade-offs October 2006 We note that deaggregation of prefixes is often accidental, but note that the operators communities (and notably the CIDR Report) also consider it intentional, and debate whether intentional deaggregation is harmful or not. The IETF has thought long and hard about scalability, but in 355 RFCs and currently-posted Internet Drafts that mention it at this writing, none have seen fit to define the term. The earliest RFC to mention it is RFC 984; the first to give it any sense of parameterization is [RFC1265], which attempts to analyze BGP's performance characteristics and scalability by asking what 'link bandwidth, router memory and router CPU cycles does the BGP protocol consume under normal conditions' and how it constrains the set of protocol participants. That document observes that Since in the steady state the link bandwidth and router CPU cycles consumed by the BGP protocol are dependent only on the stability of the Internet, but are completely independent on [sic] the number of networks that compose the Internet, it follows that BGP should have no scaling problems in the areas of link bandwidth and router CPU utilization, as the Internet grows, provided that the overall stability of the inter-AS connectivity (connectivity between ASs) of the Internet can be controlled. The key attributes that seem to define a 'scalable' addressing architecture include that it o Enables the network to address an arbitrarily large number of systems, o Does so in a manner that is friendly to mobility and other attributes that contribute to the churning of advertisements, o Does so in a manner that is friendly to multihoming, which is to say that it enables edge networks to purchase service from several providers and in so doing optimize their communications solutions, o In that environment limits the amount of memory, computational cycles, and network bandwidth spent on routing to a small fraction of available capacity, and o Enable vendors and network administrators to predict the amount of memory, CPU power, and network bandwidth is required to support the network. From that perspective, while it is common to talk about 'scalability' (usually by way of saying that a protocol or procedure lacks a necessary characteristic to really be 'scalable'), in the absence of Baker & Azinger Expires April 19, 2007 [Page 5] Internet-Draft IPv6 multihoming trade-offs October 2006 a concise definition it may not be helpful. In this document, we will focus on the ability to 'enumerate' the number of routes that must be distributed through BGP and the ability to constrain the advertisement of information to its proper locality, as indicators of scalability. In enumerating the number of routes in the "default-free zone" of the backbone, we will make three assumptions. These are based on statements commonly made, and were suggested by our reviewers, but are otherwise offered without proof. If the reader wishes, he may change the numbers and rerun the calculations for himself. They are: o In 2050, the population of the earth will be approximately 10,000,000,000 souls. o In 2050, we will have one multihomed edge network per population of 1000, distributed throughout the Internet. o In 2050, everyone on the planet will use the Internet as their basic communication system, much as today the planet uses a combination of telephone and postal mail. 2.2. Problems with large routing tables The IETF and at least some operators have repeatedly stated concerns about having a large route table. It might be of value to state why the size of the route table is of concern. The issue is not fundamentally the scaling factors related to BGP routing, although some have raised that concern. Regardless of how routing information is exchanged, three fundamental issues have a per-advertised-prefix impact. They are: o The amount of time that it takes a router to join a network from its initial state and join the converged view of that network is dependent in part on the rate at which it can receive and process the routes advertised to it by its peers. Each prefix advertised requires a certain number of bits on the interconnect, which at the rate of the interconnect implies a certain amount of time. o Additionally, even if the prefix is discarded on receipt, the processing of the prefix requires some amount of information to be stored in router memory to support validation and other processing, and requires some computational resources (time and memory). At this writing, even over high speed optical fiber and with O(200,000) backbone routes, this is non-trivial. Routers that manage backbone routing tables are typically configured with hundreds of megabytes to gigabytes of memory when they support Baker & Azinger Expires April 19, 2007 [Page 6] Internet-Draft IPv6 multihoming trade-offs October 2006 O(10^5) routes; routers with O(10^7) routes would seem to call for tens to hundreds of gigabytes of memory, with the attendant power consumption issues that large memories bring. o Any link or equipment has a certain probability of experiencing an outage, either due to failure, during reconfiguration, or due to an incorrect configuration. Additionally, the BGP Update Report [BGP-UPDATE] indicates that a small percentage of Internet providers have a disproportionately high level of BGP 'chatter', probably due to dysfunctional configuration or policy. We presume that the rate of churn per prefix will not be reduced in the future; if anything, small providers and small edge networks are more likely to have incorrect configurations due to inexperience, raising the churn rate. The larger the number of routes in the backbone, the more stressful this prefix churn is. In can be readily seen that these concerns apply regardless of how many prefixes are in the routing system, and increase in gravity linearly with the increase in the upper bound size of the routing system. In the extreme case, it is possible to build routers that manage individual end system addresses in routing, and both Ethernet switches and MANET routers can be pointed to as examples of such systems. However, neither of these solutions is generally implemented in the Internet backbone for cost and scaling reasons. The logic that takes one there argues in the direction of minimizing the size of the route table. Any delegation, aggregation, distribution,or filtering strategy that increases the number of prefixes ambient in the backbone exacerbate them, and any proposal that reduces the number of prefixes ambient in the system helps to mitigate the concerns. 2.3. The desirability of traffic engineering in IP routing Having just said that the IETF's advice, the registry's advice, and the periodic BGP Update Report argue in favor of maximizing aggregation, ISPs world-wide fail to do this and justify it on the basis of traffic engineering. They advertise longer prefixes than they were allocated with a view to either soliciting traffic and therefore being seen as more valuable by potential bilateral partners and customers, or to manage the ingress point or route of traffic to or within their networks to reduce their own costs. In the IPv4 Internet, this means a large number of /24 prefixes in the backbone that could be usefully aggregated to /20, /19, or shorter. The sense of these operators is that Internet routing is sufficiently robust to handle the load, and the practice improves their business position, so it is something they want to do in the IPv6 backbone as well. This is a matter on which the operators are not of one mind. Baker & Azinger Expires April 19, 2007 [Page 7] Internet-Draft IPv6 multihoming trade-offs October 2006 Theoretically, however, if one of the objectives of Internet layer routing is to engineer traffic loads, then the logical unit of such engineering is the ISP point of presence, not a small sub-prefix of it. One would generally not suggest advertising prefixes outside of a provider's network longer than the prefix assigned to a POP. Doing so may offer the illusion of greater control, but it also increases the risk of the route being filtered out by the peer. 2.4. IETF historical thought on delegations IPv6 is defined in the IPv6 Specification [RFC2460], and its current address architecture is defined in the IP Version 6 Addressing Architecture [RFC4291]. The IETF community believes that the simplest way for the registries to manage the address space and the routing tables in ISPs is to allocate it in block sizes appropriate to an ISP or large enterprise, who will in turn sub-allocate to mid- sized enterprise customers, homes, and small offices (SOHO). The assumptions behind RFC 3177's recommendations are that o The Internet Assigned Numbers Authority (IANA) allocates large blocks to the registries. o Registries in turn allocate large blocks of IPv6 address space to entities that can demonstrate a sufficient reason to have such. o These entities, which may be ISPs or well connected multi-homed edge networks, delegate prefixes from that address space to customers or business units. o These customers and business units in turn subnet their internal networks within the same prefix. o On individual LANs, addresses are either derived automatically, assigned via DHCP, or are assigned manually. In theory, for the typical ISP, this means that it is in a position to (and RIR policy recommends that it) aggregate its own and all of its customer's routing into a single prefix that it advertises beyond itself. As a direct consequence, it can also expect to receive at most a few prefixes in BGP routing for each autonomous system in the Internet, and in addition carry its own internal routing and its customer's routing. At current numbers, this is a very reasonable address table size even if every company that currently has an autonomous system number assigned to it is granted a Provider- Independent IPv6 prefix. It would be approximately 1/10 the size of the current IPv4 routing table as reported in the BGP Update Report [BGP-UPDATE]. Baker & Azinger Expires April 19, 2007 [Page 8] Internet-Draft IPv6 multihoming trade-offs October 2006 There is only one problem. In today's Internet, this strictly hierarchical model is at best naive. Multihoming, the practice of purchasing Internet access from multiple ISPs, wrinkles this simple landscape in at least four ways. 1. The provider-assigned address model originally proposed in [RFC1887] presumes that when a multihomed site obtains Internet connectivity through multiple providers, each provider delegates a prefix to the the multihomed site, and each host within the multihomed site configures or is configured with one address per available prefix. This model, in the presence of ingress filtering as described in [RFC2827], and egress routing as described in [RFC3704], has no fail-over path for traffic bearing a source address that was assigned by an ISP that is currently unreachable by the edge site. 2. Edge networks are not necessarily willing to deploy multiple prefixes delegated by ISPs throughout their networks. As articulated in [RFC3582], they prefer a model in which a single prefix is assigned to the edge network such as is implemented by Provider-Independent Addressing (see Section 3.1) for a set of operational reasons. 3. In this case, one provider assigns a prefix to an edge network and that edge network advertises it to its other upstream providers. The scenario, however, creates connectivity problems for the host. For example, if the prefix is advertised to a given ISP who in turn advertises it upstream, but whose upstream ISP doesn't accept the route, even though the alternate ISP is willing to deliver it, traffic will not be delivered via the alternate route and traffic sent via it may be ingress filtered by the upstream ISP. 4. Assignment of a prefix to each edge network, regardless of who does the assignment, that is individually advertised throughout the backbone yields the specter the number of prefixes distributed by the routing system ballooning, as has happened in the IPv4 Internet. In the very near term, this may be acceptable, but in the long term the issues of a voluminous table loom in that domain as well. These issues are discussed in the RFCs Architectural Approaches to Multi-homing for IPv6 [RFC4177] and Threats Relating to IPv6 Multihoming Solutions [RFC4218], and the Requirements for IPv6 Prefix Delegation [RFC3769]. Baker & Azinger Expires April 19, 2007 [Page 9] Internet-Draft IPv6 multihoming trade-offs October 2006 3. Tradeoffs in Address Multihomed Prefix delegation and Aggregation As discussed in [RFC2008], all addressing that has hope of producing an enumerable set of routes in the backbone supports some form of aggregation model. Three fundamental models have been proposed: o a model associating prefixes with ISPs alone, o a model associating prefixes with ISPs or edge networks as is found in the IPv4 Internet, and o a model allocating prefixes to ISPs, larger edge networks, and to regional exchanges that serve small office/home office (residential or "SOHO") networks, called 'Exchange-based addressing'. Note that each of these models are topological (prefixes are assigned to points in the routing topology) and are hierarchical; they differ in that traditional addressing has been disjoint from any sense of locality, while exchange-based addressing is generally deemed to be in some sense regional. A fourth approach to multihoming, the use of network address translators as is done in the IPv4 network, is not discussed here as it is addressed in other documents and is not the IETF's preferred approach. See [I-D.ietf-v6ops-natpt-to-exprmntl] and [I-D.ietf-v6ops-nap]. 3.1. Provider-independent prefixes [RFC1787] defines the term 'Provider-Independent' (PI) 'Addressing' in the observation that It is important to emphasize that the requirement to maintain topologically significant addresses doesn't need to be applied indiscriminately to all the organizations connected to the Internet -- hierarchical routing requires that most, but not all addresses be topologically significant. For a large organization it could be sufficient if the set of destinations within the organization can be represented within the Internet routing system as a small number of address prefixes, even if these address prefixes are independent of the providers that the organization uses to connect to the Internet ('PI' addresses). The volume of routing information that a large organization would inject into the Internet routing system would be comparable to the (aggregated) routing information associated with a large number of Baker & Azinger Expires April 19, 2007 [Page 10] Internet-Draft IPv6 multihoming trade-offs October 2006 small organizations. Provider-Independent assignment of prefixes is the current standard behavior of the various registries. Some ISPs are acting as Local Internet Registries, assigning prefixes out of their assigned prefixes (regarding which see Section 3.2), but more generally the regional and national registries are assigning prefixes on this model. [RFC3582] could be summarized as saying that any new approach to multihoming needs to be as good as PI addressing, and in addition must scale well in routing. 3.1.1. Discussion of PI multihoming In the IPv6 Internet, if each edge network (including SOHO) is granted a PI prefix and all ISPs are expected to route to it specifically and without aggregation, then the number of prefixes exchanged the Internet backbone must eventually approximate the number of edge networks in the world. Given the stated assumptions (see Section 2.1), this calculates to 10,000,000,000/1,000 or 10,000,000 prefixes. There are various ways to mitigate this, but they each result in a significant fraction of this number. At this point, the gentle reader is encouraged to re-read Section 2.2. These same issues apply to and are amplified by the ISP practice of BGP load balancing, in which some ISPs advertise prefixes to upstream providers in ways that offload the cost of traffic carriage or traffic at hot spots in their own routing to other providers. Since PI Addressing maximizes the number of prefixes advertised in the default-free zone of the backbone, those who have argued against PI address delegation focus hardest on these issues. 3.1.2. Site-multihoming architectural analysis for PI multihoming In response to the points raised in [RFC3582], we observe the following. Fundamentally, we note that the IPv4 Internet uses a combination of PI and PA addressing, and PI addressing is known to work in the IPv4 Internet. [RFC3582] sets PI addressing as the gold standard, and it is widely preferred for edge networks that are comparable to ISPs in size, structure, and attachment. Redundancy: PI addressing, as it does in the IPv4 Internet, clearly shields the multihomed network from failures in individual ISPs through which it advertises its address. Baker & Azinger Expires April 19, 2007 [Page 11] Internet-Draft IPv6 multihoming trade-offs October 2006 Portability: PI addresses, since they are advertised everywhere, are inherently portable. Load sharing: Distribution of traffic by the edge network to its upstreams is at its convenience and according to its policy. Performance: Edge network distribution policies may be made dependent on the perceived performance of its providers without concern. Policy: Traffic may be distributed according to any policy the source network considers relevant. Simplicity: PI prefixes in the IPv6 network are no different than PI prefixes in the IPv4 network from a user-maintainability perspective. It could be argued that they are simpler, due to address auto-configuration. Transport-layer survivability: Since only one prefix is deployed within the edge network, TCP, UDP, and SCTP sessions all have a reasonable expectation of surviving changes in routing. Impact on DNS: DNS lists the address used, as is done in the IPv4 Internet. Datagram filtering: PI addressing facilitates BCP 38 ingress filtering, in that the ISP is cognizant of the addresses used by the edge network, whether this is accomplished through routing or configuration. Scalability-impact on routers: PI addressing has no algorithmic impact on routing functionality. It does not preclude single- homed operation and should interoperate with systems that do not implement routing functionality. However, as noted in Section 3.1.1, there are serious questions regarding the number of prefixes in the Internet backbone if PI addressing is applied to the SOHO environment. The prefix count would have effects on the amount of memory required for routing, which has both cost and power implications, and would require increased amounts of state to be maintained in the network. Scalability-impact on hosts: This approach is backward compatible with current RFCs and requires no host changes. Scalability-interactions between hosts and the routing system: The interaction between hosts and the routing system is defined by [RFC2462] and [RFC3315]. As the proposal is currently deployed, it manifestly requires no change to the system. Baker & Azinger Expires April 19, 2007 [Page 12] Internet-Draft IPv6 multihoming trade-offs October 2006 Scalability-operations and management: It is possible for the staff of a site to monitor and configure the operation of its multihomed routing system using operations confined to the routers in the network. Scalability-cooperation between transit providers: PI addressing does not require inter-provider cooperation, but does require cooperation between the provider and his customer. 3.2. Provider-assigned prefixes The RFCs in which the IETF has commented on this model refer to it as "Provider-Based" [RFC3587], "Provider-Assigned" [RFC4076], and "Provider-Aggregatable" [RFC3582] Addressing. In this document, it will be called PA addressing and may be interpreted in any of those ways. The concept of PA addressing has developed with the IPv6 addressing architecture. It was first described in detail in [RFC2073], refined in [RFC2374], and is now specified in [RFC3587]. A fundamental premise of each of these documents is that routing to the end system from another network involves first routing to the ISP to which the prefix was allocated, and which assigned a more specific prefix to one of its customers; the ISP will in turn route the traffic to its customer. This differs materially from proposals that suggest the use of provider-assigned addressing as another way to achieve the equivalent of a PI prefix by having the customer advertise the same prefix upstream through another ISP. This second model is reported in [RFC4116], which says The site uses PA addresses assigned by a single transit provider. The set of routes covering those PA addresses (the "site route set") is announced or propagated by one or more additional transit providers. The transit provider which assigned the PA addresses (the "primary transit provider") originates a set of routes which cover the site route set. The primary transit provider often originates or propagates the site route set as well as the covering aggregates. The use of PA addresses is applicable to sites whose addressing requirements are not sufficient to meet the requirements for PI assignments by RIRs. However, in the case where the site route set is to be announced or propagated by two or more different transit providers, common operational practice still dictates minimum /24 prefixes, which may be larger than the allocation available to small sites. Baker & Azinger Expires April 19, 2007 [Page 13] Internet-Draft IPv6 multihoming trade-offs October 2006 There have been well-documented examples of sites filtering long- prefix routes which are covered by a transit-providers aggregate... Interestingly, at this writing, the statuses of these documents are 'proposed standard', 'historic', and 'informational'. What started as a standard has become a suggestion, and the ISPs appear to be very interested in using PA addressing as another way to achieve the equivalent of PI addressing as mentioned in the opening paragraph of section 3.1.1.2 of [RFC3582]. Since PA addressing as described in RFCs 2073 and 2374 is incapable of multihoming, for present purposes we will only address the latter discussion. 3.2.1. Discussion of PA multihoming with multiple advertisements of the PA prefix The fundamental argument for multihoming using PA prefixes is that they are not PI and are therefore presumed to be more scalable than PI prefixes. The assumption is that they can be aggregated at least by the first tier of ISPs, and as such need not be advertised throughout the Internet. The assumption, of course, has several weaknesses. The first tier of ISPs, those with truly global scope, do not act as backbones for all traffic. Many routes pass from major regional ISP to major regional ISP - the ISPs which have traditionally been called the second tier. These ISPs are more likely to find it in their interest to not aggregate multihomed routes. Further, [RFC2008] observes that This document expects that when the 'address lending' policy is used by an Internet Registry associated with a provider, the terms and conditions of the loan would be coupled to the service agreement between the provider and the subscribers. That is, if the subscriber moves to another provider, the loan would be canceled. Similarly, [RFC4076] observes in section 3.1 that One of the fundamental principles of IPv6 is that sites receive their IPv6 address allocations from an ISP using provider-assigned (PA) address space. There is currently no provider-independent (PI) address space in IPv6. Therefore, a site changing its ISP must renumber its network. Any such site renumbering will require hosts to reconfigure both their own address and default router settings and their stateless DHCPv6-assigned settings. Baker & Azinger Expires April 19, 2007 [Page 14] Internet-Draft IPv6 multihoming trade-offs October 2006 It may be instructive to imagine what would happen in the event that this policy was not rigorously applied, and a PA prefix remained with the subscriber even after it had terminated its relationship with the assigning provider. In such a case, the prefix would functionally become a PI prefix, with whatever scaling issues a PI prefix has. For PA addressing to be more scalable than PI addressing therefore requires that the address be assigned only while the subscriber subscribes to the ISP that assigned it the prefix; it is otherwise indistinguishable operationally. It also requires that the addresses can be aggregated at some point in the hierarchy and not distributed globally, which is something not true of a PI prefix. This latter assumption is also suspect on another score. In the Internet routing architecture, we route towards the most specific prefix, an algorithm generally called 'longest match first'. Suppose that the subscriber in Figure 1 is granted a prefix by ISP A and advertises it to ISP B, but ISP A does not advertise it to its upstream ISP (C) while B does. In that case, either ISP C will accept the prefix from B and route all of the subscriber's traffic through ISP B, or it will not accept it and route none of the subscriber's traffic through ISP B. To provide a multihomed service to the subscriber, ISP C must accept the prefix from both ISPs A and B, and both ISPs A and B must advertise the prefix to ISP C. It has also been noted that the original provider often provides the best route (shortest distance or most widely connected) to its direct customers, meaning that any more specific route is often a lower quality route. ,--------------------. / \ ( ISP C ) \ / `---+------------+---' | | ,--+--. ,--+--. / \ / \ ( ISP A ) ( ISP B ) \ / \ / `--+--' `--+--' | | ,----+------------+----. ( subscriber ) `----------------------' Figure 1: Multihomed Subscriber Several concerns were raised in Section 2.2. In addition, the clear Baker & Azinger Expires April 19, 2007 [Page 15] Internet-Draft IPv6 multihoming trade-offs October 2006 implication is that multi-homed service only really works if upstream providers accept the prefixes and advertise them to their transit providers (even if they don't use them themselves or advertise them to their peers), which implies that if edge networks are predominantly multihomed, the number of prefixes in the global route table approximates at best an order of magnitude less than in the PI case (which we calculated at 10,000,000,000 backbone prefixes in 2050), and potentially no different than that number. 3.2.2. Site-multihoming architectural requirements analysis for PA multihoming with prefix advertisement to multiple providers In response to the questions raised in [RFC3582], we observe the following. Redundancy: PA addressing that mimics PI addressing in the sense of advertising prefixes upstream through multiple providers clearly shields the multihomed network from failures in individual ISPs through which it advertises its address. However, issues with the advertisement of these prefixes upstream have been noted. Portability: PA prefixes are not portable. RIR policy requires that if the edge network leaves the assigning ISP, it return the prefix. Load sharing: PA addressing that mimics PI addressing in the sense of advertising prefixes upstream through multiple providers enables the distribution of traffic by the edge network to its upstreams is at its convenience and according to its policy. Performance: Edge network distribution policies may be made dependent on the perceived performance of its providers without concern. Policy: Traffic may be distributed according to any policy the source network considers relevant. Simplicity: PA prefixes that mimic PI prefixes have a selection of problems with upstream networks, as discussed in [RFC3704]. If the assigning ISP does not advertise the prefix to its upstream but another ISP does, traffic to the edge network will prefer the alternate ISP's route. If an upstream ISP fails to accept the advertised prefix, neither it nor any of its downstream ISPs will participate in the routing of traffic to the edge network, denying it the contracted service. Ingress filtering can also be an issue. Baker & Azinger Expires April 19, 2007 [Page 16] Internet-Draft IPv6 multihoming trade-offs October 2006 Transport-layer survivability: Since only one prefix is deployed within the edge network, TCP, UDP, and SCTP sessions all have a reasonable expectation of surviving changes in routing. Impact on DNS: DNS lists the address used, as is done in the IPv4 Internet. Datagram filtering: PA addressing that mimics PI addressing in the sense of advertising prefixes upstream through multiple providers facilitates BCP 38 ingress filtering, in that the ISP is cognizant of the addresses used by the edge network, whether this is accomplished through routing or configuration. There are potential problems, however, with upstream providers, as discussed in [RFC3704]. Scalability-impact on routers: PA addressing that mimics PI addressing requires no algorithmic impact on routing functionality, although changes have been proposed as in [I-D.van-beijnum-v6ops-pa-mhome-community]. It does not preclude single-homed operation and should interoperate with systems that do not implement routing functionality. However, as noted in Section 3.2.1, there are serious questions regarding the number of prefixes required to be in the Internet backbone if the approach is applied to the SOHO environment. The prefix count would have effects on the amount of memory required for routing, which has both cost and power implications, and would require increased amounts of state to be maintained in the network. Scalability-impact on hosts: This approach is backward compatible with current RFCs and requires no host changes. Scalability-interactions between hosts and the routing system: The interaction between hosts and the routing system is defined by [RFC2462] and [RFC3315]. As the proposal is currently deployed, it manifestly requires no change to the system. Scalability-operations and management: It is possible for the staff of a site to monitor and configure the operation of its multihomed routing system using operations confined to the routers in the network. Scalability-cooperation between transit providers: PA addressing that mimics PI addressing requires some level of inter-provider cooperation, in the sense that a prefix that is a sub-prefix of one allocated by a registry to provider A and advertised upstream by provider B must be accepted by a provider C that is not a party to the agreement between the edge network and its providers. The implications of this are discussed in [RFC3704]. Baker & Azinger Expires April 19, 2007 [Page 17] Internet-Draft IPv6 multihoming trade-offs October 2006 3.3. Site Multihoming by IPv6 Intermediation (shim6) A variation on PA multihoming is in the process of definition by the shim6 working group and may be standardized in the future; the protocol is described in [I-D.ietf-shim6-proto], and there are several related documents discussing address pair selection policy, failure detection and management, and so on. The premise of this is that an edge network obtains PA space from each of several providers and allocates addresses from each provider to each host interface within the network. The question is then which of each system's several addresses is to be used in communications between any two systems, noting that each address pair implies a different route. Datagrams will leave the source network using the ISP that the address is derived from and will be delivered to the destination using the ISP implied by the destination address. For example, in Figure 2, depending on the selection of addresses at a system in the source network, the same datagram might be sent through ISPs A and C, ISPs A and D, ISPs B and C, or ISPs B and D. Imagine, for example, that A<->C was a satellite path each way, A->D was a satellite path while D->A was terrestrial fiber with a long propagation delay, and the links from B<->A and B<->A were shorter; the choice of address prefix pair would clearly have a tremendous impact on round trip delays. ,-----. ,-----. / \ / \ / \ / \ ,---. ( ISP A +---------------+ ISP C ) ,---. / \ \ +. .+ / / \ / +=+ / `. .' \ +=+ \ / \ `-----' `. .' `-----' / \ ; : `. .' ; : | | `.' | | | Source | .' `. |Destination| | | .' `. | | : ; .' `. : ; \ / ,-----. .' `. ,-----. \ / \ +=+ +' `+ +=+ / \ / / \ / \ \ / `---' ( ISP B +---------------+ ISP D ) `---' \ / \ / \ / \ / `-----' `-----' Figure 2: Shim6 PA proposal Baker & Azinger Expires April 19, 2007 [Page 18] Internet-Draft IPv6 multihoming trade-offs October 2006 3.3.1. Discussion of PA multihoming with aggregated prefix advertisement From the perspective of prefix enumeration, this is very attractive; the only prefixes in the backbone are those of ISPs and large edge networks, and the end systems find ways to use those routes to their benefit according to their desires. If, for example, the statistically least mean delay path is important to the Source network's administration or user, it can cache information about the delays incurred by various sessions' address pairs and choose the one that has historically worked the best. If ISP B's service is at a higher cost, it can also try address pairs involving ISP A before trying address pairs involving ISP B. Weaknesses in the approach have also been pointed out, in that it presumes that the edge networks will be willing to renumber (in the sense of deploying address space from each ISP) as it changes contracts with providers, and that the edge network will be willing to pay the cost of the lease of PA space sufficient for its entire company from every ISP it uses. Renumbering technology has been worked out to a certain degree, as documented in [RFC2071], [RFC2894], and [RFC4076]. However, as noted in [RFC4192], the large issues in renumbering relate to human stupidity, against which there is no proof. Renumbering therefore remains a non-trivial effort in large networks, usually because of errors in judgement in application or network design. Some in the operational community believe that portable address space that does not require renumbering upon a change of provider is a customer requirement.If this is the case, the prospects of deploying this architecture are in doubt. 3.3.2. Site-multihoming architectural requirements analysis for PA multihoming following the shim6 model In response to the questions raised in [RFC3582], we observe the following. Redundancy: PA addressing from a host equipped with multiple IPv6 addresses enables a certain level of redundancy, in the sense that SCTP sessions can use multiple addresses and thus survive as long as some connectivity exits. TCP sessions through the failing ISP will be lost, although new TCP sessions originated using other addresses will continue to work. In the event that the multiple addresses consist of one global and one local (ULA or link-local) address, a failure of the ISP supporting the global address will limit the edge network to internal communications, but those internal communications will continue to work. If there are Baker & Azinger Expires April 19, 2007 [Page 19] Internet-Draft IPv6 multihoming trade-offs October 2006 multiple global addresses, the shim6 model allows for session recovery if the other global address is known to the peer system (e.g., if the session has been up long enough for certain exchanges to have taken place). Portability: PA prefixes are not portable. RIR policy requires that if the edge network leaves the assigning ISP, it return the prefix. Load sharing: PA addressing that assigns a different prefix from each upstream, if the upstream filters traffic by source address on ingress, has a selection of problems discussed in [RFC3704]. That RFC also discusses strategies for mitigating the concerns. Performance: As noted previously in this section, PA addressing of this type makes performance estimation an issue that the host has to deal with in its address pair selection algorithms as opposed to an issue dealt with in routing. The host does have the option of selecting address pairs to optimize performance. However, it lacks information on which to base that decision, and so must base it either on cached history, present measurement, or random chance. Policy: Traffic must be distributed according to the routing of the address pair in question. However, address pairs may be selected according to any policy the source network considers relevant. Simplicity: From the perspective of upstream ISPs, PA addressing of this type is transparent and therefore simple. However, the edge network is required to distribute every ISP's prefix through an appropriate subset of its network, and if those subsets are not congruent may encounter anomalies such as having internal systems that share no prefix communicating via the global Internet due to routing. Large networks, such as those of Fortune 1000 companies, are most likely to experience this sort of issue. Transport-layer survivability: [I-D.ietf-shim6-multihome-shim-api] and [I-D.ietf-shim6-proto] describe a mechanism that could be used to enable TCP sessions to be portable across multiple address pairs on systems that implement it. SCTP, which is capable of changing addresses, can also survive. In both cases, host changes (the implementation of the shim6 protocol or the implementation of SCTP) are required to have transport survivability. Impact on DNS: DNS lists the addresses (plural) used, as is done in the IPv4 Internet. IPv6 address-selection algorithms, however, modify the behavior of the DNS resolver to some extent. Rather than selecting a destination address from the list at random, the Baker & Azinger Expires April 19, 2007 [Page 20] Internet-Draft IPv6 multihoming trade-offs October 2006 source may use additional policy such as historical RTTs from various addresses or prefixes in its address selection algorithms or other techniques. Datagram filtering: PA addressing that assigns a different prefix from each upstream facilitates BCP 38 ingress filtering, in that the ISP is cognizant of the addresses used by the edge network, whether this is accomplished through routing or configuration. Scalability-impact on routers: PA addressing that assigns a different prefix from each upstream requires no changes to routing functionality. Since the only prefixes in the network would be those of ISPs and the largest companies, this is the most scalable of the options considered in this note, with a global route table on the order of 10^5 to 10^6 routes. Scalability-impact on hosts: Host changes are required to fully implement the shim6 proposal, but a host that does not implement the changes will still get some service from the network. Scalability-interactions between hosts and the routing system: The interaction between hosts and the routing system is defined by [RFC2462] and [RFC3315]. As the proposal is currently deployed, it manifestly requires no change to the system, although there are proposed changes to the system that would improve its performance. Scalability-operations and management: It is possible for the staff of a site to monitor and configure the operation of its multihomed routing system. The configurations will include router configurations and host configurations, and may include middleware capabilities. Scalability-cooperation between transit providers: PA addressing does not require inter-provider cooperation beyond that present in the IPv4 Internet. 3.4. Exchange-based addressing Several variations on Metropolitan Addressing [METRO] have been proposed. These are generally viewed as "geographic", in the sense that it maps readily to a city, which in turn works with the relevant providers to provide an exchange. Geographic locality is not central to the concept, however; what is central is the notion of a service domain. That domain could as easily be the customers of a cooperative as the citizens of a government. Each of the providers advertises the exchange's prefix to the Internet, accepts (either by protocol or by contract) longer prefixes from subscribers that are within the service domain, and interchanges traffic to other relevant Baker & Azinger Expires April 19, 2007 [Page 21] Internet-Draft IPv6 multihoming trade-offs October 2006 providers appropriately. 3.4.1. Exchange-based addressing implementation One implementation would have the cooperative or regional authority actually operate or contract the operation of a routing interchange point, similar in some respects to the operation of an internet exchange point and possibly co-resident with one. This is a mechanism that [RFC2374] calls "exchange-based aggregation". The interchange point would in fact be an ISP; it would buy transit from some set of providers and sell transit to all of the providers that served multihomed SOHO networks in the service domain. Unlike other ISPs that do this, however, it would advertise a prefix to all of its providers upstream and downstream and (perhaps through them) lease more specific prefixes from that prefix to SOHO networks. These would obtain service from their providers using those more specific prefixes, either advertising them upstream or having their providers behave as if they were on the basis of configuration, and their providers would in turn advertise the prefixes of their customers to the interchange point. Any traffic that comes to the region that is not delivered directly to a customer is delivered to the interchange router, which in turn passes it to the relevant provider. This could occur in a co-location center, for example. Another implementation would have a cooperative or regional authority that assigned the prefixes, as in the first implementation approach, but would have all of the relevant providers directly contract and exchange SOHO routes with each other, and the transit providers among them advertise the exchange's general prefix beyond them using their own AS numbers. In this model, the definition of an "exchange" is more subjective - it exists in the sense that all of the routes are exchanged, although multiple AS numbers are associated with the prefix. This approach has issues in advertisement validation by ISPs not involved in the exchange - they are not likely to believe all of the transit ISPs simultaneously. The two approaches can also be combined. There could be a central exchange as described, and in addition some ISPs choose to exchange SOHO routes through their bilateral links and exchange value directly, bypassing the exchange. The big issue in this approach is exchange of value. The present Internet model lays the burden of datagram transport on the receiver's ISP - traffic goes to that ISP via the least expensive route, and it is required to deliver it. This model inverts that - the sender's ISP determines the route to the interchange point. As such, larger providers tend to carry the burden of transport while smaller providers can often switch a datagram directly from network Baker & Azinger Expires April 19, 2007 [Page 22] Internet-Draft IPv6 multihoming trade-offs October 2006 ingress to the customer. In addition, implementation via bilateral contracts among the carriers constitutes a barrier to entry: while the major carriers very likely already have bilateral interchanges, smaller carriers are forced to purchase transport contracts from all of their larger competitors. As such, anti-competitive behavior or the appearance of it is a serious danger. 3.4.2. Enumerability of exchange-based addressing Given a 2050 world population of 10,000,000,000 (see Section 2.1), addressing of exchanges for regions with populations on the order of one million persons would add approximately 10,000 prefixes to the IPv6 route table and permit multihoming of individual homes or small to medium sized businesses (e.g., SOHO networks). Reducing the presumptive size of the region an exchange could address to 100,000 means that we would add a total of 100,000 globally routed prefixes under the same assumptions. Note that the number of people in the domain is not critical to the concept; numbers are used here for purposes of estimation, not definition. A large region like the megalopolis incorporating California's Ventura, Los Angeles, Riverside, Orange, and San Diego counties might use multiple prefixes or a single very large one, while smaller regions like Edinburgh and its suburbs might use a single smaller prefix. At one multihomed network per 1000 people, a /36 prefix could be subdivided into 4096 /48's, or a /48 prefix assigned to an exchange could be subdivided into 4096 /60 prefixes. At one prefix per 1000 people, either distribution might serve a region containing four million people. The important point here is not the size of an exchange or the prefix it might use, but the concept on which it is based. This suggests that the use of PI addressing for ISPs and larger enterprises with multiple geographically disparate access to the Internet, in concert with some form of exchange-based addressing for the SOHO environment, yields a solution in which backbone route table size is predictable and comparable in size to that of Section 3.3 without the issues it entails. While exchange-based routing requires exchange-based addressing, the opposite isn't true: it would be possible to deploy exchange-based addressing in the relative short term, and hold off implementation of exchange-based routing until such time that the size of the default- free routing table becomes unmanageable without it. Until that happens, exchange-based prefixes will function exactly like regular PI prefixes. The difference is that implementing exchange-based addressing now provides more options in the future. Baker & Azinger Expires April 19, 2007 [Page 23] Internet-Draft IPv6 multihoming trade-offs October 2006 3.4.3. Site-multihoming architectural requirements analysis for exchange-based multihoming In response to the questions raised in [RFC3582], we observe the following. The key point is that exchange-based addressing has many of the same characteristics as a PI address from the edge network's perspective; it differs only in that the address must be released when the edge network leaves the exchange. Redundancy: Exchange-based addressing clearly shields the multihomed network from failures in individual ISPs in the exchange as long as one of its providers survives. Portability: A prefix assigned in this manner is portable among participating providers within the service domain of the exchange, but not across service domain boundaries. Generally, a SOHO that changes address, however, changes IP prefix even it stays with the same provider. Load sharing: Distribution of traffic by the edge network to its upstreams is at its convenience and according to its policy. Performance: Edge network distribution policies may be made dependent on the perceived performance of its providers without concern. Policy: Traffic may be distributed according to any policy the source network considers relevant. Simplicity: Exchange-based prefixes in the IPv6 network are no different than PI prefixes in the IPv4 network from a user- maintainability perspective. It could be argued that they are simpler, due to address auto-configuration. From the ISP's perspective, cooperation within the exchange is necessary. It is not, however, significantly more complex for the ISP than PI addressing, in the sense that the edge network will provide its prefix as a condition of the contract and the ISP will include that prefix in its routing configurations and policies. Transport-layer survivability: Since only one prefix is deployed within the edge network, TCP, UDP, and SCTP sessions all have a reasonable expectation of surviving changes in routing. Impact on DNS: DNS lists the address used, as is done in the IPv4 Internet. Baker & Azinger Expires April 19, 2007 [Page 24] Internet-Draft IPv6 multihoming trade-offs October 2006 Datagram filtering: Exchanged-based addressing facilitates BCP 38 ingress filtering, in that the ISP is cognizant of the addresses used by the edge network, whether this is accomplished through routing or configuration. Scalability-impact on routers: Exchange-based addressing does not change routing technology, although it changes how it is used. Since the only prefixes in the network would be those of ISPs and the largest companies and those corresponding to relatively large regional networks, perhaps related to cities in some sense, this is the second-most scalable approach considered in this note, with a global route table on the order of 10^6 routes. Scalability-impact on hosts: This approach is backward compatible with current RFCs and requires no host changes. Scalability-interactions between hosts and the routing system: The interaction between hosts and the routing system is defined by [RFC2462] and [RFC3315]. As the proposal is currently deployed, it manifestly requires no change to the system. Scalability-operations and management: It is possible for the staff of a SOHO site to monitor and configure the operation of its multihomed routing system using operations confined to the routers in the network. Scalability-cooperation between transit providers: PI addressing does not require inter-provider cooperation with respect to any given customer, apart from using the prefix assigned to the customer by the exchange, but it does require cooperation between each provider and the exchange. To the extent that the "exchange" is implemented via bilateral contracts instead of a central routing system, providers using bilateral relationships must perform in accordance with them. 4. IETF recommendations on prefix delegation, aggregation, and filtering The IETF's first observation is that it is not its place to dictate business rules for ISPs. If anywhere - and the ISPs will hotly dispute even this - it is properly the place of the Regional Internet Registries, ISP associations, and bilateral contracts. What the IETF understands that it is being asked in this context is what the design goals and assumptions are that went into the system, and should be considered in writing those rules. As such, the IETF's advice cannot be summarized as 'allocate, Baker & Azinger Expires April 19, 2007 [Page 25] Internet-Draft IPv6 multihoming trade-offs October 2006 aggregate, and filter at the following fixed prefix lengths' or 'the IETF knows its not its place to dictate a boundary but if a boundary were to be chosen /___ would be suggested'. It must be stated in terms of design guidelines that must in turn be interpreted in the context of the policies and intentions of the registries and ISPs. The design guidelines that the IETF considers most critical are these: o In the general case, the number of prefixes distributed via routing is a direct byproduct of the level of aggregation of prefixes. Since large route tables require more time to exchange than smaller ones and more computation to interpret, smaller route tables - and therefore a higher level of prefix aggregation - are to be preferred over larger ones [RFC2008]. The IETF recommends in the general case that ISPs exchange and filter at the length of prefix delegations from the registry to the ISP. At this writing, the most frequent delegation is a /32, but there are shorter prefixes such as /19 [ARIN-MICRO] [ALLOCSIZE-RIPE] [ALLOCSIZE-LACNIC] [ALLOCSIZE-APNIC], and longer ones such as /48 PI space as well. They SHOULD be announced without further deaggregation and filtered to their allocation length. o Prefixes assigned by registries are not all of the same length. For example, at this writing ARIN is assigning PI prefixes for medium-sized enterprise use at /48, and to ISPs and large enterprises at /32, and some ISPs reportedly have assigned /56 prefixes to their customers. Peer ISPs SHOULD filter prefixes received, and the ISPs announcing them SHOULD provide the means for them to readily do so. o Business considerations will always override general rules in specific cases. As such, an ISP that contractually agrees to accept a PA prefix from a customer that was assigned by another ISP needs to coordinate with that ISP, its own transits, and its own peers, to enable them to properly assess the route. This is mostly easily accomplished through a validation database established by mutual agreement or by a routing mechanism such as the use of a BGP community [I-D.van-beijnum-v6ops-pa-mhome-community] (which will in turn require receiver validation). This will allow the receiving ISP or customer to determine whether it will accept the prefix under its own business rules, and manage its ingress filters in the data plane. However, it SHOULD be understood that even if an ISP accepts a more specific PA prefix from a customer, this cannot be guaranteed to be routed by other transit providers in the chain, which is what makes multihoming as described in Section 3.2 addresses problematic. Baker & Azinger Expires April 19, 2007 [Page 26] Internet-Draft IPv6 multihoming trade-offs October 2006 o For the purposes of origin-filtering policies such as used in Secure Origin BGP [I-D.white-sobgp-architecture], the IETF further recommends that the association of a multi-homed prefix (PA or PI) with an Autonomous System number SHOULD be documented in an appropriate database in the Internet Routing System, perhaps at the allocating registry. o Despite the different policies set in different regions, the routing table is a unique one, shared globally. Any delegation policy SHOULD be widely published in a form that enables ISPs to readily filter announcements to the prefixes that were in fact allocated. o In the event that ISPs agree to advertise prefixes longer than the allocation boundary to each other for traffic engineering purposes, the principles of [RFC2008] and considerations of Section 2.2 remain valid and important. For scalability, the prefixes advertised should be no longer than necessary to accomplish the goal. This document conjectures that the correct unit of advertisement in this case is the prefix assigned to an Internet Point of Presence or POP. In addition, the numbers would suggest that the operational communities seriously consider the deployment of some form of exchange-based addressing for the aggregation of multihomed SOHO prefixes in addition to using PI addressing for ISPs and for ISP- sized organizations that require multihoming. While the use of PA Prefixes for non-multihomed networks remains very promising, the explosion of the route table resulting from using PA prefixes as if they were PI prefixes, as discussed in Section 3.2 will have direct costs to the ISPs in terms of memory, power, and money. 5. IANA Considerations This memo requests no services from the IANA. Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required. From the author's perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion. 6. Security Considerations As discussed, each of the proposed forms of multihoming have advantages and disadvantages. PI multihoming is the "gold standard" by which all others are measured in [RFC3582]. But it has serious Baker & Azinger Expires April 19, 2007 [Page 27] Internet-Draft IPv6 multihoming trade-offs October 2006 scaling difficulties in the sense that it would inject tens of millions of prefixes into the backbone. PA multihoming that mimics PI multihoming suffers from the same issue, and additionally makes the Internet's present routing architecture complex and in some ways unpredictable by the edge network. PA multihoming as described by shim6 is significantly more scalable, but fails to met many of the requirements that service providers believe to be important. Exchange-based addressing is both scalable and generally meets [RFC3582]'s other requirements, but requires changes to the business model of the backbone. This document does not address the protocols or the architecture of that system, but it does make observations regarding the trade-offs in their use. As such, the recommendations do not increase or reduce the security of the architecture or of Internet routing, but when mis-used or mis-applied, problems can result. 7. Acknowledgements This discussion occurred in the IPv6 Operations Working Group, and specifically within a design team that included the authors, Alain Durand, Brian Carpenter, Iljitsch van Beijnum, Jordi Palet Martinez, Kurt Lindqvist, Pekka Savola, Randy Stewart, Thomas Narten, and Tony Hain. Comments were also received from Russ White, Paul Wilson, and Eliot Lear. Miya Kohno orchestrated a very helpful discussion with several Japanese operators, which included Ichiro Mizukoshi, Arifumi Matsumoto, Yasushi Ono, Yasuo Igano, Kuniaki Kondo (JANOG chair), and Akinori Maemura (JPNIC chair). . 8. References 8.1. Normative References [RFC2008] Rekhter, Y. and T. Li, "Implications of Various Address Allocation Policies for Internet Routing", BCP 7, RFC 2008, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. Baker & Azinger Expires April 19, 2007 [Page 28] Internet-Draft IPv6 multihoming trade-offs October 2006 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004. [RFC4177] Huston, G., "Architectural Approaches to Multi-homing for IPv6", RFC 4177, September 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 8.2. Informative References [ALLOCSIZE-APNIC] APNIC, "Allocation sizes within APNIC IPv4 address ranges", . [ALLOCSIZE-LACNIC] LACNIC, "LACNIC - Registration Services", . [ALLOCSIZE-RIPE] RIPE NCC, "RIPE-380 Address Space Managed by the RIPE NCC", . [ARIN-MICRO] ARIN, "ARIN Micro-allocations", . [BGP-UPDATE] Huston, G., "BGP Update Report", . [I-D.ietf-shim6-multihome-shim-api] Komu, M., "Socket Application Program Interface (API) for Multihoming Shim", draft-ietf-shim6-multihome-shim-api-00 (work in progress), October 2006. [I-D.ietf-shim6-proto] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim protocol", draft-ietf-shim6-proto-05 (work in progress), May 2006. [I-D.ietf-v6ops-nap] Velde, G., "IPv6 Network Architecture Protection", draft-ietf-v6ops-nap-03 (work in progress), July 2006. Baker & Azinger Expires April 19, 2007 [Page 29] Internet-Draft IPv6 multihoming trade-offs October 2006 [I-D.ietf-v6ops-natpt-to-exprmntl] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Experimental", draft-ietf-v6ops-natpt-to-exprmntl-03 (work in progress), October 2005. [I-D.van-beijnum-v6ops-pa-mhome-community] Beijnum, I., "BGP Community for PA Multihoming", draft-van-beijnum-v6ops-pa-mhome-community-01 (work in progress), September 2006. [I-D.white-sobgp-architecture] White, R., "Architecture and Deployment Considerations for Secure Origin BGP (soBGP)", draft-white-sobgp-architecture-02 (work in progress), June 2006. [METRO] Deering, S., "Metro-Based Addressing", July 1995, . [RFC1265] Rekhter, Y., "BGP Protocol Analysis", RFC 1265, October 1991. [RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, April 1995. [RFC1881] Internet Architecture Board and Internet Engineering Steering Group, "IPv6 Address Allocation Management", RFC 1881, December 1995. [RFC1887] Rekhter, Y. and T. Li, "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, December 1995. [RFC2071] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997. [RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J. Postel, "An IPv6 Provider-Based Unicast Address Format", RFC 2073, January 1997. [RFC2374] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Baker & Azinger Expires April 19, 2007 [Page 30] Internet-Draft IPv6 multihoming trade-offs October 2006 Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005. [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005. Authors' Addresses Fred Baker Cisco Systems Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Email: fred@cisco.com Baker & Azinger Expires April 19, 2007 [Page 31] Internet-Draft IPv6 multihoming trade-offs October 2006 Marla Azinger ARIN AC Vancouver, Washington 98662 USA Phone: +1-360-816-3034 Email: marla_azinger@czn.com Baker & Azinger Expires April 19, 2007 [Page 32] Internet-Draft IPv6 multihoming trade-offs October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Baker & Azinger Expires April 19, 2007 [Page 33]