[ppml] POC verification process

Ian Baker ibaker at codecutters.org
Tue Aug 12 13:41:01 EDT 2003

----- Original Message ----- 
From: <Michael.Dillon at radianz.com>
To: <ppml at arin.net>
Sent: Tuesday, August 12, 2003 3:11 PM
Subject: Re: [ppml] POC verification process

> >I would suggest that your target customers would be best served by a
> >consortium-led directory made up of the main players in the industry, and
> >that - therefore - this isn't really a valid topic for discussion here.


> Now what I am proposing here is an RIR-like organization to serve the
> financial services industry. That is something which does not currently
> exist although there are precedents in the way SITA was given space for
> the air-traffic industry and the way that the North American cable
> industry
> was given a /8. Before one can reasonably discuss this with the companies
> which would form this type of new registry, one first needs to have some
> idea of how to go about getting an allocation of space. That is a matter
> of public policy so I am discussing it here. Also, I suspect that most
> organizations who would be part of the said consortium are also ARIN
> members
> so it does no harm to broach the subject in this forum.

Hmm? If there is only one address space (something I dispute), and backed-up
by your comments concerning Reuters, then I would be very interested to hear
the reasons as to why just one market sector (financial) should justify
special attention over all other people and organizations on the planet.

> By the way, no matter how hard we try, it is not possible any more to
> create
> a private IP network that is not connected to the Internet.

Show me a CAT-5 crossover cable and two NICs and I'll show you a
contradiction to that argument ;o)

Given that, I guess that I won't have to explain security in military
installations, and the internal "Chinese Walls" mandated by both law and
regulation in (ahen) UK financial institutions..?

> The Internet
> is
> defined as the collection of sites connected to the Internet. Nowadays,
> that
> includes just about every medium and large organization on the planet.
> It probably includes every single one of the companies which form the
> financial services industry.

.. and the others..

> A reasonable assumption is that every one of these companies also uses RFC
> 1918 addressing internally in their private networks and the larger ones
> probably have an internal registry managing their use of RFC 1918 space.

Remarkable reasonable, if untrue in a "couple" of instances that spring to
mind - I have yet to come across any centralised database of *all* IPs in
any organization that is not totally dedicated to such things (i.e. lies
outside the telecoms sector). In addition, you would have to scratch anyone
that uses DHCP, so out goes BT, NTL, etc.

In fact, I can't think of a /single/ organization that has a fully
comprehensive database as you describe. If we're willing to expand the
parameters slightly, then we have a directory that is anything but unique to
the financial sector. So why the proposed special treatment?

> In
> that context, the only feasable way of building a private internet and
> avoid
> all manner of wierd addressing corner cases, is to use globally unique
> registered addresses just like the public Internet. This need was foreseen
> by the authors of RFC2050 which is why this is considered a valid usage of
> IPv4 addresses.

Yes.. if I have the passage correctly, "the organization has no intention of
connecting to the Internet-either now or in the future", and that the
addresses should not be Internet routable. This is, in any event, something
that I would have thought to be the remit of the RFC 2050 Working Group,
rather than here?

Simple NAT would solve the other issue, as currently used globally by
millions. If it were an argument for the adoption of IPv6, then I'd accept
its validity.

> Please do not call this a private network; it is not. It is a private
> internetwork
> or private internet that interconnects a large number of networks which
> are
> also connected to the public Internet. If it helps, you can envision this
> as a thin layer around the edge of the public Internet where stub networks
> have a non-transit IPv4 connection to each other through this thin layer.

I fail to see the distinction. By this logic, if I were to dial-out using
the modem in my desktop machine, my /home/ network would also match this
definition! Why not avoid the semantics and just refer to all of this as " a
series of IP networks, forming one large IP network". Or, perhaps, "network"
for short.

> These stub networks are private networks belonging to companies like NYSE,
> Chicago Board of Trade, Merrill Lynch, Belzberg, Standard & Poor's, etc.
> Looking at the world from their point of view, they consider their
> privately
> owned corporate networks to be private networks and they consider
> RadianzNet
> (or SAVVIS Financial Xchange or SWIFTNet) to be a public network shared
> with
> their customers and competitors.

I very much doubt that broad-brush assertion (having dealt with one of those
network providers in the past as a partner/vendor; believe me, they were
even clearer in person than on their website).

Yes, those organizations have their own private networks, but, no, I do not
agree that they consider the various VPN vendors to constitute a public
network. Even if it /is/ firewalled and proxied to the hilt - I would hope
that most organizations would have learnt from that unfortunate episode in
Hong Kong.

Which, to my mind, makes your proposal seem very like the Internet as it
stands today - the only difference being that the Financial Services sector
gets to set the rules for all other private individuals and other industrial
sectors. Perhaps you could remind me - why exactly why would that be A Good
Thing for anyone outside of that minority?

Why we're at it, why not delegate the whole thing to AOL - after all, they
have a more representative spread of customers (I hasten to point out that
was a joke!)


Ian Baker
EMEA Support Manager
OpenConnect Systems Ltd.

More information about the ARIN-PPML mailing list