[ppml] POC verification process

[william at elan.net]

I meant 1.0.0.0/8 and 2.0.0.0/8 not /1 and /2. Sorry about mistype.

On Wed, 13 Aug 2003 william at elan.net wrote:

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