Daniel Roesen <dr@cluenet.de> writes:

The folks all having their own /32 already allocated to them and trying to limit independent address space to "service providers" (or those who manage to pretend being it, which seems to be easy) are still arguing for "not for them!" paradigm - easy position with having their own dishes already done.

With all due respect, these sorts of comments are not helpful. They imply bad motivations on some, that IMO, are simply false. There are (IMO) valid reasons for not giving out /32s to everyone. The original (and still compelling, IMO) rational behind the current policy is to ensure good aggregation for the long term, in order to keep the number of distinct prefixes in the DFZ manageable. Hence, the current policy is oriented not towards _all_ ISPs, but those who will (hopefully) have _many_ customers that they assign addresses too. That is, they aggregate addresses for _many_ customers. That is where the "plan for 200 customers" wording originally came from. The presumption is that an ISP/LIR that realistically expects to have 200 customers will be aggregating _many_ customer addresses. If an ISP will have (say) only 100 customers long term, its not at all clear that they will be aggregating significant amounts of address space. Note, I'm not defending the the "200 customer" rule per se; I understand that it is viewed as problematic. But I think the motivation that led to it is still valid, and when folk say "get rid of this requirement," I object to "forgetting" about the original concern when coming up with a replacement policy.

Until we have a clear full replacement (that means a solution which does NOT ignore real requirements like shim6 does) there should be a very simple PI policy which issues a /48 or whatever to end sites at a nominal small fee, paid directly to the RIR. An initial setup fee and a yearly renewal fee, paid by credit card or something equally simple. No payment => assignment withdrawn. The initial fee covering the cost of evaluation of the request, doing the assignment and setting up the billing account and DNS reverse. The yearly fee covering the maintenance of the entries in the database and DNS rev NS RRset and the yearly recurring fee invoicing/billing. Done.

Note that ARIN has been and continues to have discussions about how to give out PI space to end sites, but in a way that doesn't explode the routing tables going forward. I think there is (very strong) support for the idea of giving out more PI space, the difficulty has been in coming up with details that people are comfortable won't explode the routing tables going forward. I.e., that in five years we look back and say "oops, we should not have done that, now what do we do"

Setting aside my disbelieve in the FUD about the scalability problem of real BGP multihoming (noone yet has shown that the relative amount of multihomers does or will explode),

Um, do the math. How many end sites do you think will want to multihome ten years from now? Can you honestly/realistically say it won't be a million? Can the routing infrastructure handle that? (Enough people say "not sure" that IMO it would be foolish to just assume we can do this). Thomas