Approach to allocating netblocks

Thu Jan 15 20:11:48 UTC 2009

On Wed, Jan 14, 2009 at 11:05 AM, Frank Bulk <frnkblk at iname.com> wrote:
> For the first time we have our own ARIN-assigned netblocks that we can now
> split out and divide to our customers.
>
> What's the best approach to handing out /30's, /29's, etc. that is efficient
> as possible but allows for customers to expand their allocation to a
> neighboring block?

Frank,

Prioritize the following optimization criteria in order of importance to you:

1. Most efficient use of address space.
2. Maximum routing aggregability.
3. Highest probability of expansion by only changing the netmask

Solution to #1: For each new assignment, select the smallest block of
available addresses which is large enough to accommodate the new
assignment, where a "block" is defined as a network plus netmask, not
defined as a range of addresses. Carve the assignment from the end of
the block.

Downside: expansion by changing the netmask is unlikely since the
assignments are all crunched together.

Solution to #2: Split your ARIN netblock based on your current and
anticipated routing areas. Inside each sub-block, implement your
second priority.

Downside: Over time this becomes futile as your routing areas move,
split and merge.

Solution to #3: For each new assignment, select the largest block of
available addresses. Split it in half, placing the new assignment in
the middle. When the assignee expands, there is a relatively high
probability that the adjacent part of the next shorter netmask is
still available. This is called "sparse allocation."

Downside: This fragments the heck out of your address space. You will
typically only be able to assign address blocks whose netmask is more
than log2(n) bits longer than the netmask of your ARIN block where n
is the total number of assignments you've already made. For example,
after assigning 150 /29's from your /20, the largest remaining block
would be a /28. Assign 150 more /30's and your largest remaining block
would be a /29! With Solution #1, you'd still have an untouched /21.

You can do a hybrid of #1 and #3 by doing things like "pick the
smallest block that's at least 4 times the size you need, split in
half, etc." Or, you might split the ARIN block in half and do #3 for
/28 and longer assignments in the first half and #1 for /27 and
shorter assignments in the second. Unfortunately, the efficacy of such
approaches is unproven.

Unless you have a particularly large system (and if this is your first
ARIN block, you don't) just go with solution #1 so that you don't run
into problems with what will probably be tightening criteria for
subsequent IPv4 address assignment.

On Thu, Jan 15, 2009 at 5:16 AM, Måns Nilsson <mansaxel at besserwisser.org> wrote:
> from operational standpoint renumbering is not that bad.

Måns,

http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-01.txt
provides 24 pages and growing worth of problems with renumbering.

Here's a simple one:

Web browsers intentionally violate the DNS TTL with a technique called
"DNS Pinning." DNS Pinning limits acceptance of server IP address
changes due to a javascript issue where repeated address changes could
otherwise be used to induce a browser to scan the inside of a
firewalled network and report the results to an outside attacker. This
can persist as long as the browser is running, perhaps months at a
time.

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