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