On Mon, 4 Apr 2005 18:13:54 +0100, Jon Lawrence wrote:
There are bound to be mistakes, like you say. However, one of the major mistakes with v4 (imho) was the initial handing out of large amounts of address space to people who had no use for that many addresses. We're not faced with the quite same problems of address space exhaustion with v6, but I see absolutely no reason to repeat the same errors over and over by just wasting the address resources. I'd rather see large routing tables rather than in 10 years time find we're running out of v6 space. Well, we will also see routers beeing capable to route more than 150K prefixes. We can even see them today.
And there are really PC's with more than 640K of RAM ;-) 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.
Most of this seems to stem from the simple requirement to multihome (anycast or otherwise). Perhaps we should just wait for the final recommendations from multi6 and see what they've come up with. I always had the oppinion the "no risk at all, better no decision than some decision, let us better wait until the project is dead" approach is called the *German* disease ... :-|
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 ;-/ However there *is* an IPv4 solution called PI/BGP4 and we won't convince customers to adopt an 128 Bit address space if even the old effective 24 Bit international routing won't be available any more :-( For a 128 Bit address space from a users point of view I would expect at least an full international routing of 48 Bits, which means *of course* a *larger* number of *possible* prefixes. This has nothing to do with "old mistakes", if we can't route this range with independent prefixes, *forget it*. 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. Below 500K, BGP4 is ok for sure, and 20K is much less than 500K. Ceterum censeo: 1. If routers can't route 20K *IPv6* prefixes, it is better to drop this technology now. Simply because routers *can/must* route >>150K IPv4 prefixes. If it seems so dificult to implement IPv6 that we can't afford even one prefix per paying LIR, then it is obvious that IPv4 is clearly the better technology and we should stay with it rather than switching to IPv6. ( Let us all save the money and let's have a big "final IPv6" party ;-/ 2. If we want to shift IPv6 to a common and commercial *product* rather than a toy-place for techies, we should *distribute* it and not restrict it. You can't sell the shoes and restrict them with a don't-wear-them policy ... I do fully agree with Gert: "because if IPv6 isn't going to take up soon, it's dead." And I also fully agree with the policy proposal. Best regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0