[ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity
desterdick at verizon.com
desterdick at verizon.com
Thu Apr 8 13:48:22 EDT 2004
While on the topic of delayed responses -
Regarding the discussion of whether RFC-2050 is somewhat ambiguous or very
clear on use of registered IP addresses when connecting separate private
My concern is not with the fact that there is enough ambiguity to raise
this issue in the first place, but rather that during the RFC-2050 Working
Group discussion at ARIN-XII
there was a proposal for drafting an informational RFC to change the status
of RFC-2050 to historical. It was mentioned that if 2050 became a
historical document, the RIRs would have to reference internal documents
rather than RFC-2050.
I am not aware of the current momentum behind the proposal to deprecate
RFC-2050 to historical, but would not consider supporting the effort until
ARIN had a policy in place that included clear language on the use of
registered IP addresses when connecting separate private networks.
RFC-2050 may or may not be explicit enough, but before it "goes away" the
text regarding the requirement for globally unique IP addresses needs to be
included in an ARIN policy. IMHO, ARIN's existing IPv4 policy
documentation does not sufficiently address this requirement.
<einarb at arin.net> To: ppml at arin.net
Sent by: cc:
owner-ppml at arin.n Subject: RE: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network
I apologize for the delayed response.
In this thread on private nets Michael Dillon wrote:
>>I would like to see a comment from ARIN staff as to whether or not
>>they interpret the current rules this way.
Please allow me to point out the current policy text, and then explain
how requests for private nets are handled.
First, the policy text for "Non-connected Networks" can be found in
ARIN's IPv4 policy documentation (http://www.arin.net/policy/ipv4.html):
End-users not currently connected to an ISP and/or plan not to be
connected to the Internet are encouraged to use private IP numbers
reserved for non-connected networks (see RFC 1918).
Second, requests are handled as follows:
When someone requests nets for a private network the first thing we do
is refer them to the nets outlined in RFC 1918. In many cases this
turns out to be helpful because the one making the request was unaware
of the existence of private net space.
There are cases where a requesting entity is able to clearly state a
technical reason for not being able to use the addresses outlined in RFC
1918 and justify unique IPv4 address space even though they will not be
connecting to the Internet. These cases are rare.
There are also situations where the request is somewhere between the two
cases outlined above and the decision to approve or deny the request is
left to the judgment of the ARIN staff. These cases are tracked very
closely and documented for future reference to provide the highest level
of consistency possible.
Einar Bohlin - Policy Analyst, ARIN
einarb at arin.net +1 703 227-9867
> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of
> Michael.Dillon at radianz.com
> Sent: Thursday, April 01, 2004 8:52 AM
> To: ppml at arin.net
> Subject: RE: [ppml] Policy Proposal 2004-3: Global Addresses for
> Private N etwork Inter-Connectivity
> >I wish to reiterate this call for comments.
> I reiterate Bill's reiteration.
> > RFC-1918 and RFC-2050 are somewhat ambiguous concerning the use of
> > registered IP addresses when connecting separate private networks.
> In particular, I disagree with the basic premise of this
> proposed policy. I think that RFC-2050 is very clear:
> a) the organization has no intention of connecting to
> the Internet-either now or in the future-but it still
> requires a globally unique IP address. The organization
> should consider using reserved addresses from RFC1918.
> If it is determined this is not possible, they can be
> issued unique (if not Internet routable) IP addresses.
> It does not mandate following RFC 1918 and it does not
> require any specific reasons for determining that RFC 1918
> usage is not possible.
> Note that RFC 1918 has the following text in it:
> Category 3: hosts that need network layer access outside the
> enterprise (provided via IP connectivity); hosts in
> the last category require IP addresses that are
> globally unambiguous.
> It seems perfectly clear to me. When you interconnect two
> private RFC 1918 networks you should use globally unique
> IP addresses to do so. And this is sufficient justification
> for an allocation from a registry.
> I would like to see a comment from ARIN staff as to whether
> or not they interpret the current rules this way.
> Note that I work for a company which operates a global IP
> network in 20 countries using over half a million globally
> unique registered IP addresses. Our network is not connected
> to the network and we have no intention of ever connecting
> to the Internet. Our business model is based on interconnecting
> the private networks of businesses in the financial services
> industry so that they can provide services to one another.
> This means that we primarily interconnect networks that use
> RFC 1918 addressing internally.
> So the bottom line is that I understand current policy to say
> that any infrastructure which interconnects two or more
> networks, private or otherwise, should use globally unique
> IP addresses and that this infrastructure can justify their
> need for addresses in the normal way.
> Now I do agree that ARIN policies and ARIN forms are
> becoming dreadfully obsolete, filled with anachronisms
> and failing to meet the new realities of the IP
> internetworking world. I'm not at all surprised that
> people are confused by this and would like to clear
> up some corners of ambiguity. If this policy only included
> the first sentence then I would wholeheartedly support
> it. But right now, it seems to be based on misunderstanding
> and, possibly, on ARIN mistakes in applying the existing
> policy. I'd really like to get to the bottom of this.
> Michael Dillon
More information about the ARIN-PPML