IPv6 Addressing Help

Sat Aug 15 15:29:46 UTC 2009

On Sat, Aug 15, 2009 at 2:34 AM, Randy Bush<randy at psg.com> wrote:
>> I'm going to contradict you there. Classful addressing had a lot to
>> recommend it. The basic problem we ran in to was that there weren't
>> enough B's for everyone who needed more than a C and there weren't
>> enough A's period. So we started handing out groups of disaggregate
>> C's and that path led to the swamp.
>
> the swamp preceeded cidr

Randy,

Correct. Disaggregate classful blocks overwhelming the routers was
part of the problem. CIDR was part of the solution. That's what I
said.

> and, if you had a bit of simple arithmetic clue, you would realize that,
> unless you are prescient, you will always run out of some classes before
> others.

Of course. That's what reserves are for: a resource you move into
place after you discover where it's needed. Whether its a reserve
force in a military action, the reserve slack in your unix disk
partition or the emergency fund in your bank account, this is a long
solved problem in human endeavor.

On Sat, Aug 15, 2009 at 3:03 AM, Nathan Ward<nanog at daork.net> wrote:
> Read about how sparse allocation/binary chop stuff works. You get the same
> amount of routes in your IGP table (or less) but it's much more flexible.

Sparse allocation says that you maximize the potential expansion of an
allocation by simply changing its netmask. That means your first two
allocations go at 0% and 50% (allowing either to expand to half your
space), your next two go at 25% and 75% (allowing any to expand to
1/4th of your space) and so on.

Let's try some of Randy's simple arithmetic on sparse allocation.

Start with: /32
Sparsely allocate 200 /56's

Total remaining space: in excess of /33. In fact, you haven't consumed
a single /48.
Expandability by altering the netmask: to /40
Largest allocation still possible: only /40

See the problem? You've eaten 8 bits of capability long before you've
consumed even half of your space. In fact, when you do consume close
to half your space, the largest remaining block is a meager /47 and
your expandability of all those /56's is only to /47.

Software developers very rarely fragment a resource pool on purpose
because of precisely this problem.

On the other hand, consider an escalating pools (aka classful) scenario:

/32 broken into four pools:
/34 for the /60 pool
/34 for the /56 pool
/34 for the /48 and larger pool
/34 for the reserve pool

Assume that:
90% of allocations are /60
9.9% are /56
0.1% are /48 or larger

100,000 allocations into this strategy you haven't tapped the reserve
pool and it's probably still possible for you to allocate a /35 from
the /48+ pool.

And the price for this structure is that a small number of the
registrants will have more than 1 but less than 4 routes (one each of
/60, /56 and /48+) as opposed to sparse allocation improves the
probability that they'll have only 1 route.

On the other hand, 100,000 allocations in to the fore-mentioned sparse
allocation, while there's a higher probability of each user having
only 1 route, the largest users will need many more than 1. You've
used a total of /42, maybe a little more of your space but your
largest remaining free space is only /48. So if you need to accomodate
a /44 customer, you'll have to give him 16 discontiguous /48's.

Sparse is a farce.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004