In IPv4, enterprises and other organizations can protect themselves from
ISP and telco outages by connecting to more than one ISP (multihoming).
This means the organization's IP address range must be visible in the
global routing table, which now holds approximately 115,000 routes.
The same thing could be done in IPv6, but it isn't, since this type of
multihoming isn't considered scalable enough. The multi6 working group
has been working on requirements for multihoming in IPv6 for a while
now, coming close to consensus on several occasions but never quite
reaching it.
Unfortunately, there is no multi6 meeting on the agenda for Atlanta.
That doesn't mean there is nothing to discuss. Solutions in the
following areas have been proposed:
1. geographical aggregation (draft-van-beijnum-multi6-isp-int-aggr-00.txt)
2. have boxes sit between the internal network and the border routers
that map between provider independent, but not globally routable, and
provider aggregatable address ranges (for instance,
http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt)
3. extend mobility so entire sites can benefit from it
4. have multi-address aware transport protocols, such as SCTP
5. revisit/improve GSE/8+8
6. even more radical identifier/locator decoupling (hostnames as identifiers?)
As it looks like the long term solution will be some kind of
identifier/locator separation which will have a huge impact on all
aspects of IPv6, I think this topic deserves attention from a wider
audience than it's getting now.
(Since this will take a while to get off the ground, I think we need
something like my geo solution for immediate/short term relief, which
will scale one to two orders of magnitude, as well.)
Some of us will be getting into this deeper next week in Atlanta, and we
would be happy to provide an overview of what has been discussed on
multi6 (not just our own drafts/ideas) to anyone who's interested.
Contact me off-list for this.
Iljitsch van Beijnum
PS. Let me remind you in advance that this is NOT the forum to discuss
the feasability of geographical aggregation or any of the other
solutions mentioned. However, I'd be happy to discuss any and all of
this off-list.