On Jun 25, 2012, at 12:06 AM, Masataka Ohta wrote:
Justin M. Streiner wrote:
I see periodic upticks in the growth of the global v6 routing table (a little over 9k prefixes at the moment - the v4 global view is about 415k prefixes right now), which I would reasonably attribute an upswing in networks getting initial assignments.
As I already wrote:
: That's not the point. The problem is that SRAMs scale well but : CAMs do not.
it is a lot more difficult to quickly look up 1M routes with /48 than 2M routes with /24.
It is incrementally more difficult, but not a lot at this point. Further, 2M routes in IPv4 at the current prefix:ASN ratios would only map to about 100,000 routes in IPv6. (IPv6 prefix:AS ratio is currently about 3:1 while IPv4 is around 14:1, so if all 35,000 active AS were advertising 3 IPv6 routes, we would be at about 100,000. Most of the growth in the IPv4 routing table represents increases in the prefix:ASN ratio whereas most of the growth in the IPv6 routing table represents additional ASNs coming online with IPv6.)
If anything, I see more of a chance for the v4 routing table to grow more out of control, as v4 blocks get chopped up into smaller and smaller pieces in an ultimately vain effort to squeeze a little more mileage out of IPv4.
The routing table grows mostly because of multihoming, regardless of whether it is v4 or v6.
Assertion proved false by actual data. The majority of the growth in the IPv4 routing table is actually due to disaggregation and slow start. A smaller proportion is due to traffic engineering and multihoming. (See Geoff Huston's various presentations and white papers on this).
The only solution is, IMO, to let multihomed sites have multiple prefixes inherited from their upper ISPs, still keeping the sites' ability to control loads between incoming multiple links.
This is not a solution. This is an administrative nightmare for the multihomed sites which has very poor failure survival characteristics. 1. Established flows do not survive a failover. 2. Every end host has to have knowledge of reachability which is not readily available in order to make a proper source address selection. The solution, in fact, is to move IDR to being locator based while intra-domain routing is done on prefix. This would allow the global table to only contain locator information and not care about prefixes. Currently, in order to do that, we unfortunately have to wrap the entire datagram up inside another datagram. If we were to create a version of the IPv6 header that had a field for destination ASN, we could do this without encapsulation. Unfortunately, encapsulation brings all the MTU baggage of tunneling. More unfortunately, changing the header comes with the need to touch the IP stack on every end host. Neither is an attractive option. It would have been better if IETF had actually solved this instead of punting on it when developing IPv6. Owen