Tony Li wrote: [..]
We have a great deal of freedom to propose anything that results in a better routing architecture. Obviously, it should be clearly motivated and a rational extrapolation from the solution that we set forth. Could we specifically recommend HIP? Certainly, however working on it here would seem somewhat redundant.
You folks have more insight in that than me, but my take on it is that we have basically have the following situations:
* Big sites with a big address pool providing connectivity to loads of users. These will inject only a IPv6 /32 maybe per country they are in. Serve millions of users, require lots of addresses. => 1 routing slot per country or so, not a big burden * Content delivery sites, not a large prefix in general, but actually having a large amount of hosts behind them, though only few actually will be visible as most are behind load balancers. These might be globally distributed and anycasted and might have high routing activity for load balancing, data centers going down etc. => multiple routing slots, around the world * End-sites, small places which require static IPs due to firewalling and other static configurations (DNS). Don't change routing that often serve a 'small' amount of users. Prefix only present at one location. => 1 slot per small site, with many many many of those sites.There is of course then also the aspect of Traffic Engineering, which for all these above sites can cause extra entries in BGP.
Now, the first one, that is how people envisioned (from what I understand that is :) IPv6 routing to happen: large sites giving chunks of address space to small sites.
The problem with that of course being that people want to be independent and thus 'require' their address space to be globally visible thus we get more prefixes in there. Effectively though we only have a couple of organizations which actually are real "Tier 1"s, thus really only a few organizations really need a slot in the routing tables. Currently IPv6 allocations are given to anybody who can cough up the dough, this thus restricts in effect the really small sites (the latter group). The content folks generally have enough cash to cough up for a little prefix thus that is not a problem for them.
That actually leaves the latter group who are most likely one of the locations that want to have a global independent address but should not have a slot in the routing tables if we want to keep those to a low number in the long long long run (we really have no idea if that number will explode or not, and also of course if the hardware will or will not be able to keep up with it, it might just be that they can scale, but the question then is can and will everybody scale up?).
Currently we already have two solutions which will solve most of the requirements from the latter group: SCTP and HIP. The only big problem with both of those being that everybody everywhere needs to start using them and have them available, next to changing the mentality of application programmers and of course also the people who are developing it. Oh and there is of course the issue of people simply stating "we do it like this now, lets do it like that tomorrow", which is not helping much either.
SCTP would require heavy vendor support to get rolling, especially in the Microsoft area it needs to be installed per default, if is not installed per default, then (unless there is a magic thing that people crave and they will install something for it) SCTP will never happen and when it is not at the endsite then it won't happen at the providers either. This is more or less the same issue as IPv6: chicken-egg. There is one advantage here though, it does not require anything in the middle, except maybe firewalls to allow it to work.
Greets, Jeroen
Attachment:
signature.asc
Description: OpenPGP digital signature