Home page logo
/

nanog logo nanog mailing list archives

Re: Approach to allocating netblocks
From: William Herrin <herrin-nanog () dirtside com>
Date: Thu, 15 Jan 2009 15:11:48 -0500

On Wed, Jan 14, 2009 at 11:05 AM, Frank Bulk <frnkblk () 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 () 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 () dirtside com  bill () herrin us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]