Faster 'Net growth rate raises fears about routers
gmaxwell at martin.fl.us
Tue Apr 3 14:52:09 UTC 2001
On Tue, 3 Apr 2001, RJ Atkinson wrote:
> At 08:37 03/04/01, Greg Maxwell wrote:
> >Replace the internet with a highly aggregated IPv6 network
> >which uses transport level multihoming and you gain a factor
> >of 1000 improvement at core routers (and 100,000x further
> >from the core where you no longer need to be default-free)
> >and still have the oppturnity for a further 5x by going
> >to a state-of-the-art CPU (providing that your cpu speed
> >reasoning is valid).
> Precisely which "highly aggregated IPv6 network
> which uses transport level multihoming" is one talking about ?
> What's the RFC on this ?
It's possible to 'solve' these problems in the future:
Forbid IP level multihoming for IPv6 which crosses aggregation boundaries.
I.e. absolutly no multihoming that inflates more then your providers
routing tabling, connect to whoever you want, but no AS should emit a
route for any other AS without aggregating it into their own space without
a special agreement of limited scope (i.e. not globally!)
> AFAIK, IPv6 multihoming is identical to IPv4 multihoming,
> with all the same adverse implications on the default-free routing
> table -- hence the creation of an IETF MULTI6 WG to try
> to change this. If I've missed some recent advance in the
> IETF specifications, please share the details (preferably citing
> RFC and page number :-) with the rest of us.
IPv6 multihoming *is* the same.
What I argue is that: Routers are the wrong place to do multihoming for
anything but Tier-1 connectivity. Multihoming belongs in the end node.
SCTP (2960) is a transport level protcol which offers what amounts to a
superset of TCP. One of it's features is multihoming (2960; section 6.4).
With such a protcol it is possible to accomplish all of the realibility
benifits of IP multihoming while achieving much greater scalability,
flexibility, and performance.
We need to stop looking at IP addresses as host-identifyers (thats what
DNS is for) and look at them as path-identifyers.
I'm not sure of an RFC detailing specifics of an Internet architecture
based on these concepts, thats one of the reasons I asked here. I'll troll
around more and see if I can find anyone working on such a document and if
no one is, I'll create one.
More information about the NANOG