Oliver, Would you please invest some time into discovering how grownups use email? The excessive funny interpunction hurts my eyes. On 4-apr-05, at 21:10, Oliver Bartels wrote:
I'd rather see large routing tables rather than in 10 years time find we're running out of v6 space.
Whatever we do, we're not going to run out of IPv6 space. Worst case, we have to start subdividing /64s and kill autoconfiguration, but that way we still have four billion times as many addresses in a single /64 as in the whole IPv4 internet. That said, the HD ratio and strange new ways to distribute from IANA to RIRs may eat up the bits from 3 - 47 much faster than we could have imagined at the time that IPv6 was designed, so we shouldn't waste v6 space like there is no tomorrow. Still, the routing table size problem is much more pressing than the depletion problem in IPv6 because even if the table size isn't fatal, it can get expensive easily, and when it gets fatal there is no way to fix it (even if we give up autoconfiguration).
Well, we will also see routers beeing capable to route more than 150K prefixes. We can even see them today.
Well, we're never going to run out of oil either, but at some point it's going to be so expensive to get it out of the ground that it's easier to leave it there and walk to work. I'm not sure what the cheapest router is that can handle a full table today, but I'm pretty sure it's more expensive than what one that could 10 years ago cost then (ie a Cisco 2501).
At these old days when these 64MB routers were designed, RAM chips had 4 to 16 MBits of RAM. Today we are talking about min. 256MBit SDRAM dies, smaller SDRAM's will have their "call for last order" very soon now.
Ah, but if you have N * 2 routing table entries, not only do you need 2 times the memory, but all else being equal you're going to see 2 times as many updates, so assuming you need to search N * 2 entries before you can update one (which fortunately isn't the case, the exact math is left as an excercise to the reader) you need 2 * 2 = 4 times as much memory bandwidth. It's not just a factor of more memory.
Again for multiv6: *There won't be a *full* and *unrestricted* solution, the we_want_multiv6_but_keep_BGP4 approach has fundamental laws of math and computer science against it:
An *address* is an *address* and is spoken *address*, because it addresses something, which means it guides something to a destination, which does not mean that it just references something and let's some unknown big wonder do the job ;-/
I have no idea what you're talking about here.
But it is possible, BGP4 is proven with existing products for appx. 500K prefixes, if more is needed, I would suggest thinking of an protocol update.
And what exactly would that update entail? The problem isn't BGP (although BGP has problems for sure) but the fundamental problem that if you can't derive the answer you're looking for from the information you already have, you'll have to go to the place where the information is kept. I.e., you need to search the routing table.
I do fully agree with Gert: "because if IPv6 isn't going to take up soon, it's dead."
I'm not sure how having a new techology available before the old technology implodes is a problem.