[ppml] PUBLIC ADDRESSES FOR PRIVATE NETWORKS

[Owen DeLong]

I've seen multiple organizations use 172.16 as well as 192.168 and 10.
It's not uncommon to use them for different classes of private network
needs.  I know of at least one case where an organization used 10 net to
provide private addresses to their customers that needed to connect
to a particular service over a private secured channel.  They allocated
particular 10 space to each customer purchasing that service, and, it was
up to the customer to resolve any internal conflicts with it.

In my opinion, if he really wanted to, Michael could find a way to make
that work for his industry.  In any case, it certainly doesn't belong
on the POC verification thread, so I've changed the subject hoping that
others will follow suit.  (I'm interested in the POC verification thread).

Owen


--On Thursday, August 14, 2003 9:18 PM +0100 Ian Baker 
<ibaker at codecutters.org> wrote:

> William's idea seems to be very valid - although I still dispute that, in
> general, a (random) address in Organization A will need to connect to a
> (random) address in Organization B. Except in relatively contrived
> circumstances (contrived enough that I can't think of one, off of the top
> of my head!)
>
> Shame that pinching the 172 private block would kill
> backwards-compatibility - I've still only come across one solitary
> organization that used it over the 192.168 and 10 blocks..!
>
> To be honest, though, I'm still having difficulty in trying to see why the
> already-allocated public IP addresses couldn't be used in a network that
> is never intended to be publicly addressable (which I believe was the
> initial argument?) I'm making an assumption here (more below)
>
> I'm afraid that I don't really agree with Bill's argument about "masking"
> part of the public Internet - for this to be the case, we would have to
> assume nothing on the company boundary and no proxies - there is no reason
> (short of deliberate misconfiguration) for a LAN client to address any
> internal site with anything other than an internal address. I really can't
> see an organization wanting to transmit all internal requests to (e.g.)
> the company web site via an external ISP. Waste of bandwidth. (That
> assumption - that noone would deliberately configure an external address
> for an internal server)
>
> OTOH, if we were to adopt William's suggestion, then there would be no
> /possibility/ of conflict, and each organization could use NAT, as
> mentioned previously, for their interconnections. It might start to get
> interesting, though, when we come to backup and DR connections - wouldn't
> each organization in the register require a minimum of two addresses
> (maybe three, if the DR is a fully hot standby)?
>
> Ian
>
> ----- Original Message -----
> From: <william at elan.net>
> To: <ppml at arin.net>
> Sent: Thursday, August 14, 2003 12:45 AM
> Subject: Re: [ppml] POC verification process
>
>
>>
>> Overall this situation seems to indicate that we need additional ip
>> blocks to be reserved as non-routabled ip space (that everybody would
>> also knew about and would filter at the router level). I'd say /1 and /2
>> are good choices for it. The idea would be to specify that 10.x is to be
>> used for LAN while /1 or /2 is said to be used for WAN (meaning global
>> scale) private networks. In addition somebody can keep track of all
>> these private "WANs" and registries involved (like we already have WIANA
>> discussed
> before)
>> so that different industries not start to have duplicate private network
>> operators (or if they do so we at least knew who they are).
>>
>> On Wed, 13 Aug 2003, Bill Van Emburg wrote:
>>
>> > What each of you who is following an argument similar to Ian's appears
>> > to be missing is that it is a very real problem for enterprises that
>> > are interconnected to avoid conflicting IP space, even within RFC 1918
>> > addresses.  In any case, they certainly don't globally coordinate their
>> > use of the private IP space.
>> >
>> > It is also not possible to simply grab a slice of public IP space, even
>> > though the networks involved will not connect to the Internet.  This is
>> > because the enterprise would lose the ability to communicate with a
>> > piece of the Internet, since they would be routing that slice of
>> > addresses to a private network instead.
>> >
>> > At a previous venture, we used a slice of public IP space assigned to
>> > us for a network that would never see Internet-routed packets.  The
>> > reason for this was that we were interconnecting the private networks
>> > of multiple customers.  Each customer made use of the private IP
>> > space, and their various uses of it conflicted with each other.  All
>> > of them needed to get packets to our back end network.  The only way
>> > to ensure that a conflict of addressing could be avoided was to use
>> > addresses that would never be used on any customer's private network,
>> > and that would never need to be routed from our own internal network
>> > to the Internet.  The only way to do *that* is with a slice of public
>> > IP space that we *know* is never going to be used by anyone else --
>> > one that we had assigned to
> us.
>> >
>> > Do you understand the issue?  I happen to think that the idea presented
>> > here is an excellent one, as it handles one of the largest examples of
>> > such a case.  I would venture to guess that I was not the first one to
>> > think of doing as we did in my example above....
>>
>