The race is on… One or more of these things will be the death of IPv4: 1. Not enough addresses 2. Routing Table Bloat due to one or more of: A. Traffic Engineering B. Stupid configuration C. Address Fragmentation through transfers and microallocations of “Transition space” D. Stupid network designs (where the physical deployment forces something like B rather than just software stupidity) 3. Some highly desirable feature or application which simply can’t be implemented effectively on IPv4. As such, I say go ahead and route whatever. ARIN provides a nice constrained prefix for these transitional allocations so you can at least limit the bloat from that factor, but even at the /24 level, we’re faced with upwards of 16 million routes that we are nowhere near ready to handle. In case you haven’t been paying attention for the last 25 years, there are a number of ways in which IPv4 DOES NOT SCALE. We’ve been keeping it alive on life support for a VERY LONG time. As with all patients on life support, the longer it continues, the more it becomes a losing battle and the harder (and more resource intensive and more expensive) it becomes to keep the patient alive. Fortunately, in this case, we have a nice new body that we can transplant the internet into that has many fruitful years ahead of it. So… Do whatever you have to to survive in the meantime, but focus on getting your stuff onto the IPv6 internet so that we can all let IPv4 go gently into that good night and have it’s well deserved final rest. Owen
On Oct 3, 2015, at 06:18 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
Except we might very well reach 1+ million routes soon without accepting longer prefixes than /24. Also route updates is a concern - do I really need to be informed every time someone on the other end of the world resets a link?
On 3 October 2015 at 12:57, William Waites <wwaites@tardis.ed.ac.uk> wrote:
On Sat, 3 Oct 2015 12:42:01 +0200, Baldur Norddahl < baldur.norddahl@gmail.com> said:
2 million routes will not be enough if we go full /27. This is not a scalable solution. Something else is needed to provide multihoming for small networks (LISP?).
It's not too far off though. One way of looking at it is, for each extra bit we allow, we potentially double the table size. So with 500k routes and a /24 limit now, we might expect 4 million with /27. Not exactly because it depends strongly on the distribution of prefix lengths, but probably not a bad guess.
Also there are optimisations that I wonder if the vendors are doing to preserve TCAM such as aggregating adjacent networks with the same next hop into the supernet. That would mitigate the impact of wanton deaggregation at least and the algorithm doesn't look too hard. Do the big iron vendors do this?
-w
-- William Waites <wwaites@tardis.ed.ac.uk> | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh https://hubs.net.uk/ | HUBS AS60241
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.