Thus spake "Pekka Savola" <pekkas@netcore.fi>
On Thu, 20 Apr 2006, Stephen Sprunk wrote:
I think that the multihoming requirement will be enough to keep the number of assignments reasonable; if you look at the actual number of non-transit ASNs in the v4 table, it's not all that large. If we assume one PIv6 prefix per non-transit ASN, which is the goal, we're looking at under 10k routes from the ARIN region.
(Actually, the number is somewhere between 15k and 20k but that's beside the point.)
ARIN Region origin ASes present in the Internet Routing Table: 10637 ... ARIN Region transit ASes present in the Internet Routing Table: 986 To me, that says we have 9651 non-transit ASes in ARIN-land today. Now, if every one of those ASes got an assignment under 2005-1, we'd kick up the size of the v6 routing table to 14 times its current size -- but it'd still be only 1/18th of the current v4 table. Where's the problem?
The upper limit is around the number of AS numbers, and if it's expanded to 32 bits, at least I start to feel uncomforable... "Umm.. are we sure 64K folks playing around at DFZ isn't enough??? we want 4B instead...????"
There's at least one router vendor that claims their box can do 1M routes today; Moore's Law says in 18 years they'll be able to do 4B ASes with one prefix each. I'm pretty confident we won't run into that particular limit before we run out of networks to multihome, at least not with the proposal on the table today.
Remember, it's easy and cheap to have a multihoming setup with two DSL lines...
That loophole in the definition of multihoming needs to be fixed. For that matter, ARIN told me offlist that two IP-in-IP tunnels over a single physical link counts as multihoming... Sheesh. OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two pipes or tunnels), and there's not all that many companies doing it. It's not growing much either. The doors are already wide open for a land rush and nobody is taking ARIN up on it. Why does everyone assume it'll happen with v6 if it's not happening with v4, which _is_ useful today?
setting a foundation for multihoming research to actually SOLVE this problem, etc.etc.
In theory, we already have a group tasked with that: the IETF. Are you proposing that RIRs start developing protocols outside the IETF? Or funding people to work full-time in the IETF on problems pertinent to RIRs? Again, this is a slippery slope and distracts from the RIRs' purpose.
I said 'research', not 'engineering'. The IETF isn't the right vessel for research, though IETF could maybe be consulted on it.
s/IETF/IRTF/ then. The RRG is expecting to have results sometime between 2007 and 2011. That's probably sufficient, if they actually deliver something useful. Still, the RIRs' job is not research, it is stewardship of address space and serving its members.
I wouldn't object to reserving a /44 just in case, but make no provisions (at this point) for applying more. If someone needs more than /48, it needs to justify another one, and get a separate /48 (with its own reserved /44).
So instead of giving an org a /47, which _could_ be advertised as a single route, you'd prefer to give them two /48s, which _must_ be advertised as two routes? That seems to increase routing table pollution, not reduce it.
Not necessarily. Doing so would hopefully ensure that it'll be *more* difficult to justify for more than a /48 especially if you have to pay for the extra too (hence less pollution). I.e., we'd need to figure out we have sufficiently strict criteria.
That just seems backwards to me. If a site _can_ justify more than a /48 under whatever the policy is, why would we want to assign two separate blocks that can't be aggregated into a single route?
Also, what's the point of reserving a /44, or worse multiple /44s, if we're only going to let people use a /48? That seems to defeat the purpose of having a reserved block.
As I said, I wouldn't object to reserving a /44 under those conditions, but I wouldn't require reservation either. One reason for reserving is that we could have the option of changing the policy later if we become wiser (or dumber) and decide that maybe we'll want to be able to deal out aggregatable chunks after all, regardless of the more specific crap that's filling the routing tables right now.
If we're going to reserve, we ought to assign supernets within that block as justified by the org. If they deaggregate, so be it, but at least there's the chance they won't. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin