Multi-6 Internet Draft T. Hain Document: draft-hain-ipv6-pi-addr-use-00.txt Cisco Expires: December 2001 June 2001 Application and Use of the IPv6 Provider-Independent Global Unicast Address Format Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document discusses the expected use of the address format discussed in the companion document [2] in the Internet. In addition to covering implementations where it adds value in managing the growth of the Internet routing tables, the document will discuss implementations which 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 [3]. Hain Expires - December 2001 1 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format Status of this Memo...................................................1 Abstract..............................................................1 Conventions used in this document.....................................1 Introduction..........................................................3 IPv6 Provider-Independent Global Unicast Address Format Overview......4 Meritorious implementations...........................................5 Troublesome implementations...........................................6 Routing issues........................................................7 Operational Issues...................................................10 Considerations.......................................................11 Address Selection..................................................11 Partitioning.......................................................12 Path Selection.....................................................12 Renumbering........................................................13 Relationship to telephony addressing model.........................13 General Considerations.............................................14 Security Considerations..............................................15 Relationship to Multi-6 WG multi-homing requirements.................15 Redundancy û.......................................................15 Load Sharing û.....................................................16 Performance û......................................................16 Policy û...........................................................16 Simplicity û.......................................................16 Transport-Layer Survivability û....................................16 Scalability û......................................................16 Impact on Routers û................................................16 Impact on Hosts û..................................................17 Interaction between hosts & routing system û.......................17 Operations and Management û........................................17 Random thoughts....................................................17 References...........................................................18 Acknowledgments......................................................18 Author's Addresses...................................................18 Hain Expires - December 2001 2 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format Introduction This document discusses the application of the Provider-Independent global unicast address format for the IPv6 address assignment. This address format is based on WGS-84 [4] derived geographic location. 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 the approaches can be used in a complementary manner. This document will highlight the operational configurations where the geographic-based provider-independent addresses provide value in minimizing the size of the global routing table, as well as those situations where they should be avoided in favor of the provider aggregates. Provider based address aggregation has its roots in the IPv4 routing table growth limiting effort known as CIDR [5]. 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 table. 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 multiple service providers 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 (thus the term PI space). Lately this process has evolved into simply arranging with each of the service providers involved to announce the longer 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. 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 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. Collectively these issues drive sites away from the nicely structured single-connection hierarchical model that is the foundation of Provider-Aggregatable [6] 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 Hain Expires - December 2001 3 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format match. The consequence of the collective situation is that no one approach to addressing will solve the entire set of route scaling problems. The goal of the Provider-Independent address format is restoring the integrity of Provider-Aggregatable prefix format for use by the single homed sites, while simultaneously providing a scaleable approach for 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 from a distance. 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. While a site may inject any full /48 prefix into an attached service provider, it MUST recognize that other non-attached service providers may be routing on aggregates of either the Provider-Aggregatable or the Provider- Independent prefixes. While this address format is designed to support exchange-based aggregation in the context of various scope sizes, it is not dependent on exchanges for it's 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), such that only the shorter prefix is announced outside that scope. Any provider announcing a short prefix SHOULD be able to deliver packets to anywhere in the scope, either directly or through other 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. As this action is directly contradictory to the goal of reducing the routing table size, there SHOULD be a strong needs-based justification for this action. IPv6 Provider-Independent Global Unicast Address Format Overview Details of the provider-independent address format are provided in the companion document [7]. A high level overview is provided here for local context. Addresses defined with the Provider-Independent format prefix 0001 are by definition NOT-PORTABLE when a network attachment point changes geographic locations. Entities that expect identifiers to be portable across physical location moves MUST use alternatives such as Provider-Aggregatable prefixes or DNS names. Hain Expires - December 2001 4 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format 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 10 meters on a side, addressing privacy concerns may require the allocation to be at 40-bits with the expectation that site assignments in that 40 meter grid will be managed by the smallest appropriate local jurisdiction. Accommodating areas of dense population may require that the grid size be increased to 150 meters or more to allow a sufficient number of bits in the locally assigned field identifying the specific site. This will allow 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 rules are that the allocation point MUST be contained within a grid, and any overlap must be coordinated. If a 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. 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 expediency), and SHOULD represent 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. 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) or is unable to expand the scope through a shorter prefix, 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. 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 scope. Hain Expires - December 2001 5 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format 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). Troublesome implementations This address format does not provide any benefit to the routing system for sites that insist on redundancy through direct connections to providers who do not provide service for their location (such as a site in Chicago with a direct connection to a provider who's service area is London). Essentially these sites will require the full /48 prefix to be carried globally, independent of address format type. If the arrangement were simply for direct access to the customers of the remote service provider, and not global redundancy, then this prefix would be suitable. On a case-by- case basis the design goals of such sites may show a slight preference toward one of the types, but terminating provider policies will determine the actual result. The Provider-Independent address allocation mechanism SHOULD NOT be used on a temporary access network (such as a dial point of presence), because scaling routes to sites attached this way are best addressed through provider based allocations consistent with Provider-Aggregatable [6]. 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 the scope of their impact on the 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. That said, geography provides distinguished meaning to the term 'home address', so a site using Mobile-IPv6 [8] with provider- independent addresses as the home address and the current value from the intermittent access provider for the care-of-address could Hain Expires - December 2001 6 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format 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 Provider-Aggregatable 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. Routing issues The basic mechanism is a bit interleave of the WGS-84 latitude and longitude values with the intent to minimize routing table size. While the prefix length MAY be established on any bit boundary, the operational choices will naturally be limited by the requirement for all service providers at that boundary to directly 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 number of points where interconnections occur. 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 which scopes are aggregated at specific exchanges Operational experience shows that over time service providers have deployed exchanges with 40 û 600 km spacing loosely based on connected population density [9] (2-1991 -> ~ 200-2001). At the same time private interconnections between service providers have been occurring to bypass congestion at these exchange points. Both interconnect strategies work with the Provider-Independent address format, as long as the scope of the prefix being advertised is contiguous. 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. At a high level injecting /48s of any format has the same effect on the local routing table. The difference between the schemes is that for the Provider-Aggregatable allocation scheme to work for backup purposes the full /48 needs to propagate globally, where as in the provider-independent case the prefix may be aggregated as a function of distance from the alternative providers. As a simple 2-level example, global Core routing (aka: DFZ) might be based on longest match of sparsely populated table using fixed first 3 bytes (FP + 20 bits) to find a region, while Regional routing Hain Expires - December 2001 7 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format might be based on longest match of moderately populated table using next 2-3 bytes to find neighborhood-site. If a router believes it can get to the entire concatenation it should announce a short prefix, if not it will need to announce specifics. All providers would need to be aware of the current scope of its ability to deliver within a region. If a region were to become partitioned the upstream announcements would need to reflect the current scope. Implications: Announcements in general: 'have arrangements to deliver everywhere within this scope' Announcements upstream (provider) û shortest prefix with expectation of full coverage Announcements counterpart (peer) - explicit downstream lists need to be exchanged Announcements downstream (customer) û explicit customer routes within the downstream's scope + list of short prefixes 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 provider-independent and provider-dependent /48 of the each site XYZ-P & DEF full provider-independent /48 of this site up; DEF explicit customers + 1::/4 down XYZ-M & JKL full provider-independent /48 of this site up; JKL explicit customers + 10::/8 down DEF & GHI explicit customers + 1092 of XYZ-M DEF & JKL explicit customers JKL & GHI explicit customers + 1080 of XYZ-P Hain Expires - December 2001 8 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format DEF & ABC 1080 up; 1::/4 down GHI & ABC 1080 up; 1::/4 down ABC & peers 1080 out; explicit /16s from each Nodes in the Paris office of XYZ would use the 1092::/16 prefix when talking to sites in the Moscow region, and conversely nodes in the Moscow office would use the 1080::/16 prefix when talking to sites around Paris. If XYZ opens an office in New York, it would announce that 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 provider- independent 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 Provider-Aggregatable. 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 the Provider-Aggregatable prefix along with the Provider-Independent 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 |- ------ | ------ \ \ | | \ \ | ------ \ ------ Hain Expires - December 2001 9 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format ----|-----|ISP-3 |----|ISP-4 | | ------ ------ | \ / | ------ 1 | 2 | Site | | ------ Region Boundary Example 3: | ISP-1 ---- ISP-2 --|- ISP-3 - | \_ | |/ | \ | \_ | _/| | Site-2 | \ | / | | / ISP-4 ---- ISP-5 --|- ISP-6 û / | Site-1 | Scope Boundary If the link between ISP-3 & ISP-6 failed causing a partition of the scope, specifics announced to ISP-5 could be used to heal. Question about how does an ISP find out what scope they can aggregate. ??? If everyone just starts announcing site specific /48's, and use the upstream backpressure to correct the situation, there is no need for a specific registration. Clearly all of the significant players in a region need to communicate well to contain the specifics, but the consequence of not doing that is simply a larger table at the next larger boundary. Providers at the larger scopes are motivated to encourage providers in the smaller scopes to interconnect locally and avoid announcing the specifics any wider than necessary. Operational Issues Multi-site networks SHOULD internally advertise all the appropriate natural prefixes the network manager is willing to use and let the rules [10] sort it out. This would result in systems selecting a source address that most closely matches the destination. Thus 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). How a site that is multi-homed by fixed and dial-based access decides between provider and geographic based addresses? Basically it comes down to the relationship between the access paths. If they Hain Expires - December 2001 10 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format are to the same provider then Provider-Aggregatable addressing is appropriate. If the dial-path were to a different provider than the fixed line, it would make more sense to use the Provider-Independent 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. Observations and Considerations Address Selection IPv6 defines the case that nodes will have multiple addresses, so having a set of Provider-Independent ones as well as potentially several sets of Provider-Aggregatable ones 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. Managers of large multi-national organization networks should exercise operational care to administer the distribution scope of any prefix. It is generally 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. If this is true the small- office prefix SHOULD NOT be propagated that far, because doing so would only clutter and slow the address selection process for the larger segment of the organization's network. Longest match should be enough to decide between Provider- Aggregatable and Provider-Independent prefixes. (Is this true?) FP's alone would bias toward geographic, but the reserved bits make TLAs appear longer. 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. Worst case they are geographic neighbors using different providers with no relationship in the TLA. Longest match rule would cause hosts to select PI based. Contrasting case, they share the same provider but are on opposing sides of the globe. Longest match rule would cause hosts to select Provider-Aggregatable prefix. The case where one end is single-homed provider-dependent and the other is multi-homed provider-independent ... This presumes that the multi-homed site is not informing its hosts or DNS about any provider prefixes it may have; otherwise the TLA length issue would prevent it. ...this may be the case for a content provider trying to do global load distribution... Explicitly causing a preference to Provider-Independent would require a local policy override of the selection rules. Src/dst selection would only know these are global unicast and handle appropriately. If the provider of the dependent site is not interconnected within the geographic scope of the multi-homed site, traffic flow may take a less-than-optimal route from the perspective of one or the other Hain Expires - December 2001 11 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format endpoint, but will follow the optimal route based on current inter- provider policies. Partitioning Discuss what happens when the peering in a scope breaks down. Do the providers announce longer prefixes or live with the black hole? How can they tell the difference between expected holes in a peer's advertisement, customers switching providers, and a partition? Strong recommendation for 2 or more interconnects in a scope. In the case of example 2 above: if the connection between ISP-3 & ISP-4 dropped, the only difference this would make is if ISP-3 had been transiting traffic from ISP-1 to ISP-4 for ISP-4 multi-homed customers that are not customers of ISP-3 (would require a different scenario policy). In this case, ISP-1 should be receiving the short region-2 prefix announcements from both ISP-2 & ISP-3, so it becomes a regional healing policy issue to be worked out locally between ISP-2, 3, and 4. The most resilient case would be for ISP-3 and 4 to maintain a short prefix for their own scope pointed at ISP-2. This would cause any partitions in that scope to be healed via the specifics being announced to ISP-2. The cost to ISP-2 would be transiting intra-region traffic, and dealing with connection attempts for PI addresses that are not currently being announced even when the region is intact. Another approach would be for the scope-associated operators to participate in a route server that knows the set of PI addresses in use within the scope and the relationship of AS's. If the scope becomes partitioned, either the active set of prefixes changes, or the relationship between the AS's change. Either way it should be possible to respond appropriately to a partition as long as the AS doing the healing has full routes for the scope. If a layer-1 service provider also provides layer-3 service, should their layer-3 service simply announce the provider-independent aggregate for the layer-1 coverage and let more specifics from layer-3 competitors override? Advantage: smaller table Cost: they eat connection attempts when the competitor partitions from the scope or script-kiddies are trolling the PI space. Path Selection How does a source select the correct first hop? 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. One of the issues Hain Expires - December 2001 12 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format is that the most popular current business model assumes that a subscriber pays for access based on the capacity of or actual bits delivered to their site. In this environment the bias toward the technical metrics for deciding sending rules is understandable since a source can't know the cost optimization of an arbitrary destination site. What a source can know is its cost for outbound access (assuming the business model is based on that), and therefore could bias its first-hop provider selection on a real local business policy. This is independent of the choice for either a Provider- Aggregatable source address, or a Provider-Independent one. Basically a destination address should be chosen based on longest- match with the lowest cost first hop for the available address set. ie: the set of possible destination addresses needs to be aligned with the set of possible source addresses resulting in a (local outbound policy) lowest cost selection of the pair. Regardless of the host selection, the border router is in control of the actual hand-off of the packets, therefore ultimately in control of costs (when based on outbound rather than the current inbound). *** actually this would work for destination based costs as well û the basic issue is that the source address needs to be picked first based on the lowest resulting cost for the return packets, then let longest match resolve the destination. While many discussions assume the destination's ISP choice determines the source's routing; the reality is the source's ISP choice has always determined at least the first hop. The other consideration is PI may cause the traffic flow between ISPs to flip from dump-early to dump-late (in smallest peering scope of destination). The number of packets carried should remain the same, but the transit agreements may be the opposite direction from Provider-Aggregatable allocations. The only question I see as a sticking point is; will transit providers be willing to charge for ingress offered loads in addition to the egress they charge for today? If so they will be happy because they are getting paid to carry traffic, if not they will really be against this since it would cause them to carry traffic they are not getting paid for. Renumbering Even though this address format is derived from geographic information, renumbering is not required as devices move within a network, unless the public demarcation at layer 1 changes as a result. Relationship to telephony addressing model This is fundamentally the telephone solution. This is not the telephone model. In that environment as the address space was divvied up, the resulting provider boundaries happened to Hain Expires - December 2001 13 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format align with the political notion of geography at that time. The Provider-Independent address format is even devoid of any political context (beyond agreement on WGS-84 as the reference tool). IF we had a pretty solid "distance = cost" dominant cost model then there would be a fair incentive for local interconnection. If we _also_ had a different inter-provider settlement model where every packet was purchased from its originating provider and on-sold to its terminating provider (to borrow some PSTN settlement terms with a reselling margin equal to the marginal cost of transit), then there would be an even stronger case for local interconnection, and, furthermore if the packet accounting settlement rates were fixed according to some imposed industry model, then the case for regionally aggregateable addresses would be pretty solid. General Considerations In a few places there may exist regions with extreme densities (greater than 1M independent multi-homed sites per 10 km grid); where it is not reasonable to expand any given grid to a sufficiently large area to provide enough addresses for local administration. Generally these are expected to be adjacent to sizable regions of water where it is highly unlikely there will ever be permanent Internet service provided. The local jurisdiction for areas of extreme density MAY choose to map a nearby unusable grid onto an area requiring more addresses. When this is done the jurisdiction MUST coordinate with neighbors to avoid duplication. > Also the cost pressure is going to be against local exchanges > and in favour of large regional exchanges. Take the example of an 8-bit reference using the PI format. The globe divides into 128 regions, with 68 unusable (32 are polar, 36 are basically water). Of the remaining, it appears that 16 that map into current telecommunications centers. While some neighboring regions may find it advantageous to leak full routes between themselves, there should be at least 12 that end up summarized. Yes a region has flat routes, but it doesn't need 3/4 of the global table, and all but a couple of cases will probably do better than that. The interconnection robustness at this scale is fairly high, so we could get some gain. Within the regions, it becomes a mater of local politics and business practice as to how much further the plan can go. Certainly it will be more difficult in either Europe or the US than all the others combined, but if you write off those 4 regions as hopelessly intertwined there is still an opportunity for significant gain in the rest of the world not having to know the details of that mess. > Not if the solution is worse than the problem. I believe that > geo addressing simply reproduces pre-CIDR IPv4, since it is based Hain Expires - December 2001 14 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format > on unrealistic assumptions about inter-ISP connectivity. Only over a given scope. The CIDR roll out effort also showed what backpressure from the top could do to constrain entropy. It also showed what happens if you push too hard. When you try to over- engineer and enforce controls for maximum optimization you will loose control and be back where you started. This is where the rewriting the goop plan falls flat, because they are targeted at absolute optimization in the middle, without concern for systemic impact. In either case, geo or provider, if provider policies allow the entire prefix to be carried in the DFZ there is nothing a protocol design can do about that. All that can be done is provide a tool that allows connectivity to be maintained when prefixes are abstracted. If a site wants absolute global control of its routing policy it will have to arrange for the full /48 to be carried and FP makes no difference. > Only if you revolutionise ISP interconnection strategies and > find some way to change the underlying economics. There is no need to change human nature, just provide a reasonable tool for aggregation then expect to charge for carrying explicit routes when people insist on them. Match the economics to human nature rather than trying to invent a technological restraint system. 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 [6] allocations. Relationship to Multi-6 WG multi-homing requirements The multi-homing requirements for IPv6, consistent with current IPv4 usage, are detailed in [11]. The capability of the Provider- Independent address format to deal with each of the points in that document will be addressed here. 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 a part of the path that lacks redundancy. Hain Expires - December 2001 15 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format Load Sharing û The Provider-Independent address format allows sites to manage outbound traffic without concern for undue filtering in the routing system. It also allows for a course-grain load sharing on inbound traffic, by managing service provider subscriptions to achieve the desired traffic flow matrix. 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 to that provider, and not transit any other provider. Policy û Traffic class alignment as policy routing is not an IP routing issue. As such the Provider-Independent address format will not offer any explicit support. Achieving the goal of this bullet is best met with a mix of Provider-Independent and Provider- Aggregatable prefix announcements. Simplicity û The target of the Provider-Independent address format is simplicity, both in the method of allocation, and in the routing expectations. The primary increase in complexity over current IPv4 deployments is the requirement for service providers within a short prefix scope to be capable of delivering traffic to all other providers serving the scope. Transport-Layer Survivability û The Provider-Independent address format explicitly deals with transport-layer survivability by isolating the connection from the intervening providers. As long as the routing system converges within the timeout period of the transport-layer, the connection will survive. Scalability û No one approach will solve all scalability concerns. An appropriate mix of Provider-Independent and Provider-Aggregatable 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 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. Hain Expires - December 2001 16 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format Impact on Hosts û Hosts will have an additional address to select from. Using longest- match rules should easily sort between Provider-Independent and Provider-Aggregatable prefixes. Other than that they may 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 will have an additional one in the list. 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. Random thoughts For global load-balancing hints to work all nodes will need to know their PI address, even if they never use it for anything else. The combination of Provider-Independent & Provider-Aggregatable should reduce the DFZ part of any router's table to < 256 entries. Local customers + administrative policy overrides of aggregates will make the entire table larger, but scale is directly controlled by the local administration. Due to the provider based allocation & interconnection matrix a multi-homed site may receive 8-16 FP-001 prefixes. If so, and the network manager feels this is a burden on the hosts, an appropriate subset should be selected to announce in the RA. Adding PI will not significantly make the problem worse. It is likely that policies would be biased to prefer PI for multi- homed sites, as connections would survive routing flaps. If so are they explicitly trading off fine-grained inbound policy control for resilience? If fine-grained inbound policy control is the goal, can that be achieved without complete pollution of the global routing table? How many sites really want inbound policy control vs. simple path redundancy and fail-over? If the vast majority are the latter will ISPs finally start charging the few remaining for the former? Hain Expires - December 2001 17 Application and Use of the IPv6 Provider- June 2001 Independent Global Unicast Address Format References 1 RFC-2026, Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Geo, Hain, T., "IPv6 Provider Independent global unicast address format", June 2001 3 RFC-2119, Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 4 http://www.wgs84.com/files/wgsman24.pdf 5 RFC-1518, Rekhter & Li, "An Architecture for IP Address Allocation with CIDR", September 1993 6 RFC-2374, Hinden, B., O'Dell, M., Deering, S., " An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998. 7 draft-hain-ipv6-PI-addr-00.txt, Hain, T., "An IPv6 Provider- Independent (Geographic Reference) Global Unicast Address Format", June 2001. 8 mobile-ipv6, Johnson, D., Perkins, C., " Mobility Support in IPv6", draft-ietf-mobileip-ipv6-13.txt, November 2000 9 http://www.ep.net/ 10 addr-selection, Draves, R., " Default Address Selection for IPv6", draft-ietf-ipngwg-default-addr-select-04.txt, May 2001. 11 requirements, Black, et. al., " IP Multihoming Requirements", draft-ietf-multi6-multihoming-requirements-01.txt, June 2001 Acknowledgments Early feedback was provided by Iljitsch van Beijnum, Brian Carpenter, Sean Doran, and Geoff Huston. Author's Addresses Tony Hain Cisco Systems 500 108th Ave. N.E. Suite 500 Bellevue, Wa. 98004 Email: alh-ietf@tndh.net Hain Expires - December 2001 18