Dividing up a small IPv4 block

Steve Bertrand steve at ipv6canada.com
Tue Jun 22 02:02:36 UTC 2010


Hi all,

I've got a local v4 peer (ie. an ISP whom I lease fibre from to feed my
clients, they peer with me directly, and we're about to provide mutual
transit for one another).

They (hereinafter 'client') have recently received a /22 from ARIN. The
client's immediate need is to re-assign a /23 to an ISP client that they
have, which effectively leaves them with one /23.

The client has asked me to help design an IP addressing scheme that will
suit the rest of their clients (most require /29's), their internal
infrastructure, and the small server farm they have. Although this seems
small-scale, the client handles sensitive-type subs.

I'm at a loss on how to do this. I know that I'll eat up at least a /25
and another /26 to renumber their existing clients into. My instincts
would have me reserve equivalents, but that almost doesn't seem possible
given the math.

Thinking that they will have to go back to ARIN for additional space
relatively quickly without intervention, can anyone provide links to
docs that will help prevent future renumbering or decent management? I
know that I can collapse a lot of their current waste, and I know where
I can scrounge, but where in the space should the clients be assigned
from, and where should I reserve my p2p/32 blocks from... front or back?

My current personal strategies don't apply, neither does the
documentation that I've found/read on the web in the past. This feels
like a nightmare ready to happen, and I need to ensure that with what
they have, a sane lo/ptp and client assignment strategy is configured.

They applied for too small a block. Numbering guidelines for tight v4
holdings will be very much appreciated.

Cheers,

Steve

ps. I advised an authority figure that they should apply for their v6
immediately now that they have their v4. I've also set up a meeting for
tomorrow morning to discuss how I can help them get experience with it ;)




More information about the NANOG mailing list