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

[Jørgen Hovland]

I dont really think there is a problem.  If everybody used ipv6 instead of
ipv4 right now, we would probably have less prefixes than today. There are
around 109327 ipv4 prefixes today, but only around 65000 as numbers.
Im not sure really how big/the usage of a ipv6 /35 is if you compare it to a
ipv4 /16.  There are no lir's today with more than 1 real ipv6 prefix
anyway? That would result in something like: number of asn's == number of
prefixes wouldnt it?

As you stated, the problem might begin with too many wanting a multihomed
solution.
Since becoming a LIR is not free (atleast not in europe/ripe), it would
restrict itself.  Small company's probably wont spend that ammount of money
just to get a LIR membership.  Its not worth it. Some enterprises do need
multihoming: stockexchanges, banks etc. Only allowing isp's to be multihomed
is crap.  As long as the price for LIR membership is high enough, the
problem is solved :-)

I agree with the PI-address suggestion. They should drop it completely.

Right now, I recieved an email from ripe. They are implementing a new global
ipv6 policy. Im not familiar with it, but Im looking forward to read it.
Maybe somebody knows whats it about?

---------------
Dear Colleagues,

We are pleased to announce that the RIPE NCC will implement the new
Global IPv6 Policy on 1 July 2002. This policy has been agreed by
the communities of all the Regional Internet Registries (RIRs).

Before 1 July 2002 we will publish and announce the following as
RIPE Documents:

        - Global IPv6 Policy Document
        - Initial IPv6 Allocation Request Form in the RIPE NCC
          Service Region
        - IPv6 End User Site Assignment Request Form in the RIPE
          NCC Service Region (for prefixes shorter than a /48)

------------------------------

Joergen Hovland
WebOnline AS

----- Original Message -----
From: "Michel Py" <michel@arneill-py.sacramento.ca.us>
To: <6bone@ISI.EDU>
Sent: Thursday, May 23, 2002 5:45 AM
Subject: [6bone] Roadmap to IPv6 multihoming: no PI addresses.


> 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.
>
> _______________________________________________
> 6bone mailing list
> 6bone@mailman.isi.edu
> http://mailman.isi.edu/mailman/listinfo/6bone
>