Ipv6-wg folk, This is my candid view on IPv6 multihoming, comments welcomed. Enjoy, Michel. +-----------------------------------------------+ | Roadmap to IPv6 multihoming: no PI addresses. | +-----------------------------------------------+ Assessment of the current IPv6 multihoming situation: ----------------------------------------------------- - Regardless of the availability of multihoming protocols, independence from the service provider is highly desired by multihomers. - The pressure is increasing on RIRs to allocate PI blocks. - RIRs have delayed PI allocation as it creates long-term known problems. - The current policies effectively prohibit multihoming for everyone but ISPs (even RIRs themselves can not use PI addresses). - It is clear at this time that PA addresses alone do not address today's needs. The current roadmap to IPv6 multihoming is: - Offer a short-term alternative that would prevent the deployment of PI addresses: "geo for now". - Finish developing a long-term, scalable solution: MHAP. - ISP multihoming remains unchanged. "geo for now" ------------- The idea is to create a low-ambition geographic aggregation model that can be adopted using today's technology, requires no changes to physical infrastructure and few changes to current operational practices. Current work includes making geo for now and MHAP compatible to the migration from the shorter-term geo for now to the longer-term MHAP smooth. Geo addresses are: - Allocated depending on the location of the site. - Allocated by RIRs or NIRs - Locally portable. - Globally unique. - Aggregatable. Regardless of the actual aggregation ratio achieved, geo addresses are always preferable to PI; PI addresses will never be aggregated, geo will some day. Therefore, no IPv6 PI addresses must be ever used in any situation and geo addresses must be used instead. In other words, PI addresses offers no hope of aggregation, geo addresses do. The choice between PI and geo is a no-brainer: geo. MHAP ---- This is currently a working document of the ipv6mh mailing list. The draft is relatively mature and an earlier form was submitted to the IETF a year ago (it has evolved since then). MHAP is a full-blown mid to long-term solution. MHAP Features: - Zero impact on the DFZ's routing table. The DFZ's routing table stays strongly aggregated. - Provides multihomed, provider-independent, /48 address space for any site. - Very large organizations that require more can get a /47 or bigger. - Scalable (4 billion multihomed sites, initial allocation). - Addresses are aggregated at geographic areas boundaries. - There is no need for Internet eXchanges at aggregation boundaries. - MHAP is transparent to hosts. No modification of existing stacks is required and end-to-end traffic is unchanged. - More than 90% of routers would not require modification. - Provides global load balancing. - Provides survivability of open sessions. - There is no MTU reduction. - Can be run on hardware available today. - Gradual migration, no "flag day". - IPv6 only protocol. - MHAP provides site multihoming. ISP multihoming is unchanged. MHAP Concepts: - Multihomed address space exists only at the edge. The end-to-end multihomed traffic is carried over aggregated PA address space in the core. - A site gets PA addresses from ISPs and multihomed provider-independent space from a registry. - The process of transforming multihomed traffic to PA and back is called aliasing and relies on the presence of rendezvous points and aggregators. - Rendezvous points and aggregators answer topology requests. They do not carry traffic. - There is a separation between the DFZ's routing table and the multihomed space routing tables. The entire multihomed space is represented by two aggregates in the DFZ's routing table. - The only multihomed traffic on backbones is topology requests and routing updates. - There are two types of multihomed addresses: o Centralized, portable, for large multinational organizations. o Geographical, portable only within a geographic area. - There is no centralized table for geographic addresses. - The routing table for centralized prefixes remains contained to rendezvous points. - No multihomed site receives full multihomed tables. All a multihomed site needs is the small DFZ's routing table.