[6bone] Roadmap to IPv6 multihoming: no PI addresses.

[Michel Py]

6boner,

My candid view on IPv6 multihoming, comments welcomed.

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.