LET'S JUST GO AROUND
You keep quoting from the *assignment* section of RFC2050. That
criteria is for end-sites requesting address space directly from
the registries. Please reread the RFC, specifically the *allocation*
section that refers to ISPs.
> Content-Type: text/plain; charset=us-ascii
> On Thu, 06 Feb 1997 17:37:44 +0200, Alan Barrett said:
> > Both small and big providers have to justify their address space
> > requirements to the registry. Both small and big providers have to either
> > pay for others to carry their routes, or persuade others that their routes
> > should be carried for no charge.
> > So, in what way are small businesses being unfairly treated?
> The basic problem is that the "general guidelines" in RFC2050 say that
> you should have 25% *IMMEDIATE* use of an allocation - you don't get
> one until you will be at least 1/4 full.. So for a /19, you can be
> denied getting it until you have 2048 addresses *IN USE*. And this is
> *after* you've already started doing DHCP and all for those PC's and
> Macs that subscribe to your ISP.
> So it's possible that you don't get a prefix big enough to really
> multihome until you have so many subscribers that you have 2K of them
> connected *AT ONE TIME*. If you assume that the average subscriber is
> connected 2 hours a day, and mostly within a 12-hour "prime time",
> this means you need close to 12-15K or more subscribers to get 2K on
> at one time so you can get your /19.
> Now - try to get to 15K subscribers *without* multihoming. Remember
> that if you're only single-homed, you're right off the bat less
> reliable than a multi-homed (the whole point is redundancy). This
> will cost you market share.
> We're not talking about "mom and pop" ISPs getting cut out here.
> We're talking about ISPs that have 15K customers being cut out, to the
> benefit of those that are already 10X bigger than that. Hmm.. 15K
> customers, at $20/mo a pop, that's about $3.6M/year cash flow.
> And still not big enough to qualify for effective multihoming.
> That's the problem.
> Valdis Kletnieks
> Computer Systems Engineer
> Virginia Tech
> Content-Type: application/pgp-signature
> -----BEGIN PGP MESSAGE-----
> Version: 2.6.2
> -----END PGP MESSAGE-----