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.