Approach to allocating netblocks

Mailman List Mirror (Read Only)
1

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?

I was thinking of having one /24 for each block size, and then do the divide
and conquer approach by allocating the first /30, for example, as 0 and 128,
then next two at 64 and 192, etc. Once there's only one /30 free between
each allocation, I would start using another /24. Of course, that would
mean 50% (or less) utilization.

Ideas?

Frank

2

If most of your allocations are small, and you don't plan on growing
them very often, you'll probably do better with starting at the ends and
working your way inward.For example,. for /30s, allocate 0/30, then
4/30, 248/30, and 252/30 before moving in to 8/30, 12/30, 240/30, and
244/30. That way you're preserving larger netblocks for as long as
possible before breaking them up.

Frank Bulk wrote:

3

I see what you're saying, but what if the customer whom you assigned the
0/30 to wants a larger block...rather than making them renumber (which in
the case of a small customer, is a very painful experience because of all
the DNS and router/firewall reconfiguration issues that they don't normally
deal with and therefore cause their service provider (us) and their
consultant a lot of grief), I would want to give them 0/29. But if the 4/30
is already assigned to someone else, I'm stuck.

But perhaps the BCP is to make the customer renumber, in which case I'm
making things more complicated than they need to be.

Frank

4

Customer should have the forethought to request the right amount of space to
include for growth.

If customer requested more space, rather than grow into another adjacent
block, we would just assign them an additional block elsewhere in the
overall subnet, and route both blocks to them.

Jason

5

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?

We pay much more attn to efficient utilization and advertisement
aggregation than to ensuring that customers have contiguous blocks.

For example, we internally assign a /24 to a given PE router and then
assign from it straight through; 0/30, 4/30, 8/29, etc. as customers
get turned up or request more space. Then when it's used up, we add
another... Although it is neat and tidy to have contiguous blocks
everywhere, the cost to benefit doesn't seem to be there so we focus
on aggregation at transition points such as edge to backbone, backbone
to peers, etc.

~Chris

6

I guess it might depend on the general profile of your customers'
requirements, but I'd imagine that non-contiguous blocks will be far
more efficient in the long run, with the added benefit of no need for
customers to pursue a renumbering plan every N years which should
nearly always be avoided in any case imho. Obviously, the smaller the
average block size the less efficient it becomes. If the customers are
honest in their expected future ip address requirements it shouldn't
be that often that they'll need more address space in any case.

Aidan

7

Customer should have the forethought to request the right amount of space to
include for growth.

hmm, as a vict^H^H^H^H former associate of a few startups I can
assure you the customer will almost never know how much space
they need for growth, or when. :slight_smile:

If customer requested more space, rather than grow into another adjacent
block, we would just assign them an additional block elsewhere in the
overall subnet, and route both blocks to them.

Seems reasonable as long as it can be done whenever the customer
discovers they really do need more space.

Jeff Kinz

8

Most customers with PA space (which is what you are giving them) are quite
used to renumbering. If not, they will become, given v6 PAishness.

Renumbering is not to be avoided at all costs, because:

Renumbering cleans cruft and finds mishaps waiting to happen.
Renumbering rewards those who have done proper configuration separation.
Renumbering rewards those who have automated their systems management.
Renumbering thus is good for you.

There are economic incentives (keeping the customer because said customer
hovers in the Lagrange point between clueless and lazy) to let suboptimal
numbering schemes fester. Might alter picture above, but from operational
standpoint renumbering is not that bad.

9

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.

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

10

<snip>

Given the small netmasks, I'd guess that most of the browser population
behind them is addicted to a proxy. The proxy might not subscribe to
pinning.

Also, the browsers that run for months typically aren't on end-user PCs,
but on the workstations of the clued, if I might be so blunt.

It is not that renumbering is painless, not at all. But it is very useful
as "spring cleaning". I'd rather know what happens by testing it than
finding out by being woken up while on call.

11

I hesitate to put my customers in "the Lagrange point between clueless and lazy" because they're SMBs doing what 99% of the other SMBs out there do. I have some customers who are in the hub in a multi-site VPN network and renumbering would be very painful.

While Renumbering has all the positives you mentioned, it's a sure way to sour the customer relationship. Much cheaper, long-term, to set aside adjacent address space.

Frank