RE: (ipv6mh) about MHAP draft

["Michel Py" <michel@arneill-py.sacramento.ca.us>]

> Juan Francisco Rodriguez Hervella wrote:
> I'm trying to understand this draft, but there are a
> lot of terminology and definitions at the beginning and
> I don't see the main idea clearly. How does it work ?
> I think it's worth to underline the features and try to
> explain how this works *briefly*, maybe in another paper ?

Here is the main idea:

6.1.24. The general principle of address aliasing is as follows:
- Multihomed traffic is to be aliased and carried over the Internet as
singlehomed traffic.
- When the IPv6 packet or datagram is processed by the first aliasing-
capable router along its path (an MHAP client in most situations) the
multihomed destination IPv6 address is replaced with one of the
possible singlehomed PA addresses.
- When this aliased packet reaches the destination site's MHAP
endpoint, the singlehomed destination PA address is replaced
(unaliased) with the original multihomed destination address.
- Contrary to most NATs, MHAP replaces the destination address, not the
source.

Here is the sales pitch:

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.


> If someday someone wants to apply this solution, likely
> he will fed up of reading this paper. Don't get angry
> with me, I'm making a positive review :)

I know this, the draft is due for a complete rewrite for Atlanta....

Michel.