[ppml] POC verification process

[Ian Baker]

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....
>