Internet Draft T. Hain Document: draft-hain-ipv6-pi-addr-use-10.txt Cisco Expires: February 2007 August 2006 Application and Use of the IPv6 Provider Independent Global Unicast Address Format 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 30, 2006. Abstract This document discusses the expected use of the Provider Independent address format discussed in the companion document GEO [1] in the Internet. Several parties have expressed interest in using this approach as a good fit for managing their networks. With the long timeframe that the shim6 effort will take, this approach provides a scalable multi-homing approach for use in the interim. In addition to covering implementations where it adds value in managing the growth of the Internet routing tables, the document will discuss implementations that should be avoided due to the negative impact on the routing tables. Conventions used in this document 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 [2]. Hain Expires - February 2007 1 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format Status of this Memo...............................................1 Abstract..........................................................1 Conventions used in this document.................................1 Introduction......................................................3 History...........................................................4 Site requirements to be provider independent and multi-home:......5 Site scale......................................................6 Current realities.................................................6 Service provider business issues................................6 Operational issues..............................................7 Applicability of the PI format....................................8 Overview of the IPv6 PI Address Format..........................9 Constructive implementations...................................10 Troublesome implementations....................................11 Fundamental Issues...............................................12 Routing issues.................................................12 Example 1:..................................................13 Example 2:..................................................14 Example 3:..................................................15 Exchange Issues..................................................15 Placement......................................................16 Engineering considerations.....................................18 Observations and Considerations..................................19 Address Selection..............................................19 Path Selection.................................................20 Partitioning...................................................21 Renumbering....................................................21 Relationship to telephony addressing model.....................21 General Considerations.........................................22 Recommendations..................................................23 RFC Editor Considerations........................................24 Security Considerations..........................................24 Relationship to the IETF Multi-6 WG multi-homing requirements....24 Redundancy ...................................................25 Load Sharing .................................................25 Performance ..................................................25 Policy .......................................................25 Simplicity ...................................................25 Transport-Layer Survivability ................................25 Impact on DNS ................................................26 Packet Filtering .............................................26 Scalability ..................................................26 Impact on Routers ............................................26 Impact on Hosts ..............................................26 Interaction between hosts & routing system ...................26 Operations and Management ....................................26 Cooperation between Transit Providers ........................26 Multiple Solutions ...........................................27 References.......................................................28 Acknowledgments..................................................29 Author's Addresses...............................................29 Hain Expires - February 2007 2 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format Introduction This document discusses the application of the Provider Independent (PI) global unicast address format for the IPv6 address assignment. This address format is based on WGS-84 [3] derived geographic location. Historically there have been many debates about the value of geographic versus provider based allocation schemes. One interesting observation about this debate is the overriding assumption that the Internet will have to be built using one or the other, rather than leveraging the strengths of each in context. The intent here is not to reopen that debate, but to present the case that with the multiple address capabilities of IPv6 the approaches can be used in a complementary manner. The protracted debate in the RIR policy discussions show that we are no closer to consensus on a Provider Independent (PI) allocation policy than we were five years ago. While the service provider community continues to focus on the threat of routing table meltdown, the global enterprise network managers continue pressing the position that the current IPv6 Provider Aggregate (PA) addressing scheme is unusable by anyone except Internet providers trying to serve the household and small business market. It is clear to all that additional mechanisms will be required to address the needs of large multi-continent organizations, the difficult part is defining who gets a routing slot and who does not in a globally equitable manner. The current PA focus on route aggregation, deals with the technical problems of memory and CPU resource consumption when site attachments conform to the model, but the other significant business issues related to PI approaches remain open. In any case, a site that is expressing an explicit global routing policy will have full- length prefixes announced. The PI address format discussed here does not remove that issue, instead it offers a PI approach for those looking for something more than PA yet less than a global routing slot. Additional work is ongoing in the IETF to separate the roles of an address as the identifier or locator. While this effort might eventually provide alternatives for dealing with multi-homed connections, its outcome is far from certain. Recent charter adjustments have restricted its goals in an effort to achieve any hope of consensus, and even if successful at this scaled back capability the approach will require substantial retrofitting of other aspects of Internet management and security that have been built on the assumption that the roles are combined. Hain Expires - February 2007 3 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format It is frequently assumed that any address format that is not based on provider aggregation will degenerate into the 'swamp' that came to describe pre-CIDR IPv4, with the result that the routing table grows unabated. The goal of this scheme is to allow sites to be independent of any provider, while still allowing aggregation for those who do not require explicit global routing policy. As a result, there will need to be consistently applied rules for when a prefix gets aggregated and when it doesn't. These will be discussed in the recommendations section. This document will highlight the operational configurations where the PI geographic based addresses provide value in provider independence, as well as those situations where they should be avoided in favor of the provider aggregate mechanism. History Provider based address aggregation has its roots in the IPv4 routing table growth limiting effort known as CIDR [4]. The basic premise is that routing entries can be summarized in such a way that a large number of sites, which subscribe to the same service provider, generate a single entry in the global inter-provider routing exchange, also known as the Default Free Zone (DFZ). While this works well when sites connect to a single provider, it is inadequate for providing a site with redundant access through multiple service providers. Sites that expect redundant service through an arbitrary number of service providers currently require the global routing table to carry an explicit entry for the full-length prefix allocated to the site. Traditionally this was accomplished by having a site acquire an address allocation out of the pre-CIDR range of the IPv4 address space, which remained provider independent. Lately this process has evolved into simply arranging with each of the service providers involved for multiple announcements of the explicit prefix allocated to the site by one of those providers. While the effect on the global routing table is the same in either case, the act of 'punching holes' in provider aggregates increases operational complexity, and makes it very difficult for a site to disconnect from the service provider that allocated the address prefix. As noted, the prime motivation for CIDR deployment was reduction on the size of the IPv4 routing table. Using BGP, the total size of the table is a direct function of the number of address aggregates within the Internet, where each entry describes a contiguous set of subnets that share a common origin AS and a common reachability policy. The mechanism, of aligning site allocations with the provider they attached to, worked well for this purpose, but at the same time was directly contrary to the needs of the site for provider and routing policy independence. The primary operational motivation for sites to connect to multiple providers and/or regions is resiliency. Other factors that come into play are managing overall cost, and optimizing performance or balancing load. Hain Expires - February 2007 4 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format Collectively these issues drive sites away from the nicely structured single-connection hierarchical model that is the foundation of IPv6 Provider Aggregatable [5] allocation. At the same time, due to the evolving state of infrastructure deployments, the concepts of geographic locality and least-cost locality often don't match. The consequence of the collective situation is that no one approach to address allocation will solve the entire set of route scaling problems. The goal of the PI address format described in GEO [1] is restoring the integrity of PA prefix format for use by the single homed sites, while simultaneously providing a scaleable approach for the growing number of multi-homed sites. This is accomplished by relating one of the IPv6 address prefixes of the multi-homed sites to an unambiguous geographic reference point in a way that summarizes well over physical distance. This is not an attempt to have routers understand geography. Rather it is simply a mechanism to allocate address prefixes to sites in a way that can be abstracted into a minimum number of routing table entries for routers that are not directly involved in the local topology. This approach has a strong advantage over the IPv4 PI space (which is effectively randomly assigned) in that there is a clear structure that allows for efficient abstractions when the detail is unnecessary. Site requirements to be provider independent and multi-home: Several issues play into the reasons that sites insist on remaining provider independent leading them to multi-home. Beyond the simple uncertainty that any given service provider will still be in business next month, there have been enough widespread outages of various kinds of service over the years to show that trusting any one provider (who is in turn dependent on device suppliers where a single bug can lead to system-wide outages) is problematic. At the same time, the cost of transmission circuits is low enough that it is frequently less expensive to buy Internet access services from two or more providers than to pay any one of them for premium service (history has also shown that even these premium services fail). So in addition to increasing the robustness of the Internet access, these sites frequently end up with more bandwidth for use in the normal case. The details are being documented more completely in other current works, but an overview of the requirements would include: Operational reasons: - Insulation from routing instability striking one upstream provider. - Insulation from local-loop/fiber cuts, or central office equipment failures. - Ability to reduce the points at which outages or packet loss can occur. - Ability to reduce the average number of hops between a network and various important sites. Hain Expires - February 2007 5 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format Business reasons: - Insulation from being held hostage by the ISP when billing or other disputes occur. - The negotiating leverage provided when service provider changes are simply circuit installs and don't involve readdressing. - Risk mitigation to investors and insurers who consider redundant connectivity a business necessity. - Reducing the overhead of continually changing explicitly configured firewalls for inter-enterprise communication. Site scale There are differences between the global enterprise and the small site / telecommuter in terms of multi-homing needs, but not in their goals for provider independence and resiliency. From the perspective that service providers generally prioritize customer restoration (and sometimes the quality of the engineer working the incident) by the size of the circuit, and it would appear that the lowest speed circuits get the worst service. This leads to a state where those with the smallest demand for bandwidth generally perceive the greatest of need to multi-home for reliability. Historically many service providers have used access capacity as a rule-of-thumb in distinguishing the difference in multi-homing requirements for these site types, but with the current deployments of gigabit Ethernet over fiber-to-the-home, bandwidth has become an insufficient measure of a multi-homed site's need to express an explicit policy in the DFZ. As a generalization, the small site / telecommuter simply wants to be always available and internally defaults to any available providers, while the global enterprise expresses an explicit prefix policy (for a variety of reasons including traffic management) by participating in the global BGP exchange. This generalization provides a natural (and more accurate) delineation between the types of multi-homed sites, and the PI mechanism described here exploits this operational characteristic to limit table growth. Current realities Service provider business issues During the push to deploy IPv4 CIDR, a disconnect developed within the service provider community between the operational goal of minimizing the table size through enforced aggregation, and the business goal of giving the customer the services they demand. Over the short term the demonstrable realities of the routing collapses in 1994 and 1996 allowed the operations team to wield the upper hand. In the end though, the self-indulgent business interests have overridden the altruistic sentiments of the 'good of the Internet', as organizations eventually realize that bringing money in the door Hain Expires - February 2007 6 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format will always trump the operational desire to limit growth. The effect of this has been documented in recent studies [6], which show the routing table growth returning to an exponential rate after a few years of linear growth. It is a fairly straightforward process to 'follow the money' and realize that any service provider that wants to survive will propagate a full-length prefix for a customer site into the DFZ. The fundamental reality is that the site paying for service will refuse to let any service provider dictate the business requirements, and the service provider sales staff will respond to that by selling the service that the customer is demanding (in this case, provider independence). Further, many service providers consider it a business obligation to supply a full view of the Internet routing table to the customers that request it for load balancing. To accomplish that, the entire set of long prefixes has to be passed everywhere unless the provider resorts to a default route to someone else. This means that with the current routing technology, service providers will be accepting and passing full length site prefixes as long as they are selling the service of a full default-less view to their customers. Operational issues In the current Internet, service providers frequently have conflicting operational objectives for handling traffic; in their search to minimize internal costs, they look to hand off traffic as quickly as possible. This is colloquially known as 'hot potato' routing, where the holder of the packet is looking to dump it as early as possible, while the potential receivers are looking to avoid being dumped on as long as possible. Since the routers understand policy as described through a longest- match algorithm, the 'Dump Early' strategy wants to hear short prefix lengths, while the 'Avoid Being Dumped On' model drives wide distribution of the longest possible prefix. Given this situation it is in the interest of the service provider whose customer is attempting to influence incoming routes to propagate that multi- homed site prefix as far as possible. The result of this is that only traffic for customer sites will transit the boundary. At the same time, the holders of the packets on the other side of the DFZ would prefer to filter any long prefixes so they can simply dump packets as quickly as possible. The independent policy objective of a global enterprise network then gets injected into this environment of provider conflict. The protocol mechanism for assuring provider independence of a site's specific policies is to distribute the full site prefix list into the DFZ. Since the site's ISP as a receiver is interested in only carrying traffic for that customer, propagating the full length site Hain Expires - February 2007 7 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format prefix is not only self-defensive against dumping, it is aligned with their mutual business interests. Applicability of the PI format A fair question to ask is; if short prefixes through proxy aggregation make no business sense, what mechanism will constrain routing table growth? Currently a single routing protocol is expected to sort all of the contradictory policies to arrive at a perceived optimum from every perspective. In this conflicted environment we are left with a single entity, the originating Autonomous System (AS) number, which is the basis of the various mechanisms used to describe a policy as applied to the listed set of prefixes. There are currently around 22,000 AS numbers actively distributed through the global routing system. Of these, ~ 8,800 are the origin AS for a single IPv4 prefix. The set of AS's which are origin for 4 or fewer prefixes is ~ 10,000. This means ~ 15% of the AS's are origin for ~ 85% of the prefixes in the global IPv4 BGP table. On average each AS originating 5 or more prefixes are expressing policy for around 40 IPv4 prefixes. If the IPv4 prefix allocations could be dynamically reclaimed and defragmented completely along provider alignments, the size of the Internet routing table could theoretically be reduced to around 10% of its current size. This would effectively turn back the clock on routing table size concerns by close to 10 years. While not a universal solution, by using the IPv6 PI address format the overwhelming majority of multi-homed organizations could do just that by using a single ::/48 prefix (in effect defragmenting the prefix space), and by taking this approach the number of prefixes with a common origin AS would approach 1. Assuming the goal of constraining the routing table growth is simple stability of the routing protocols; as the average number of prefixes per origin moves from 40 toward 1, aggregation of the explicit 'policy defining' PI addresses in the DFZ becomes unnecessary. Uses of PI addresses that do not attempt to define a global policy will be discussed in the subsequent section on Exchanges. Accomplishing the goal of limiting table growth would require a slight modification to the registry policy on justification for an AS number. Currently in order to be assigned an ASN, each requesting organization must provide verification that it has one of the following: - A unique routing policy - A multi-homed site This leaves open the opportunity for every multi-homed site (including telecommuters) to express a routing policy by injecting their full prefix into the DFZ. The obvious question is how many sites really want inbound policy control vs. simple path redundancy and fail-over between their attached providers? Since the fundamental requirement for an AS number in a PA context is really a mechanism for expressing policy independent of the provider, the Hain Expires - February 2007 8 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format line about multi-homing becomes an IPv4 artifact and should be removed. Overview of the IPv6 PI Address Format Details of the provider independent address format are provided in the companion document GEO [1]. A high level overview is provided here for local context. Addresses defined with the Provider Independent format prefix xxxx (IANA assigned) *ARE PORTABLE* between providers. At the same time these addresses are *NOT PORTABLE* across changes in geographic location. Entities that expect identifiers to be portable across physical location moves MUST use alternatives such as Provider Aggregatable prefixes or DNS names. Provider Independent addresses are constructed using a bit interleave of the WGS-84 based latitude and longitude of a site. While the available 44-bit field allows for resolution of a grid approximately 6.4 meters on a side, addressing privacy concerns may require the allocation to be at 36-bits with the expectation that site assignments in that 100 meter grid will be managed by the smallest appropriate local jurisdiction. Accommodating areas of dense population may require that the grid size be adjusted to allow for more flexible assignments for multi-story buildings and business centers with multiple independent sites per geographic grid. Actual assignments within a geographic grid SHOULD be a local jurisdictional issue (matching scope jurisdiction; building owner, community board, local government, etc.), and independent of any service provider. The only rule is that the allocation point MUST be contained within its natural grid. If a locally administered grid needs to be expanded to accommodate density, it MUST avoid or otherwise coordinate use of any existing values that fall within its new boundaries. One approach to accommodate density would be to annex an uninhabitable adjacent region. It is not clear this will really be necessary since the number of ::/48's available to a multi-story building will typically exceed 1,000, with a minimum of 64 ::/64's per vertical meter of each 6.4 x 6.4m area, or 1.59 ::/64's per cubic meter, 1km deep over the entire surface (see Extended Resolution discussion in [1]). The existing PA registries may choose to play a role in helping to coordinate the actual assignments by providing a public database of the local jurisdictional decisions. Specification of the WGS-84 reference point SHOULD be the responsibility of the local jurisdiction (who may defer to the layer-1 service provider for process expediency), and SHOULD represent the physical location of the demarcation point of the layer-1 service. In the case where reference points overlap, the local jurisdiction SHOULD provide coordination over the smallest workable scope. Hain Expires - February 2007 9 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format In the case where the local jurisdiction also acts as a local service provider to its tenants (ie: hotel, apartment, or high-rise business complex) it MAY choose to allocate prefix lengths longer than ::/48, as appropriate for the number and needs of its customers. In any case the allocation MUST NOT exceed 64 bits in length to preserve the Interface ID portion of the address, and should be on the nibble boundaries of /52, /56, and /60 to align the management of the dns reverse delegation with the address pool forward delegation. Constructive implementations The geographic nature of the Provider Independent address format is designed to allocate addresses to sites which aggregate well in direct proportion to the physical distance from the site. It also allows a locally connected site to easily change providers without impacting the nodes or connections within a site. In this context, one appropriate use of the Provider Independent address format is a site connecting to multiple providers within a constrained geographic scope such as a city (actual size depends on the local cooperative interconnection between service providers). When used in this way, only those routers providing service within the scope need to know the details about the interconnections, and the global routing table would see a single entry for that routing scope. Another appropriate use of the Provider Independent address format is when a site will be switching service providers. By preferring the Provider Independent address prefix for a period overlapping the switch, a site may be able to maintain connections while the new service is installed and the old removed. A third appropriate use would be for an organization providing global content services to provide clients with a proximity hint. The longest match between the list returned from DNS and the PI address of the client should provide the closest physical proximity (though not necessarily the closest topological proximity). One consideration is that for global load-balancing hints to work, all nodes will need to know their PI address even if they never use it in packets. One way to accomplish this would be by setting the lifetime values in the Router Advertisement for the PI prefix to Valid = Infinite / Preferred = Zero. A related use recognizes that geography provides distinguished meaning to the term 'home address'. Using a PI address with Mobile- IPv6 [7], where the geographic based PI is 'home', the current provider address would be the care-of address. In this case the nodes are completely independent of provider in both allocation mechanism and packet transport. Hain Expires - February 2007 10 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format Finally, as recognized in RFC 1887 [8], another appropriate use would be for organizations that do not directly connect to or participate in the global Internet (Zero-homed), but do have private links with organizations that are connected. It is necessary for the organization in the middle to be able to differentiate between any privately connected sites and the public Internet, so each of the privately connected sites need to use a unique addresses. This is easiest to accomplish with a globally unique prefix, and since the private site is not connected to an Internet provider, it is unlikely they would be able to do so in a strictly PA environment. While this is not intended to replace [9], by using the PI prefix, there would be no ambiguity. Troublesome implementations The PI address format does not provide any benefit to the size of the routing table for sites that require direct connections outside their geographic region. As discussed earlier, these sites will require the full ::/48 prefix to be carried globally, independent of address format type, so if a remote circuit is intended for access to customers of a specific provider, the prefix SHOULD come from the PA space of that provider. The Provider Independent address allocation mechanism SHOULD NOT be used by a temporary access network (such as a dial point of presence), because scaling routes to single-homed sites attached this way are best addressed through provider based allocations consistent with Provider Aggregatable [5]. The reasons for this are: 1) Temporary access endpoints can not expect to maintain higher- layer connections between physical access events, and therefore should be using a Provider Aggregatable allocation to minimize their impact on the global routing system as they come and go. 2) The location of the intermittent endpoint is unknown, so the address would have to be based on the access point location. If such an access point were scaled to handle 10,000 attachments it would have to subsume the neighboring addresses for the 2.5 km square it is centered in. Since the currently deployed temporary access points tend to be located in densely populated areas, using them with geographic rather than provider based addresses would have the maximum negative impact. A site that is multi-homed by fixed and dial-based access will decide between provider and geographic based addresses based on the relationship between the access paths. If the two paths are to the same provider then PA addressing is most appropriate. If the dial- path were to a different provider than the fixed line, it would make more sense to use the PI address, because the site would maintain its prefix and active connections through the routing switch without the need to globally punch a hole in either provider based aggregate. Hain Expires - February 2007 11 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format Fundamental Issues There are ongoing debates as to the fundamental problems created by unconstrained routing table growth as the Internet topology flattens. Some of the issues raised in these debates include: Memory size for holding the ever-expanding table Memory to CPU bandwidth for accessing the table contents CPU speed in processing table updates Convergence time as each event results in a burst of processing Inconsistent inter-provider announcement policies The volume of information stored with each prefix Management of a distributed database with insufficient concurrency controls While it is clear there are many potential problems, any solutions need to balance these against the costs of equipment capable of solving them. Most service providers will say they want all of these problems solved, but when it comes down to paying for hardware they frequently compromise long-term growth in favor of short-term cost control. As a result, any mechanism or policy needs to take the inconsistency of hardware capabilities into account. Routing issues As noted earlier, the unstated business motivation of the service provider is to push the longest possible prefix as far as possible. The primary impact of this on routing becomes one of dealing with the long prefixes of the set of sites expressing global policy. At the same time the routing system needs to be capable of aggregating all the multi-homed connections where the only policy is 'stay connected within a region'. While the basic mechanism described in GEO [1] is a bit interleave of the WGS-84 latitude and longitude values, the prefix length used by the routing protocols MAY be established on any bit boundary. At the same time, the operational choices will naturally be limited by the requirement for all service providers at that short prefix boundary to have some mechanism for interconnect with all others for traffic delivery. The result is that at some point in the hierarchy all service providers for a scope have to agree on the boundary, then share routes and traffic. It becomes an engineering tradeoff between the size of the routing table, and the cost for maintaining a large number of points where these interconnections occur. From a site perspective - on resiliency, there is a single address block that allows connections to survive any shifts in routing due to provider outages. - on traffic management, the set of address blocks may influence incoming behavior. From a service provider perspective Hain Expires - February 2007 12 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format - each site is identified in a subset of its PA space, as well as the PI prefix. - on the DFZ, there will be multiple paths to any full length ::/48 PI prefix (the intent should be that multiple exist, else PA is the right choice), and the shorter prefixes will identify regional interconnections. The 'hot potato' routing policies will assume a short prefix represents a contiguous interconnection of providers in a given region. To simplify the relationships between providers, it may be necessary to separate the transit service between regions function from the local service delivery function. This will help to contain the longer prefixes to their region of applicability. Example 1: Network DEF provides transit services within Europe. For global connectivity it subscribes to provider ABC. It has local transit agreements with competitive service providers GHI and JKL. The company XYZ is a customer of both DEF and JKL with offices in Paris and Moscow. XYZ policy is to prefer the internal network to the public network. ------- | ABC | ------- / | ------ ------ ------ | DEF |-| GHI |-| JKL | ------ ------ ------ \ '-----------' / ------ ------ |XYZ-P|-----|XYZ-M| ------ ------ Route announcement between: XYZ-P & XYZ-M - full PI and PA ::/48 of the each site XYZ-P & DEF - full PI ::/48 of this site up; DEF explicit customers ::/0 down XYZ-M & JKL - full PI ::/48 of this site up; JKL explicit customers ::/0 down DEF & GHI explicit customers + xAE2:: of XYZ-P DEF & JKL explicit customers (which includes XYZ) JKL & GHI explicit customers + xBAC:: of XYZ-M DEF & ABC xAE2:: up; x::/4 down GHI & ABC xBAC:: up; x::/4 down ABC & peers xA00::/7 out; explicit ::/16s from each Nodes in the Paris office of XYZ would use the xAE2::/16 prefix when talking to sites in the Moscow region, and conversely nodes in the Moscow office would use the xBAC::/16 prefix when talking to sites around Paris. Hain Expires - February 2007 13 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format If XYZ opens an office in New York, it would announce each of that site's ::/48 prefixes to the other two sites, but that should not extend beyond to DEF or JKL. Nodes within the XYZ network SHOULD NOT use the US prefix to talk to nodes in Europe unless the internal connection across the Atlantic is unavailable. In that case, only the New York office nodes would be receiving the local PI prefix so they might choose to use it. If the provider serving the New York office were acquiring its allocation from ABC, the address selection longest match would lead hosts to select PA. Example 2: ISP-1 prefers connections to region 2 via ISP-2, and accepts the short aggregate over that path. ISP-3 has an arrangement with ISP-1 to provide service for its customers over a direct connection between them, and announces it's PA prefix along with the PI specifics of its customers. Sub-scenario 1: The Site uses its Provider Independent address. Customers of ISP-1 would use the path via ISP-3 due to the longer prefix announcement. If the link between the Site and ISP-3 failed, ISP-3 would reroute via ISP-4 due to the intra-region announcements. ISP-3 may choose to stop announcing the Site prefix in this case, which would cause ISP- 1 to route via ISP-2 due to the short region prefix announcement. Connections between ISP-1's customers and the Site would remain intact during these rerouting events. Sub-scenario 2: For cost reasons the Site prefers ISP-4. Implementing the site's preference would require them to use the prefixes from each provider, and then via local policy order the selection rules appropriately. Customers of ISP-1 would not be aware of the site's preferences, and would use their own local policies when initiating connections to decide between the values returned by DNS. Connections between ISP-1's customers and the Site would drop if the connection from ISP-4 to the Site, or ISP-2, failed. ------ | ------ |ISP-1 |------|-----|ISP-2 |- ------ | ------ \ \ | | \ \ | ------ \ ------ ----|-----|ISP-3 |----|ISP-4 | | ------ ------ | \ / | ------ 1 | 2 | Site | | ------ Region Boundary Hain Expires - February 2007 14 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format Example 3: Site-2 connects to ISP's 3 & 6, which announce the short scope prefix to ISP's 2 & 5. None of the ISP's beyond 3 or 6 are explicitly aware of Site-2. | ISP-1 ---- ISP-2 --|- ISP-3 - | \_ | |/ | \ | \_ | _/| | Site-2 | \ | / | | / ISP-4 ---- ISP-5 --|- ISP-6 / | Site-1 |-> Scope Boundary If the link (or regional exchange) between ISP-3 & ISP-6 failed causing a partition of the scope, specifics announced via ISP-5 could be used to heal. Exchange Issues Historically, exchange points have been used to optimize the number and size of circuits needed to reach a group of peer networks. As more of them are deployed, they also provide a degree of traffic localization. Practical requirements for exchanges include, proximity to the physical cabling infrastructure, diversity of its own physical location and the interconnect capacity between those parts, as well as appropriate scaling to the number and types of customers in the region. As a general rule, an exchange fabric at layer-2 is the most flexible, but the exchange service may also want to provide a layer- 3 peering aggregator to reduce the number of participants in an N- way mesh. The general point is that the transit providers interconnecting the metro areas only need to know the aggregates. To accomplish that there needs to be a common structured exchange point, or subset of routers which know the interconnect detail. As the number of full length prefixes (::/48) grows, the convergence time of the routing protocol rises. It is assumed that simply for reasons of physical infrastructure scale, before the list of advertisements grows too long, additional exchanges will be established using longer prefix subsets of the established exchange. Care must be given to the fact that when an area scope is too large, it may become partitioned by natural terrain based boundaries. In these cases, either the more specific prefix values must be advertised, or the providers involved must carry the specifics necessary to heal the partition. Hain Expires - February 2007 15 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format Note: exchanges for a scope don't have to be physically located in the scope of interest; they are simply required to have service provider agreement about aggregation and traffic exchange. One concern that has been raised is that the majority business model of the current exchange points is focused on being an interconnect fabric rather than acting as a service provider. There is nothing in the PI prefix mechanism that requires that to change, as sites could multi-home through local ISP's rather than direct attachments to the exchange. It is also true that any exchange which provides direct service to sites could use a PA prefix like any other local service provider. This means that the exchange business model is not a factor in the allocation of geo based PI prefixes. What the exchange brings to the PI mechanism is a focal point and simplified relationships to help ensure that the infrastructure of the short prefix scope is contiguous. While it is technically possible to operate without an exchange fabric (and for performance reasons some interconnects within a scope will choose this), the inter-provider relationship matrix becomes more complex without one. Placement With an expansion in the number of multi-homed sites, additional exchanges may need to be built. The decision to do so will be a clear engineering driven decision based on the acceptable size of the local routing table (driven by the number of multi-homed sites) and the circuit costs providers will have for connecting. Operational experience shows that over time service providers have deployed exchanges with 40 600 km spacing loosely based on connected population density [10] (2-1991 -> 200-2002 -> 220-2006). One reason for the current set of exchanges is the reality that costs have been significant when national boundaries are crossed. While minimizing the size of the table for any given router would drive deployment of exchanges with ever-closer spacing, the continuing circuit cost for connecting to multiple exchanges will act as a natural counter balance to prevent an excessive number of them from being created. The costs for these additional exchanges should be directly mapped back to the multi-homed sites that create the need. Punching holes in PA space leads to a situation where it is difficult to associate the site that creates the routing table growth problem with the point where the pain is felt (the DFZ); but distribution of the PI format prefix creates a mechanism where the providers could point at a specific local cost (the exchange) which supports the goals of a site, and the site could in turn see explicit value for the additional cost. Replacing the current arbitrary inter-provider filtering arrangement with a clear architecture around exchange points will make it easier to explain the costs. Hain Expires - February 2007 16 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format While cost pressure is going to push back and discourage a massive number of small exchanges, there will be a clear benefit to exchanges covering a large expanse. Even if economics only justifies exchanges for the 22 dense population centers listed below, over 300 million people are covered (~5% of global population). Taking the example out to 12 bits (::/16) provides additional granularity for those regions where several large population centers already support multiple exchanges, and may simplify operations. Couple this with the likelihood that significant geographic areas are connected through these population centers and there is little immediate need to add additional exchanges. Population centers Prefix Example Current Exchanges (~10 M people) Sydney - x128::/12 AUSIX Tokyo, Osaka - x2D3::/12 NSPIXP-2, JPIX Seoul - x2C9::/16 IX, DACOM Beijing - x29D::/16 Terramark Shanghai - x2C0::/16 SHIX Manila - x24A::/12 PHIX, PHNET CORE, HKIX Jakarta - x0B8::/12 Napsindo, Sing Tel, KLIX Delhi, Calcutta - xB7A::/12 THIX Mumbai - xB67::/16 EMIX Karachi, Teheran - xB69::/16 Karachi NAP Moscow - xBAC::/12 M9-IX, MPIX Cairo - xB80::/16 AIX, CyIX Istanbul - xADD::/16 TIX London - xAB7::/12 LINX Paris - xAE2::/12 PARIX, AMS-IX Sao Paulo - x5C7::/12 Diveo NAP NY - x798::/12 MAE-East, NYIIX Mexico City - x673::/12 Chicago NAP LA - x6C2::/12 MAE-West, MAE-LA Some neighboring regions may find it advantageous to leak full prefix lengths between themselves. While a region has a flat routing table, providers in that region can ignore the detail in the majority of the global table. The interconnection robustness at the scale of this example is fairly high, so there is potential for significant gain. Within the vast regions, it becomes a mater of local politics and business practice as to how much further the plan can go, or how additional existing exchanges might be leveraged. Certainly evolving to a structured interconnect model will be more difficult in either Europe or the US than all the others combined, but if those PI regions are initially written off as hopelessly intertwined, there is still an opportunity for significant gain when the rest of the world is able to ignore the details of that interconnection mess. A further reduction is possible by starting with three groupings. London/Amsterdam : Tokyo/Osaka : Chicago/New York Hain Expires - February 2007 17 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format 90.00000 s 90.00000 e Tokyo xC00::/10 60.00000 s 90.00000 e Tokyo x000::/6 90.00000 n 90.00000 e Tokyo xE00::/10 90.00000 s 180.00000 e Chicago xC40::/10 60.00000 s 210.00000 e Chicago x400::/6 90.00000 n 180.00000 e Chicago xE40::/10 90.00000 s 0.00000 e London xD40::/10 60.00000 s 330.00000 e London x800::/6 90.00000 n 0.00000 e London xF40::/10 (Getting the polar sections to map to even binary units requires dividing 360 by 2^n. Given the land mass alignments, it makes sense for n to be 2, with 0 90, 90 180, & 180 360 groupings.) >-------------------global service providers------------------< | | | | | | Asia IX Amer IX Euro IX | | | | | | ----------- regional service providers ----------- / | \ / | \ / | \ / | \ / | \ / | \ Local IX's Local IX's Local IX's | | | | | | ----------- local service providers ----------- Engineering considerations Many private-peer connections exist to avoid the performance limitations of a shared interconnect. These limitations include both the interconnect fabric, and the access paths between the fabric and the provider network. While not as simple to operate as exchange interconnections, these peering points are an engineering necessity for scale. Fortunately, both interconnect strategies work with the PI address format, as long as the scope of the advertised PI prefix is contiguous (ie: there is a path between the private interconnect and the shared fabric when the prefix applies to both). One engineering consideration is that the size and location of an exchange has no mandatory relationship to the prefix lengths exchanged there. For example, assume there is a massive exchange in London with hundreds of providers participating covering all of the UK, and nearby another exchange, say Moscow, where there may only be tens of providers, but they cover all of Russia from a single exchange point. The fact that one has more participants, or covers a region approximately 10 degrees square, while the other covers a region 20 x 150 degrees has nothing to do with the number of multi- homed sites supported. A single exchange in each may be inadequate, Hain Expires - February 2007 18 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format or may be overkill for the required service. The requirement is that all participants agree on the set of prefixes to be exchanged, and that set will almost assuredly contain multiple lengths to avoid overlapping with a neighboring exchange. The existing Regional Registries for PA format addresses already have the appropriate constituency and fora to act as a catalyst for the necessary agreement on prefixes at each exchange point. It should be noted that when a site is directly connected to an exchange, the exchange becomes the logical customer of the transit service providers that tie the exchanges together. In this context the exchange itself appears to be one of the service providers for the regional aggregate. While the current set of exchanges are not likely to scale to support millions of multi-homed sites for a specific scope, in the long-run the location and number of exchanges will evolve to meet the engineering cost/benefit analysis. The design of the PI mechanism allows for the creation of exchanges at the scope that makes local engineering sense, without impact on any other scopes. Observations and Considerations Address Selection IPv6 defines that interfaces will have multiple addresses, so having a PI set as well as potentially several PA sets should not present any particular concerns to the end nodes. The primary technical issue will be limitations in the size of a DNS response packet. Using both the PI and PA prefixes, multi-site networks SHOULD internally advertise all of the appropriate natural prefixes for the connections the network manager is willing to use, then let the host address selection rules [11] sort it out. Due to longest match selection the default rules would result in systems using a source address that most closely matches one for the destination. When the destination is single-homed return traffic would naturally be directed toward the site boundary closest to the destination site (ie: traffic would traverse the public network as little as possible). If this is not the desired behavior, local policy may establish an appropriate set of rules to reorder the end system preferences. While broad advertisement of available prefixes provides the most robust infrastructure to the end systems, managers of large multi- national organization networks should exercise operational care to administer the distribution scope of any prefix. It is unlikely that nodes in a 10,000-seat office complex would be expected to use the local Internet access provided for a 3-person office halfway around the world. When this policy is true, the small-office prefix SHOULD NOT be propagated beyond that local office, because doing so would only clutter and slow the address selection process for the larger segment of the organization's network. Hain Expires - February 2007 19 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format The longest match algorithm will automatically select between PA and PI prefixes. If the two sites share some part of the provider hierarchy and some degree of geographic locality, it will become a case-by-case issue as to which one is longer. On one hand they may be geographic neighbors using different providers with no relationship in the PA based allocation (longest match rule would cause hosts to select PI based prefix). In the contrasting case, they share the same provider but are on opposing sides of the globe (longest match rule would cause hosts to select PA prefix). While the hosts have no direct access to current topology information, the simple longest match rule for address selection would appear to bias connections toward the most appropriate path. In any case, once the packets are sent, traffic flow will follow the inter-provider policy perspective of the optimal route. In the case where one site is single-homed (therefore using a PA prefix), and the other is multi-homed using PI, the routing system would not particularly care because these are both global unicast prefixes and will be handled appropriately. (Creating this situation presumes that the multi-homed site is not informing its hosts or DNS about any PA prefixes it may have, or has a local policy overriding the default selection rules.) In fact this may be a useful case for a content provider trying to do global load distribution, though it would require the PA node to be aware of its PI prefix, even if it was never used in a packet. Path Selection A frequently asked question is how a source selects the correct first hop when more than one exists? This is actually a multipart question since it involves both the address selection as well as the first hop router selection. Many arguments about address selection revolve around the host's knowledge (or lack thereof) about the technically optimum path for the metrics of bit-rate, loss-rate, delay, and jitter, but they generally avoid the topic of actual access cost, which is all the site usually knows. Address selection was dealt with in the previous section, and lacking local policy to the contrary, will be based on longest match between the source and destination. A fundamental characteristic of IPv6 hosts is that they will always choose one of the available routers, and expect to be redirected by the routers which actually know at least part of the optimal path. This set of routers for a site will be managed according to local policy and will forward or redirect in that context. While many discussions assume the destination route announcement determines the source's routing; the reality is the holder of the packet always decides based on its perspectives of cost. The source policy has always determined at least the first hop, and any intermediate policy may bias the route at any point by ignoring any announced destination policy. Hain Expires - February 2007 20 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format Partitioning One of the concerns that aggregation through an exchange raises is the potential for a portion of the local topology to partition. This would effectively create a black hole for sites that are only attached to the disconnected partition. While this is clearly a problem for single-homed sites, those sites should be using PA space and not be subject to the aggregation of PI prefixes. For those multi-homed sites using PI in a metro-aggregate context, their exposure to partitioning occurs when all of their local providers partition from the set of transit providers at the same time. The potential for simultaneous partition raises the case that any metro interconnection topology could create a single point of failure, which further leads to a strong recommendation that these metro interconnects actually consist of 2 or more interconnected fabrics per scope. The routing implications of this are that the number of BGP speakers will increase in proportion to the number of fabrics, but as long as the set of prefixes match they will appear to be one logical exchange point. In any case partitions can be locally healed with explicit routing entries in the interconnecting providers, and the rest of the world does not need to be aware. Renumbering Even though this address format is derived from geographic information, renumbering is not required as devices move within a network. The only time renumbering becomes a concern is when the layer 1 demarcation for the network changes. In this case all of the attached devices would renumber together, just as they would for a change of providers when using the PA prefix model. Relationship to telephony addressing model It has been noted that the PI format shares characteristics with the global telephone address plan (an alternative PI aggregation scheme, discussed in GAPI [12], is a closer match to the traditional telephony model of allocations). While the distribution of prefixes to specific geographic areas would appear to be similar, the telephone environment address space was divvied up in a pseudo- random way where the resulting provider boundaries aligned with the political notion of geography at one point in time. The PI address format is devoid of any political context (beyond agreement on WGS- 84 as the reference tool), and allows for structured aggregation at any bit boundary. Unfortunately the cost models for circuits still align with political notions of geography. This situation is expected to ease as the telephony system continues its efforts at deregulation and privatization. The one place where there is a strong similarity between the addressing models is the perspective that some providers operate within a geographic area (routing full- length prefixes), while other providers tie the diverse areas together (routing short area aggregates). Thus the common Hain Expires - February 2007 21 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format characteristic is the fundamental model that allows local detail to be abstracted at a distance. General Considerations One concern raised by enterprise managers is that a ::/48 might not be enough for some large organizations. Using the PI format, a large organization will almost assuredly have multiple ::/48's to work with. For example, if their facilities covered a contiguous 100x100 meter lot they would have an entire ::/36 to work with, and the types of organizations that will need more than a single ::/48 are also likely to have multiple 100x100 meter lots just to house that number of end systems. While the IPv6 PI address format is designed to support exchange- based aggregation in the context of various scope sizes, it is not dependent on exchanges as a fabric for its overall route aggregation properties. It will provide efficient route aggregation in a global context when providers in a given scope interconnect by whatever means (ie: common third party providing transit services), such that only the shorter prefix is announced outside that scope. Any provider (including a traditional exchange point route server) announcing a short prefix MUST be able to deliver packets to anywhere in the scope, either directly or through specific arrangements. In the case where a service provider does not interconnect with others in its scope it MUST advertise the longer prefixes associated with its customers. It is not likely to happen soon, but there is a concern that eventually a few regions may exist with extreme densities (greater than 1M independent multi-homed sites per area 6.5 km/side). When the density of independently multi-homed subnets exceeds 64 per vertical meter, of 6.4 x 6.4m horizontal surface, in 1km tall buildings, an alternative allocation mechanism will be required. One characteristic that is frequently overlooked is that geography provides distinguished meaning to the term 'home address'. So a node using Mobile-IPv6 [7] with PI addresses as the home address and the current value from the intermittent access provider for the care-of- address could expect to maintain connections across access events. Note this does not mean the geographic address is allocated or even known to the intermittent access point. The routing system doesn't need to know the binding for the geographic address since packets are routed according to the PA care-of-address. The home-agent would need a way to inject its Provider Independent prefix and current binding. This could be a form of tunnel-broker within a region. When used in conjunction with RFC3306, it would be possible for governments to establish a regional notification multicast service. While they could do this with PA addresses, the burden of connecting to the right multicast would fall on the end user. Using the PI format, a hierarchy of groups could be defined, where very targeted Hain Expires - February 2007 22 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format messages could be multicast efficiently without need for the consumer to understand the technical details. Recommendations Attempting to balance the conflicting policies of the service provider operations staff, their business staff, each end site, and any additional service providers will require a clear policy that everyone can rely on for consistent packet treatment. As it is not the purview of the IETF to establish operational policy for independent operators, the closest fit is a recommendation in the form known as Best Current Practice. In that context, this document recommends: 1) that all providers filter out and ignore any announcements that include 5 or more PI prefixes longer than ::/28, originating from a common AS, where the AS path length is longer than 2. 2) an AS number be restricted to those who require injecting explicit policy into the DFZ. 3) metro interconnects actually consist of 2 or more interconnected fabrics per scope. Policy 1 allows global enterprise sites which need to inject global policy into the DFZ, to inject up to 4 long prefixes if they can justify to the registries they require an AS number. At the same time it removes the small business and telecommuter announcements from the DFZ because those would have an origin AS from a provider that would most likely be sourcing more than 5 long prefixes. While it removes those small types of sites from the DFZ, it still allows them a degree of provider independence and resiliency in the metro context. Policy 2 removes multi-homing as an independent requirement to acquire an AS number. If the AS number becomes more difficult to acquire through a change in policy, and service providers employ a filter (either at the protocol level ::/28, or by charging extra per prefix) on AS paths longer than 2 where 5 or more PI prefixes share the same origin AS, the growth of the routing table will be slowed to at most 4x the growth in AS allocations. This change in policies would allow the global enterprise to manage its own policies, while avoiding the table explosion that would happen if every small business or telecommuter appeared in the DFZ. This would also allow neighboring service providers in a region to share detailed information about customers using the PI prefix. Policy 3 removes the potential for a single point of failure that would be contrary to the goals of multi-homing resiliency. It has been noted that the existing inter-provider relationships and settlement models do not align precisely with the concept of Hain Expires - February 2007 23 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format regional aggregation that is recommended here. While this is undoubtedly true, the situation is partially due to the lack of a structured address plan to align with. Other factors that play into the situation are that the perceived costs are not a strict function of distance, and that the industry lacks a rate structure for packet settlement. While the fundamental cost of physical media does have a distance component, the current pricing realities often ignore this. Compounding this situation is the fact that the Internet providers have gone out of their way to avoid hierarchy on one hand, while looking for someone to dump packets to on the other. The resulting relationship complexity could be simplified through packet accounting, but that model runs counter to the current culture that is best described a 'shared pain'. For the IPv4 Internet, service providers have attempted technological restraint systems through routing filters to varying degrees of success. For the IPv6 Internet the PI address format looks to provide a reasonable tool for aggregation, while allowing well-defined exceptions. Given this environment, economics and human nature will align the interconnect strategies of the service providers over time. In any case, deploying a new approach will require a significant number of service providers and sites to agree that these recommendations result in a sustainable business model, which actually lowers overall costs. To reach that goal, the PI address model explicitly trades address consumption for simplicity in the derivation and routing, as well as trades maximal routing efficiency for end-to-end system level efficiency. RFC Editor Considerations The format prefix x in the examples needs to be replaced by the value assigned by IANA. Security Considerations While there may be concerns about location privacy raised by the geographic scheme, there is nothing inherent in this address format that would raise any more security considerations than any other global addressing format. If location privacy were an issue it would be wise to avoid this mechanism in favor of location independent mechanisms such as provider based allocations. Relationship to the IETF Multi-6 WG multi-homing requirements The multi-homing requirements for IPv6, consistent with current IPv4 usage, are detailed in [13]. The capability of the Provider Independent address format to deal with each of the points in that document will be addressed here. Since the goal for a short-term approach to deal with multi-homed sites was specifically taken off Hain Expires - February 2007 24 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format the table as the IETF moves between the Multi-6 and extended lifetime architectural change of the Shim WG, the proposed GEO approach is clearly not an overlapping mechanism. Redundancy The Provider Independent address format is designed to provide redundancy between attached providers. By having the site prefix independent of all service providers, link and routing failures in one provider should be completely transparent to the site. The primary case where things may break is a link or routing failure in any part of the path that lacks physical redundancy. Load Sharing This recommendation for specific applications of the Provider Independent address format will allow sites to manage outbound traffic without concern for undue filtering in the routing system. It also allows for load sharing on inbound traffic by large enterprises that can justify expression of policy in the DFZ. Performance The Provider Independent address format allows traffic to arrive from a variety of sources over the set of available paths, but does not explicitly provide for remote flow control. A site may exercise some course level of remote traffic flow management by arrangements for service from multiple providers. At a minimum, traffic from the other customers of an attached provider would follow the site's path through that provider, and not transit any other provider. Policy Traffic class alignment as policy routing is not an IP routing issue, and even using PA addresses can only be accomplished by announcing explicit subnet or host routes. As such the Provider Independent address format will not offer any additional explicit support. Achieving the goal of this bullet is probably best met with a mix of Provider Independent and Provider Aggregatable prefix announcements where the hosts respond to the specific address/port mappings according to local policy. Simplicity The target of the Provider Independent address format is simplicity, both in the method of allocation, and in the routing expectations. From the site perspective, an allocation independent of provider is what they are after (ie: PI format). From the service provider perspective, handling GEO [1] type PI prefixes is as simple as IPv4 PI prefixes. The potential increase in complexity over current IPv4 deployments is understanding the impact when site chooses to use both PI and PA prefixes. Transport-Layer Survivability The Provider Independent address format explicitly deals with transport-layer survivability by isolating the session from the intervening providers. As long as the routing system converges Hain Expires - February 2007 25 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format within the timeout period of the transport-layer, any active connections will survive. Impact on DNS There are no modifications required for the Provider Independent address format discussed here. There is a potential issue with the size of a response packet if a multi-homed site chooses to include all of the applicable addresses. Use of a single PI rather than multiple PA prefixes would reduce this concern, while retaining the immunity-to-provider-failure characteristic. Packet Filtering The Provider Independent address format does not preclude filtering inappropriate packets, and may facilitate such filtering since the location of the demarcation point helps reduce any ambiguity. Scalability No one approach will solve all scalability concerns. An appropriate mix of Provider Independent and Provider Aggregatable address use will solve most concerns without undue complexity in either the host or the routing system. Impact on Routers The impact on routers outside a region is a significantly smaller routing table, both from the reaggregation of the provider prefixes and from the ability to further abstract geographically distant sites. Within a scope, the full routes need to be carried, but this is no worse than the holes punched in provider aggregates, and can be managed through interconnecting at smaller scopes. Impact on Hosts Hosts may have an additional address to select from if the site chose to use advertise both the Provider Independent and Provider Aggregatable formats. Using longest-match rules should easily sort between Provider Independent and Provider Aggregatable prefixes. Hosts may also want to choose to use this as a distinguished form of 'Home' address for mobile applications. Interaction between hosts & routing system Routers providing for IPv6 auto-configuration through announcement of the site prefixes may have an additional one in the list, or may simply choose to announce only the Provider Independent prefix. Operations and Management The mechanism for deriving the Provider Independent address is specifically designed to simplify this operations issue by using the globally ubiquitous WGS84 system of measurement. Cooperation between Transit Providers The Provider Independent address mechanism does not require cooperation between service providers specifically for a given multi-homed site. It does require all service providers for a given Hain Expires - February 2007 26 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format scope to agree on the boundaries for the scope and any traffic exchange point that might be necessary. Multiple Solutions The Provider Independent address mechanism does not preclude other forms of multi-homing. It does provide a complimentary service to the Provider Aggregatable prefixes for single-homed use, and scales much better than punching holes in those for multi-homed sites. Hain Expires - February 2007 27 Application and Use of the IPv6 Provider- August 2006 Independent Global Unicast Address Format References 1 Geo, draft-hain-ipv6-PI-addr-10.txt, Hain, T., "An IPv6 Provider- Independent (Geographic Reference) Global Unicast Address Format", August 2006. 2 RFC-2119, Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 http://www.wgs84.com/files/wgsman24.pdf 4 RFC-1518, Rekhter & Li, "An Architecture for IP Address Allocation with CIDR", September 1993 5 RFC-3587, Hinden, B., Nordmark, E., Deering, S., "IPv6 Global Unicast Address Format", RFC 3587, August 2003. 6 http://kahuna.telstra.net/bgp2/as1221/ , G. Huston 7 RFC-3775, Johnson, D., Perkins, C., "Mobility Support in IPv6", June 2004 8 RFC-1887, Rekhter, Y., Li, T. "IPv6 Unicast Address Allocation Architecture", December 1995. 9 RFC-4193, Hinden, R., Haberman, B. "Unique Local IPv6 Unicast Addresses", October 2005. 10 http://www.ep.net/ 11 RFC-3484, Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. 12 GAPI, M.Py, I. Beijnum, A Geographically Aggregatable Provider Independent Address Space to Support Multihoming in IPv6, draft- py-multi6-gapi-00.txt, October 2002 13 RFC-3582, Black, et. al., "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003 Hain Expires - February 2007 28 Acknowledgments Discussion threads on the NANOG and IETF/Multi-6 mail lists provided many of the perspectives presented here. Early feedback was provided by Iljitsch van Beijnum, Brian Carpenter, Sean Doran, Geoff Huston, and Pekka Savola. Author's Addresses Tony Hain Cisco Systems 500 108th Ave. N.E. Suite 400 Bellevue, Wa. 98004 Email: alh-ietf@tndh.net Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. 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." Disclaimer of Validity 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. Hain Expires - February 2007 29