[ipv6-wg] Re: 200 customer requirements for IPv6

Daniel Roesen <dr at 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