Private use of non-RFC1918 IP space

>>
>> Some colleagues and I are running into a bit of a problem. We've been
>> using RFC 1918 Class A space but due to the way subnets have been
>> allocated we are pondering the use of public IP space. As the
>> network in
>> question is strictly closed I don't anticipate any problems with
>> this as
>> the addresses would be unambiguous within our environment. I'm
>> curious if
>> anyone else is doing this.
>
> I'd recommend against it, because even though the network is not
> connected to the Internet now you never know what the future holds.
> Even if it's never connected there are always things that seem to pop
> up and cause problems.
>
> Also, if you're address allocation policy has been so badly managed
> that you've run out of space in 10.0.0.0/8 adding more IPs to the pool
> isn't going to help for very long.

It will if you manage it better.

Fortunately, there's a /12 and a /24 still left.

And a /16. (What's the /24?) And possibly some other space that is
reserved-for-other-purposes.

A /12 is more space
than 99.99% of the networks on the Internet need, so why wouldn't that
suffice instead of using "real" space.

If you absolutely, positively *had* to allocate another /8, it'd probably
be best to look through Class A space for networks that are not likely to
ever appear on the Internet. ISTR a bunch of them are assigned to the US
military, for example.

... JG

Joe Greco wrote:

    

Some colleagues and I are running into a bit of a problem. We've been
using RFC 1918 Class A space but due to the way subnets have been
allocated we are pondering the use of public IP space. As the network in
question is strictly closed I don't anticipate any problems with this as
the addresses would be unambiguous within our environment. I'm curious if
anyone else is doing this.
        

I'd recommend against it, because even though the network is not
connected to the Internet now you never know what the future holds.
Even if it's never connected there are always things that seem to pop
up and cause problems.

Also, if you're address allocation policy has been so badly managed
that you've run out of space in 10.0.0.0/8 adding more IPs to the pool
isn't going to help for very long.
      

It will if you manage it better.

Fortunately, there's a /12 and a /24 still left.
    
And a /16. (What's the /24?) And possibly some other space that is
reserved-for-other-purposes.

A /12 is more space than 99.99% of the networks on the Internet need, so why wouldn't that suffice instead of using "real" space.
    
If you absolutely, positively *had* to allocate another /8, it'd probably
be best to look through Class A space for networks that are not likely to
ever appear on the Internet. ISTR a bunch of them are assigned to the US
military, for example.

... JG
  

For which the unauthorized use of could be construed as a military attack if those pirated addresses ever appear on the open Internet from this ISP... No that's also a really bad idea. I find it really troublesome to believe that the subnetting on a site was so complex that it ate an entire /8. What I am betting is that for some reason that ISP wants its addressing to be totally flat and not replicated.

Todd

TSG wrote:

I find it really troublesome to believe that the subnetting on a site was so complex that it ate an entire /8. What I am betting is that for some reason that ISP wants its addressing to be totally flat and not replicated.

The subnetting doesn't need to be "complex"; they may simply have a large number of small sites, or a moderate number of relatively large sites, that will eat up more than a /8's worth of addresses. There _do_ exist companies with 100,000+ locations and a few dozen devices per location; throw in the necessary aggregation so the routers don't fall over and you're looking at NATing multiple instances of 10/8 -- and I know from experience that's not fun.

However, the OP implies that his problem is caused by a poor subnetting scheme in 10/8; the correct solution in that case is to fix the subnetting -- but mgmt may not be willing to pay the labor (or other) costs of that.

S