From billd at cait.wustl.edu Thu Apr 1 08:24:58 2004 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 1 Apr 2004 07:24:58 -0600 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity Message-ID: <50C9C45A7E8DCE41A19F7A94715BABFD02A01E@kronos.cait.wustl.edu> I wish to reiterate this call for comments. I would be particularly interested in some statistics (or firm anecdotes) about the magnitude and trend of such need. Also, is there some background about what technologies are currently being employed to get around this problem and the pain that that might involve. Are maneuvers being employed to avoid notifying ARIN or an upstream of this intention when requesting blocks? Bill Darte ARIN AC > -----Original Message----- > From: Azinger, Marla [mailto:marla_azinger at eli.net] > Sent: Wednesday, March 31, 2004 2:10 PM > To: ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2004-3: Global Addresses > for Private > N etwork Inter-Connectivity > > > Hello- In preperation for the 1/2 hour slot provided at the > conference on > this proposal...does anyone have any comments and/or input to > this one? > > In order to make good use of the 1/2 hour this is slotted > for... we would > like to be fully prepared ahead of time for any angles that > this discussion > might take on. So your comments ahead of time either Pro or > Con are greatly > appreciated. > > Thank you for your time > Marla Azinger > > > -----Original Message----- > From: Member Services [mailto:memsvcs at arin.net] > Sent: Wednesday, March 17, 2004 11:43 AM > To: ppml at arin.net > Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private > Network Inter-Connectivity > > > ARIN welcomes feedback and discussion about the following policy > proposal in the weeks leading to the ARIN Public Policy Meeting > in Vancouver, Canada, scheduled for April 19-20, 2004. > > According to the ARIN Internet Resource Policy Evaluation Process > the Advisory Council will evaluate policy proposals after the Public > Policy Meeting. The feedback and discussion of policy proposals > on the Public Policy Mailing List will be included in the AC's > evaluation. > > Subscription information for the ARIN Public Policy Mailing List is > available at http://www.arin.net/mailing_lists/index.html > > The ARIN Internet Resource Policy Evaluation Process is available at: > http://www.arin.net/policy/ipep.html > > ARIN's Policy Proposal Archive is available at: > http://www.arin.net/policy/proposal_archive.html > > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal 2004-3: Global Addresses for Private Network Inter- > Connectivity > > Author: Marla Azinger and Bill Copeland > > Policy statement: Interfaces that connect private networks may be > assigned globally unique address space. Hosts within the > administrative > control of a single organization should still use private > address space > in accordance with RFC-1918 and RFC-2050. This policy is not intended > to override other policies with regard to justification, minimum size, > fees, or any other standard procedure. > > Rationale: > > RFC-1918 and RFC-2050 are somewhat ambiguous concerning the use of > registered IP addresses when connecting separate private networks. > Further, with the complexity of today's private interconnections, it > is not feasible to coordinate RFC-1918 private space among many > enterprises. Therefore, this proposal seeks to expressly allow the > use of registered space on the interfaces between private networks. > > Many private networking scenarios present the address assignment > problem that this proposal seeks to resolve. These include private > network interconnections, Virtual Private Networks (VPNs) using a > common layer 3 transport, and service provider RFC-2547 networks that > establish multiple VPNs. In the RFC-2547 case, the VPNs are isolated > via separate routing tables. However, the use of extranets, > partnerships, and other shared applications between VPNs complicate > the address assignment on the PE-CE links. > > RFC Considerations > Per RFC-2050: "In order for the Internet to scale using existing > technologies, use of regional registry services should be limited to > the assignment of IP addresses for organizations meeting one or more > of the following conditions: > > 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 RFC-1918. > If it is determined this is not possible, they can be > issued unique (if not Internet routable) IP addresses. > > b) the organization is multi-homed with no favored connection. > > c) the organization's actual requirement for IP space is > very large, for example, the network prefix required to > cover the request is of length /18 or shorter." > > Based on experience, ARIN has interpreted the RFC > consistently to mean > that organizations not connected to the global, public Internet do not > need globally unique IP address space. However, there is no specific > policy for the situation described in this proposal. > > In addition, RFC-1918 says: > "Hosts within enterprises that use IP can be partitioned > into three > categories: > > Category 1: hosts that do not require access to hosts in other > enterprises or the Internet at large; hosts within > this category may use IP addresses that are > unambiguous within an enterprise, but may be > ambiguous between enterprises. > > Category 2: hosts that need access to a limited set of outside > services (e.g., E-mail, FTP, netnews, remote login) > which can be handled by mediating gateways (e.g., > application layer gateways). For many hosts in this > category an unrestricted external access (provided > via IP connectivity) may be unnecessary and even > undesirable for privacy/security reasons. Just like > hosts within the first category, such hosts may use > IP addresses that are unambiguous within an > enterprise, but may be ambiguous between > enterprises. > > 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 is clear that routers need access to each other, and the layer 3 > VPN requires non-conflicting addresses between routers. To be > specific and conservative, non-conflicting addresses between PE-CE > links are required. So, while it is true that one VPN customer > organization's router (host) may not need to reach another > VPN customer > organization's router (host), the VPN provider needs to reach both > routers. In some cases, VPN customer organizations do need to > be able > to reach each other, as in the case of business partnerships or > extranets. > > It should be noted that the authors of RFC-1918 made some > consideration > of this scenario, and the RFC seems to suggest that the > private space > it reserves should not be used for interconnected > enterprises. However, > there is no ARIN policy to allow for allocation for these > enterprises. > > To recognize earlier work in this area, an Internet Draft was prepared > to resolve the policy vacuum, known as internet-draft-guichard-pe-ce, > by Jim Guichard et al. The draft proposed to use a large block, e.g., > /8, to be used by all service providers for private interconnection > purposes. The draft failed to reach consensus support. > > Finally, it should be noted that even if another addressing > scheme is > used, a router used to connect to a VPN may also be connected > to the Internet. Network Address Translation (NAT) cannot be used in > two instances on a single router in common practice. Any address > space outside of RFC-1918 must be considered routable. Therefore, > if the network local to the router uses RFC-1918 space and NAT is > used to translate addresses back to the Internet, it cannot use > another instance of NAT back to the VPN. > > Actual Network Case Study > > There are many different situations in which it seems public IP > addresses are needed to support a widely used private network. For > example, the E-911 networks facilitate confidential communication > among Police Stations, Fire Stations, Sheriff Stations, State Trooper > Stations and various other Emergency Response Programs. > > Background: Every city and state deploys E-911 services separately. > This has created multiple private networks within every County in the > United States. There is now an increasing effort to allow these > separate entities to communicate with each other. This may > be achieved > by putting these individual E-911 networks onto one larger connected > private network while at the same time leaving each individual network > with its own autonomy. Since every separate private network is > maintaining it's very own private network and utilizing the private > IP blocks within it's own network...there are no private IP's easily > identified for use in this connected private network. Also, due to > the delicate nature of this E-911 network it is imperative that no IP > range is utilized more than once. This leaves us with only > one option. > This option is to use public IP's on the E- 911 Connective Networks. > > Technical Translation: In some cases these are private networks, and > in other cases these are Virtual Private Networks (VPN) using a common > layer 3 transport. When these networks connect, there is the > possibility > that addresses assigned in good faith on one network may overlap > addresses assigned in good faith on the other. This will cause routing > instability and reachability problems. > > How this has been handled in the past? With or without the knowledge > of the upstream provider, public IP addresses are already being used > for these private networks. There is currently one specific company > working with ELI for creating several of these "E-911 connected" > private networks. This company has already obtained several different > blocks from multiple large ISPs. > > Why bring this proposal to the table now? Two reasons exist: > 1) to make the entire community aware of this situation, and, > 2) to provide a clearly documented solution that is supported by ARIN > and the Internet community. > > Meeting Considerations: > > Apr 2004 1st Day of Conference: Vote on yes or no to implement use of > Public IP's for Private use when requirements are met. The > initial vote > should solely be based on "should we allow this to happen for > company X if they fit the approved requirements list." > > Apr 2004 2nd Day of Conference: Vote on requirements and supporting > questions detailed below in *proposal step 2. The second day/session > will be used to vote in or out what will comprise the "approved > requirements and who does the assigning". > > > *Policy proposal step 2 > Several issues remain should this proposal pass. > > 1. Should a special block of IP addresses be set aside for this > application as suggested in the earlier work by Jim Guichard? > a. Pro: This approach will potentially consume fewer > addresses. > b. Con: Networks using IP addresses for this purpose > already exist and the operators will not want to renumber. A > grandfather clause would be needed to protect those that are > already using IP addresses in this manner. > > 2. Who should assign these IP's? Upstream and ARIN? > a. Upstream Pro: Sometimes this is appropriate if the > private network has an ISP that can accommodate the request. > b. Upstream Con: Some service providers are their own ISP > and need to resort to ARIN for additional address space. > c. ARIN Pro: This is the only choice for major service providers. > d. ARIN Con: This choice incurs more administrative overhead > for ARIN. > > 3. What are the qualifications for an operator to be allocated IP > addresses for this application? The following are acceptable > applications of this proposal. > a. Emergency Use (Police enforcement organizations, Fire > departments, 911 dispatch units) > b. Life support line (i.e. crisis hot lines and hospitals) > c. Layer 3 VPN service providers > d. RFC-2547 public service providers > e. Other private networks not under the same administrative > control that must interconnect. > > References: > > internet-draft-guichard-pe-ce-addr-03.txt. "Address Allocation for > PE-CE links within a Provider Provisioned VPN Network," Jim > Guichard, > et al. > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-guicha rd-pe-ce-addr- 03.txt RFC2050. "INTERNET REGISTRY IP ALLOCATION GUIDELINES," Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, Jon Postel. http://www.arin.net/library/rfc/rfc2050.txt RFC2547. "BGP/MPLS VPNs," Eric Rosen, Rakov Rekhter. http://www.ietf.org/rfc/rfc2547.txt RFC1918. "Address Allocation for Private Internets," Yakov Rekhter, Robert Moskowitz, Daniel Karrenberg, Geert Jan de Groot, Eliot Lear. http://www.arin.net/library/rfc/rfc1918.txt Timetable for implementation: This policy should be applied immediately, contingent upon final approval by the Board. From Michael.Dillon at radianz.com Thu Apr 1 08:52:15 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 1 Apr 2004 14:52:15 +0100 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity Message-ID: >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 From randy at psg.com Thu Apr 1 08:56:28 2004 From: randy at psg.com (Randy Bush) Date: Thu, 1 Apr 2004 05:56:28 -0800 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity References: Message-ID: <16492.8076.664870.653259@ran.psg.com> > 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 well, that "is not possible" is pretty strong. randy From Michael.Dillon at radianz.com Thu Apr 1 09:06:18 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 1 Apr 2004 15:06:18 +0100 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity Message-ID: >> 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 >well, that "is not possible" is pretty strong. Hmmm... well let's say I sat down with my boss to discuss the use of RFC 1918 addresses and he said to me, "It's not possible to use RFC 1918 addresses because we have promised our customers that we will use globally registered addresses". Seems to me that I have now determined that the use of RFC 1918 addresses is not possible and I am in full compliance with RFC 2050. Of course we would all hope that there was some technical basis for the impossibility criterion but the RFC doesn't go that far. However, the examples that are in the rationale for the proposed policy do contain good technical justification, for instance, connecting together a large number of existing private E911 networks over a large geographic area. Unique addresses are needed to maintain universal routability in such an interconnect infrastructure. --Michael Dillon From Dawn.Martin at mci.com Thu Apr 1 10:42:17 2004 From: Dawn.Martin at mci.com (Dawn Martin) Date: Thu, 01 Apr 2004 10:42:17 -0500 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity In-Reply-To: Message-ID: <013501c417ff$e9544590$c6df2799@mcilink.com> I would agree with Randy here that what "is possible" is not what is feasible. Your example is perfect, when multiple private networks are linked unique IP addresses need to be used. What I have heard from the ARIN meetings are that "is not possible" means not technically possible. i.e. if it is conceivable it is achievable. It is really just a clarification that is being sought to detail when globally unique IPs can be used to connect private networks. -Dawn Martin -----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 9:06 AM To: randy at psg.com Cc: ppml at arin.net Subject: RE: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity >> 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 >well, that "is not possible" is pretty strong. Hmmm... well let's say I sat down with my boss to discuss the use of RFC 1918 addresses and he said to me, "It's not possible to use RFC 1918 addresses because we have promised our customers that we will use globally registered addresses". Seems to me that I have now determined that the use of RFC 1918 addresses is not possible and I am in full compliance with RFC 2050. Of course we would all hope that there was some technical basis for the impossibility criterion but the RFC doesn't go that far. However, the examples that are in the rationale for the proposed policy do contain good technical justification, for instance, connecting together a large number of existing private E911 networks over a large geographic area. Unique addresses are needed to maintain universal routability in such an interconnect infrastructure. --Michael Dillon From adb at onramp.ca Thu Apr 1 11:08:57 2004 From: adb at onramp.ca (Anthony DeBoer) Date: Thu, 1 Apr 2004 11:08:57 -0500 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity In-Reply-To: ; from Michael.Dillon@radianz.com on Thu, Apr 01, 2004 at 03:06:18PM +0100 References: Message-ID: <20040401110857.Q22081@onramp.ca> Michael.Dillon at radianz.com wrote: > for instance, connecting together a large number of > existing private E911 networks over a large geographic > area. Unique addresses are needed to maintain universal > routability in such an interconnect infrastructure. I'd be concerned about putting the entire E911 infrastructure into one routable network, just for security reasons, and would countersuggest that perhaps each unit thereof should use 1918 addressing behind a firewall, which itself would be on a globally-uniquely-addressed E911 backbone. That would give some control of what accesses each unit is giving its peers and auditing of the use of such access, and call for a much smaller block. You don't want the PC they use to surf pr0n between calls at the firehall to catch a remote-access trojan and infect every other emergency-services Windows box in the nation. -- Anthony DeBoer Onramp Technical Support From marla_azinger at eli.net Thu Apr 1 12:38:57 2004 From: marla_azinger at eli.net (Azinger, Marla) Date: Thu, 1 Apr 2004 09:38:57 -0800 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity Message-ID: <10ECB7F03C568F48B9213EF9E7F790D207C9F2@wava00s2ke2k01.corp.pvt> Michael- You are very smart and interperate ARIN Policy very well. However, not everyone can make this interpretation as easily as you. Unfortunately I must confess...I was in the confused boat two years ago. Fortunately, I understand it now...but due to this being a re-occuring question at every ARIN conference we go to... it just seems it needs to be re-textualized in a very point blank manner. Thank you for responding! Marla -----Original Message----- From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] Sent: Thursday, April 01, 2004 5: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 From marla_azinger at eli.net Thu Apr 1 12:45:52 2004 From: marla_azinger at eli.net (Azinger, Marla) Date: Thu, 1 Apr 2004 09:45:52 -0800 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity Message-ID: <10ECB7F03C568F48B9213EF9E7F790D207C9F3@wava00s2ke2k01.corp.pvt> Dawn- your last sentence gets to the point of this very proposal. Because ARIN and many members of ARIN have used IP's this way and agree that it is needed, possible and not going against any current policy. It's just that...some (even myself back two years ago) found this a tad unclear. This policy is simply striving to achieve clarification. Marla -----Original Message----- From: Dawn Martin [mailto:Dawn.Martin at mci.com] Sent: Thursday, April 01, 2004 7:42 AM To: ppml at arin.net Subject: RE: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity I would agree with Randy here that what "is possible" is not what is feasible. Your example is perfect, when multiple private networks are linked unique IP addresses need to be used. What I have heard from the ARIN meetings are that "is not possible" means not technically possible. i.e. if it is conceivable it is achievable. It is really just a clarification that is being sought to detail when globally unique IPs can be used to connect private networks. -Dawn Martin -----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 9:06 AM To: randy at psg.com Cc: ppml at arin.net Subject: RE: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity >> 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 >well, that "is not possible" is pretty strong. Hmmm... well let's say I sat down with my boss to discuss the use of RFC 1918 addresses and he said to me, "It's not possible to use RFC 1918 addresses because we have promised our customers that we will use globally registered addresses". Seems to me that I have now determined that the use of RFC 1918 addresses is not possible and I am in full compliance with RFC 2050. Of course we would all hope that there was some technical basis for the impossibility criterion but the RFC doesn't go that far. However, the examples that are in the rationale for the proposed policy do contain good technical justification, for instance, connecting together a large number of existing private E911 networks over a large geographic area. Unique addresses are needed to maintain universal routability in such an interconnect infrastructure. --Michael Dillon From owen at delong.com Thu Apr 1 17:17:46 2004 From: owen at delong.com (Owen DeLong) Date: Thu, 01 Apr 2004 14:17:46 -0800 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity In-Reply-To: <16492.8076.664870.653259@ran.psg.com> References: <16492.8076.664870.653259@ran.psg.com> Message-ID: <2147483647.1080829066@dhcp156-138.corp.tellme.com> It also begs the question of "Who gets to determine it is not possible?" Owen --On Thursday, April 1, 2004 5:56 -0800 Randy Bush wrote: >> 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 > > well, that "is not possible" is pretty strong. > > randy > -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Thu Apr 1 17:19:05 2004 From: owen at delong.com (Owen DeLong) Date: Thu, 01 Apr 2004 14:19:05 -0800 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity In-Reply-To: References: Message-ID: <2147483647.1080829145@dhcp156-138.corp.tellme.com> Where in the RFC does it say you get to make that determination and not the registry staff? Either I missed it, or, you're applying assumptions to the interpretation of 2050 that I can't guarantee will hold up when the rubber hits the road. Owen --On Thursday, April 1, 2004 15:06 +0100 Michael.Dillon at radianz.com wrote: >>> 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 > >> well, that "is not possible" is pretty strong. > > Hmmm... well let's say I sat down with my boss to discuss > the use of RFC 1918 addresses and he said to me, "It's not > possible to use RFC 1918 addresses because we have promised > our customers that we will use globally registered addresses". > > Seems to me that I have now determined that the use of > RFC 1918 addresses is not possible and I am in full > compliance with RFC 2050. Of course we would all hope that > there was some technical basis for the impossibility criterion > but the RFC doesn't go that far. > > However, the examples that are in the rationale for the > proposed policy do contain good technical justification, > for instance, connecting together a large number of > existing private E911 networks over a large geographic > area. Unique addresses are needed to maintain universal > routability in such an interconnect infrastructure. > > --Michael Dillon > > > > -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From anne at apnic.net Mon Apr 5 02:11:48 2004 From: anne at apnic.net (Anne Lord) Date: Mon, 5 Apr 2004 16:11:48 +1000 (EST) Subject: [hm-staff] RE: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D207C9E7@wava00s2ke2k01.corp.pvt> Message-ID: hi Marla, Thought it might be useful to share with you the outcome of one of the proposals at APNIC's recent Open Policy Policy in KL, Malaysia in February. The policy proposal [prop-015-v001] 'Should APNIC allocate global unicast IPv6 address space to 'unconnected' networks?' was approved by consensus at the meeting. Full details of the proposal and all related documentation and presentations can be found at: http://www.apnic.net/docs/policy/proposals/prop-015-v001.html The proposal is now in the two month post meeting 'comment period', after which it will be presented to the Executive Council for endorsement. As background information to the proposal, the APNIC Executive council made a decision on behalf of the members to respond to the issue of IPv6 allocations to 'closed/private' networks which was raised on the globally co-ordinated IPv6 mailing list last year : http://www.apnic.net/mailing-lists/global-v6/archive/2003/10/msg00008.html The issue is fully explained in the 'interim statement' issued by the EC: http://www.apnic.net/docs/policy/ipv6-policy-clarification.html Best wishes, Anne _____________________________________________________________________ Anne Lord, Manager, Policy Liaison Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 ---------------------------------------------------------------------- On Wed, 31 Mar 2004, Azinger, Marla wrote: > Hello- In preperation for the 1/2 hour slot provided at the conference on > this proposal...does anyone have any comments and/or input to this one? > > In order to make good use of the 1/2 hour this is slotted for... we would > like to be fully prepared ahead of time for any angles that this discussion > might take on. So your comments ahead of time either Pro or Con are greatly > appreciated. > > Thank you for your time > Marla Azinger > > > -----Original Message----- > From: Member Services [mailto:memsvcs at arin.net] > Sent: Wednesday, March 17, 2004 11:43 AM > To: ppml at arin.net > Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private > Network Inter-Connectivity > > > ARIN welcomes feedback and discussion about the following policy > proposal in the weeks leading to the ARIN Public Policy Meeting > in Vancouver, Canada, scheduled for April 19-20, 2004. > > According to the ARIN Internet Resource Policy Evaluation Process > the Advisory Council will evaluate policy proposals after the Public > Policy Meeting. The feedback and discussion of policy proposals > on the Public Policy Mailing List will be included in the AC's > evaluation. > > Subscription information for the ARIN Public Policy Mailing List is > available at http://www.arin.net/mailing_lists/index.html > > The ARIN Internet Resource Policy Evaluation Process is available at: > http://www.arin.net/policy/ipep.html > > ARIN's Policy Proposal Archive is available at: > http://www.arin.net/policy/proposal_archive.html > > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal 2004-3: Global Addresses for Private Network Inter- > Connectivity > > Author: Marla Azinger and Bill Copeland > > Policy statement: Interfaces that connect private networks may be > assigned globally unique address space. Hosts within the administrative > control of a single organization should still use private address space > in accordance with RFC-1918 and RFC-2050. This policy is not intended > to override other policies with regard to justification, minimum size, > fees, or any other standard procedure. > > Rationale: > > RFC-1918 and RFC-2050 are somewhat ambiguous concerning the use of > registered IP addresses when connecting separate private networks. > Further, with the complexity of today's private interconnections, it > is not feasible to coordinate RFC-1918 private space among many > enterprises. Therefore, this proposal seeks to expressly allow the > use of registered space on the interfaces between private networks. > > Many private networking scenarios present the address assignment > problem that this proposal seeks to resolve. These include private > network interconnections, Virtual Private Networks (VPNs) using a > common layer 3 transport, and service provider RFC-2547 networks that > establish multiple VPNs. In the RFC-2547 case, the VPNs are isolated > via separate routing tables. However, the use of extranets, > partnerships, and other shared applications between VPNs complicate > the address assignment on the PE-CE links. > > RFC Considerations > Per RFC-2050: "In order for the Internet to scale using existing > technologies, use of regional registry services should be limited to > the assignment of IP addresses for organizations meeting one or more > of the following conditions: > > 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 RFC-1918. > If it is determined this is not possible, they can be > issued unique (if not Internet routable) IP addresses. > > b) the organization is multi-homed with no favored connection. > > c) the organization's actual requirement for IP space is > very large, for example, the network prefix required to > cover the request is of length /18 or shorter." > > Based on experience, ARIN has interpreted the RFC consistently to mean > that organizations not connected to the global, public Internet do not > need globally unique IP address space. However, there is no specific > policy for the situation described in this proposal. > > In addition, RFC-1918 says: > "Hosts within enterprises that use IP can be partitioned into three > categories: > > Category 1: hosts that do not require access to hosts in other > enterprises or the Internet at large; hosts within > this category may use IP addresses that are > unambiguous within an enterprise, but may be > ambiguous between enterprises. > > Category 2: hosts that need access to a limited set of outside > services (e.g., E-mail, FTP, netnews, remote login) > which can be handled by mediating gateways (e.g., > application layer gateways). For many hosts in this > category an unrestricted external access (provided > via IP connectivity) may be unnecessary and even > undesirable for privacy/security reasons. Just like > hosts within the first category, such hosts may use > IP addresses that are unambiguous within an > enterprise, but may be ambiguous between > enterprises. > > 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 is clear that routers need access to each other, and the layer 3 > VPN requires non-conflicting addresses between routers. To be > specific and conservative, non-conflicting addresses between PE-CE > links are required. So, while it is true that one VPN customer > organization's router (host) may not need to reach another VPN customer > organization's router (host), the VPN provider needs to reach both > routers. In some cases, VPN customer organizations do need to be able > to reach each other, as in the case of business partnerships or > extranets. > > It should be noted that the authors of RFC-1918 made some consideration > of this scenario, and the RFC seems to suggest that the private space > it reserves should not be used for interconnected enterprises. However, > there is no ARIN policy to allow for allocation for these enterprises. > > To recognize earlier work in this area, an Internet Draft was prepared > to resolve the policy vacuum, known as internet-draft-guichard-pe-ce, > by Jim Guichard et al. The draft proposed to use a large block, e.g., > /8, to be used by all service providers for private interconnection > purposes. The draft failed to reach consensus support. > > Finally, it should be noted that even if another addressing scheme is > used, a router used to connect to a VPN may also be connected > to the Internet. Network Address Translation (NAT) cannot be used in > two instances on a single router in common practice. Any address > space outside of RFC-1918 must be considered routable. Therefore, > if the network local to the router uses RFC-1918 space and NAT is > used to translate addresses back to the Internet, it cannot use > another instance of NAT back to the VPN. > > Actual Network Case Study > > There are many different situations in which it seems public IP > addresses are needed to support a widely used private network. For > example, the E-911 networks facilitate confidential communication > among Police Stations, Fire Stations, Sheriff Stations, State Trooper > Stations and various other Emergency Response Programs. > > Background: Every city and state deploys E-911 services separately. > This has created multiple private networks within every County in the > United States. There is now an increasing effort to allow these > separate entities to communicate with each other. This may be achieved > by putting these individual E-911 networks onto one larger connected > private network while at the same time leaving each individual network > with its own autonomy. Since every separate private network is > maintaining it's very own private network and utilizing the private > IP blocks within it's own network...there are no private IP's easily > identified for use in this connected private network. Also, due to > the delicate nature of this E-911 network it is imperative that no IP > range is utilized more than once. This leaves us with only one option. > This option is to use public IP's on the E- 911 Connective Networks. > > Technical Translation: In some cases these are private networks, and > in other cases these are Virtual Private Networks (VPN) using a common > layer 3 transport. When these networks connect, there is the possibility > that addresses assigned in good faith on one network may overlap > addresses assigned in good faith on the other. This will cause routing > instability and reachability problems. > > How this has been handled in the past? With or without the knowledge > of the upstream provider, public IP addresses are already being used > for these private networks. There is currently one specific company > working with ELI for creating several of these "E-911 connected" > private networks. This company has already obtained several different > blocks from multiple large ISPs. > > Why bring this proposal to the table now? Two reasons exist: > 1) to make the entire community aware of this situation, and, > 2) to provide a clearly documented solution that is supported by ARIN > and the Internet community. > > Meeting Considerations: > > Apr 2004 1st Day of Conference: Vote on yes or no to implement use of > Public IP's for Private use when requirements are met. The initial vote > should solely be based on "should we allow this to happen for > company X if they fit the approved requirements list." > > Apr 2004 2nd Day of Conference: Vote on requirements and supporting > questions detailed below in *proposal step 2. The second day/session > will be used to vote in or out what will comprise the "approved > requirements and who does the assigning". > > > *Policy proposal step 2 > Several issues remain should this proposal pass. > > 1. Should a special block of IP addresses be set aside for this > application as suggested in the earlier work by Jim Guichard? > a. Pro: This approach will potentially consume fewer > addresses. > b. Con: Networks using IP addresses for this purpose > already exist and the operators will not want to renumber. A > grandfather clause would be needed to protect those that are > already using IP addresses in this manner. > > 2. Who should assign these IP's? Upstream and ARIN? > a. Upstream Pro: Sometimes this is appropriate if the > private network has an ISP that can accommodate the request. > b. Upstream Con: Some service providers are their own ISP > and need to resort to ARIN for additional address space. > c. ARIN Pro: This is the only choice for major service providers. > d. ARIN Con: This choice incurs more administrative overhead > for ARIN. > > 3. What are the qualifications for an operator to be allocated IP > addresses for this application? The following are acceptable > applications of this proposal. > a. Emergency Use (Police enforcement organizations, Fire > departments, 911 dispatch units) > b. Life support line (i.e. crisis hot lines and hospitals) > c. Layer 3 VPN service providers > d. RFC-2547 public service providers > e. Other private networks not under the same administrative > control that must interconnect. > > References: > > internet-draft-guichard-pe-ce-addr-03.txt. "Address Allocation for > PE-CE links within a Provider Provisioned VPN Network," Jim Guichard, > et al. > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-guichard-pe-ce-addr- > 03.txt > > RFC2050. "INTERNET REGISTRY IP ALLOCATION GUIDELINES," > Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, Jon Postel. > http://www.arin.net/library/rfc/rfc2050.txt > > RFC2547. "BGP/MPLS VPNs," Eric Rosen, Rakov Rekhter. > http://www.ietf.org/rfc/rfc2547.txt > > RFC1918. "Address Allocation for Private Internets," Yakov Rekhter, > Robert Moskowitz, Daniel Karrenberg, Geert Jan de Groot, Eliot Lear. > http://www.arin.net/library/rfc/rfc1918.txt > > Timetable for implementation: This policy should be applied > immediately, contingent upon final approval by the Board. > _______________________________________________ > Hostmaster-staff mailing list > Hostmaster-staff at apnic.net > http://mailman.apnic.net/mailman/listinfo/hostmaster-staff > From William.Copeland at mci.com Mon Apr 5 09:56:52 2004 From: William.Copeland at mci.com (William Copeland) Date: Mon, 05 Apr 2004 08:56:52 -0500 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity In-Reply-To: <50C9C45A7E8DCE41A19F7A94715BABFD02A01E@kronos.cait.wustl.edu> Message-ID: <004901c41b15$d9ae2bb0$938c23a6@mcilink.com> To address the questions about the magnitude of private network numbering and the process used to number them thus far: The authors of the proposal have first-hand knowledge of 10's of thousands of PE-CE subnets that are numbered from globally unique address space. Given the growing popularity of private network interconnection, there are perhaps 100's of thousands if not millions of such address assignments today. Also, and again from the author's view point, these assignments were made with the full knowledge of and full disclosure to ARIN or its representatives within our respective corporations. The current rules of ARIN, though a bit vague on the subject, have been interpreted thus far to allow such assignments between private networks. Because the private network connections are quite complex and the networks involved are quite large, the private address spaces employed by the various agencies are often well populated. To avoid any conflicting addresses, private network have turned to ARIN for permission to assign registered space to the interconnecting networks only between such entities. This proposal seeks to codify in explicit language what has become operative practice. Regards -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Bill Darte Sent: Thursday, April 01, 2004 7:25 AM To: 'Azinger, Marla'; 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 would be particularly interested in some statistics (or firm anecdotes) about the magnitude and trend of such need. Also, is there some background about what technologies are currently being employed to get around this problem and the pain that that might involve. Are maneuvers being employed to avoid notifying ARIN or an upstream of this intention when requesting blocks? Bill Darte ARIN AC > -----Original Message----- > From: Azinger, Marla [mailto:marla_azinger at eli.net] > Sent: Wednesday, March 31, 2004 2:10 PM > To: ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2004-3: Global Addresses > for Private > N etwork Inter-Connectivity > > > Hello- In preperation for the 1/2 hour slot provided at the > conference on > this proposal...does anyone have any comments and/or input to > this one? > > In order to make good use of the 1/2 hour this is slotted > for... we would > like to be fully prepared ahead of time for any angles that > this discussion > might take on. So your comments ahead of time either Pro or > Con are greatly > appreciated. > > Thank you for your time > Marla Azinger > > > -----Original Message----- > From: Member Services [mailto:memsvcs at arin.net] > Sent: Wednesday, March 17, 2004 11:43 AM > To: ppml at arin.net > Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private > Network Inter-Connectivity > > > ARIN welcomes feedback and discussion about the following policy > proposal in the weeks leading to the ARIN Public Policy Meeting > in Vancouver, Canada, scheduled for April 19-20, 2004. > > According to the ARIN Internet Resource Policy Evaluation Process > the Advisory Council will evaluate policy proposals after the Public > Policy Meeting. The feedback and discussion of policy proposals > on the Public Policy Mailing List will be included in the AC's > evaluation. > > Subscription information for the ARIN Public Policy Mailing List is > available at http://www.arin.net/mailing_lists/index.html > > The ARIN Internet Resource Policy Evaluation Process is available at: > http://www.arin.net/policy/ipep.html > > ARIN's Policy Proposal Archive is available at: > http://www.arin.net/policy/proposal_archive.html > > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal 2004-3: Global Addresses for Private Network Inter- > Connectivity > > Author: Marla Azinger and Bill Copeland > > Policy statement: Interfaces that connect private networks may be > assigned globally unique address space. Hosts within the > administrative > control of a single organization should still use private > address space > in accordance with RFC-1918 and RFC-2050. This policy is not intended > to override other policies with regard to justification, minimum size, > fees, or any other standard procedure. > > Rationale: > > RFC-1918 and RFC-2050 are somewhat ambiguous concerning the use of > registered IP addresses when connecting separate private networks. > Further, with the complexity of today's private interconnections, it > is not feasible to coordinate RFC-1918 private space among many > enterprises. Therefore, this proposal seeks to expressly allow the > use of registered space on the interfaces between private networks. > > Many private networking scenarios present the address assignment > problem that this proposal seeks to resolve. These include private > network interconnections, Virtual Private Networks (VPNs) using a > common layer 3 transport, and service provider RFC-2547 networks that > establish multiple VPNs. In the RFC-2547 case, the VPNs are isolated > via separate routing tables. However, the use of extranets, > partnerships, and other shared applications between VPNs complicate > the address assignment on the PE-CE links. > > RFC Considerations > Per RFC-2050: "In order for the Internet to scale using existing > technologies, use of regional registry services should be limited to > the assignment of IP addresses for organizations meeting one or more > of the following conditions: > > 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 RFC-1918. > If it is determined this is not possible, they can be > issued unique (if not Internet routable) IP addresses. > > b) the organization is multi-homed with no favored connection. > > c) the organization's actual requirement for IP space is > very large, for example, the network prefix required to > cover the request is of length /18 or shorter." > > Based on experience, ARIN has interpreted the RFC > consistently to mean > that organizations not connected to the global, public Internet do not > need globally unique IP address space. However, there is no specific > policy for the situation described in this proposal. > > In addition, RFC-1918 says: > "Hosts within enterprises that use IP can be partitioned > into three > categories: > > Category 1: hosts that do not require access to hosts in other > enterprises or the Internet at large; hosts within > this category may use IP addresses that are > unambiguous within an enterprise, but may be > ambiguous between enterprises. > > Category 2: hosts that need access to a limited set of outside > services (e.g., E-mail, FTP, netnews, remote login) > which can be handled by mediating gateways (e.g., > application layer gateways). For many hosts in this > category an unrestricted external access (provided > via IP connectivity) may be unnecessary and even > undesirable for privacy/security reasons. Just like > hosts within the first category, such hosts may use > IP addresses that are unambiguous within an > enterprise, but may be ambiguous between > enterprises. > > 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 is clear that routers need access to each other, and the layer 3 > VPN requires non-conflicting addresses between routers. To be > specific and conservative, non-conflicting addresses between PE-CE > links are required. So, while it is true that one VPN customer > organization's router (host) may not need to reach another > VPN customer > organization's router (host), the VPN provider needs to reach both > routers. In some cases, VPN customer organizations do need to > be able > to reach each other, as in the case of business partnerships or > extranets. > > It should be noted that the authors of RFC-1918 made some > consideration > of this scenario, and the RFC seems to suggest that the > private space > it reserves should not be used for interconnected > enterprises. However, > there is no ARIN policy to allow for allocation for these > enterprises. > > To recognize earlier work in this area, an Internet Draft was prepared > to resolve the policy vacuum, known as internet-draft-guichard-pe-ce, > by Jim Guichard et al. The draft proposed to use a large block, e.g., > /8, to be used by all service providers for private interconnection > purposes. The draft failed to reach consensus support. > > Finally, it should be noted that even if another addressing > scheme is > used, a router used to connect to a VPN may also be connected > to the Internet. Network Address Translation (NAT) cannot be used in > two instances on a single router in common practice. Any address > space outside of RFC-1918 must be considered routable. Therefore, > if the network local to the router uses RFC-1918 space and NAT is > used to translate addresses back to the Internet, it cannot use > another instance of NAT back to the VPN. > > Actual Network Case Study > > There are many different situations in which it seems public IP > addresses are needed to support a widely used private network. For > example, the E-911 networks facilitate confidential communication > among Police Stations, Fire Stations, Sheriff Stations, State Trooper > Stations and various other Emergency Response Programs. > > Background: Every city and state deploys E-911 services separately. > This has created multiple private networks within every County in the > United States. There is now an increasing effort to allow these > separate entities to communicate with each other. This may > be achieved > by putting these individual E-911 networks onto one larger connected > private network while at the same time leaving each individual network > with its own autonomy. Since every separate private network is > maintaining it's very own private network and utilizing the private > IP blocks within it's own network...there are no private IP's easily > identified for use in this connected private network. Also, due to > the delicate nature of this E-911 network it is imperative that no IP > range is utilized more than once. This leaves us with only > one option. > This option is to use public IP's on the E- 911 Connective Networks. > > Technical Translation: In some cases these are private networks, and > in other cases these are Virtual Private Networks (VPN) using a common > layer 3 transport. When these networks connect, there is the > possibility > that addresses assigned in good faith on one network may overlap > addresses assigned in good faith on the other. This will cause routing > instability and reachability problems. > > How this has been handled in the past? With or without the knowledge > of the upstream provider, public IP addresses are already being used > for these private networks. There is currently one specific company > working with ELI for creating several of these "E-911 connected" > private networks. This company has already obtained several different > blocks from multiple large ISPs. > > Why bring this proposal to the table now? Two reasons exist: > 1) to make the entire community aware of this situation, and, > 2) to provide a clearly documented solution that is supported by ARIN > and the Internet community. > > Meeting Considerations: > > Apr 2004 1st Day of Conference: Vote on yes or no to implement use of > Public IP's for Private use when requirements are met. The > initial vote > should solely be based on "should we allow this to happen for > company X if they fit the approved requirements list." > > Apr 2004 2nd Day of Conference: Vote on requirements and supporting > questions detailed below in *proposal step 2. The second day/session > will be used to vote in or out what will comprise the "approved > requirements and who does the assigning". > > > *Policy proposal step 2 > Several issues remain should this proposal pass. > > 1. Should a special block of IP addresses be set aside for this > application as suggested in the earlier work by Jim Guichard? > a. Pro: This approach will potentially consume fewer > addresses. > b. Con: Networks using IP addresses for this purpose > already exist and the operators will not want to renumber. A > grandfather clause would be needed to protect those that are > already using IP addresses in this manner. > > 2. Who should assign these IP's? Upstream and ARIN? > a. Upstream Pro: Sometimes this is appropriate if the > private network has an ISP that can accommodate the request. > b. Upstream Con: Some service providers are their own ISP > and need to resort to ARIN for additional address space. > c. ARIN Pro: This is the only choice for major service providers. > d. ARIN Con: This choice incurs more administrative overhead > for ARIN. > > 3. What are the qualifications for an operator to be allocated IP > addresses for this application? The following are acceptable > applications of this proposal. > a. Emergency Use (Police enforcement organizations, Fire > departments, 911 dispatch units) > b. Life support line (i.e. crisis hot lines and hospitals) > c. Layer 3 VPN service providers > d. RFC-2547 public service providers > e. Other private networks not under the same administrative > control that must interconnect. > > References: > > internet-draft-guichard-pe-ce-addr-03.txt. "Address Allocation for > PE-CE links within a Provider Provisioned VPN Network," Jim > Guichard, > et al. > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-guicha rd-pe-ce-addr- 03.txt RFC2050. "INTERNET REGISTRY IP ALLOCATION GUIDELINES," Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, Jon Postel. http://www.arin.net/library/rfc/rfc2050.txt RFC2547. "BGP/MPLS VPNs," Eric Rosen, Rakov Rekhter. http://www.ietf.org/rfc/rfc2547.txt RFC1918. "Address Allocation for Private Internets," Yakov Rekhter, Robert Moskowitz, Daniel Karrenberg, Geert Jan de Groot, Eliot Lear. http://www.arin.net/library/rfc/rfc1918.txt Timetable for implementation: This policy should be applied immediately, contingent upon final approval by the Board. From randy at psg.com Mon Apr 5 16:09:27 2004 From: randy at psg.com (Randy Bush) Date: Mon, 5 Apr 2004 13:09:27 -0700 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity References: <50C9C45A7E8DCE41A19F7A94715BABFD02A01E@kronos.cait.wustl.edu> <004901c41b15$d9ae2bb0$938c23a6@mcilink.com> Message-ID: <16497.48375.974671.981181@roam.psg.com> > To address the questions about the magnitude of private network numbering > and the process used to number them thus far: > > The authors of the proposal have first-hand knowledge of 10's of thousands > of PE-CE subnets that are numbered from globally unique address space. > Given the growing popularity of private network interconnection, there are > perhaps 100's of thousands if not millions of such address assignments > today. Also, and again from the author's view point, these assignments were > made with the full knowledge of and full disclosure to ARIN or its > representatives within our respective corporations. The current rules of > ARIN, though a bit vague on the subject, have been interpreted thus far to > allow such assignments between private networks. > > Because the private network connections are quite complex and the networks > involved are quite large, the private address spaces employed by the various > agencies are often well populated. To avoid any conflicting addresses, > private network have turned to ARIN for permission to assign registered > space to the interconnecting networks only between such entities. This > proposal seeks to codify in explicit language what has become operative > practice. huh? i thought one of the big promises of 2547[bis] was that it handled vpns with the same overlapping private space. now you want the world to bear the cost? gimme a break. randy From William.Copeland at mci.com Tue Apr 6 14:41:53 2004 From: William.Copeland at mci.com (William Copeland) Date: Tue, 06 Apr 2004 13:41:53 -0500 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity In-Reply-To: <16497.48375.974671.981181@roam.psg.com> Message-ID: <007601c41c06$d4a8a4a0$938c23a6@mcilink.com> It is unfair to the topic to restrict the discussion to MPLS VPNs, though the issue is fully present there also. The problem is that multiple private interconnecting networks, regardless of the underlying technology, must interoperate. A working IP address scheme among business partners, extranet customers, and application service customers is not practically supportable in these situations without globally unique IP addresses. Administering RFC-1918 space across multiple administrative domains is not feasible on any commercial scale. -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Monday, April 05, 2004 3:09 PM To: William Copeland Cc: 'Bill Darte'; 'Azinger, Marla'; ppml at arin.net Subject: RE: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity > To address the questions about the magnitude of private network numbering > and the process used to number them thus far: > > The authors of the proposal have first-hand knowledge of 10's of thousands > of PE-CE subnets that are numbered from globally unique address space. > Given the growing popularity of private network interconnection, there are > perhaps 100's of thousands if not millions of such address assignments > today. Also, and again from the author's view point, these assignments were > made with the full knowledge of and full disclosure to ARIN or its > representatives within our respective corporations. The current rules of > ARIN, though a bit vague on the subject, have been interpreted thus far to > allow such assignments between private networks. > > Because the private network connections are quite complex and the networks > involved are quite large, the private address spaces employed by the various > agencies are often well populated. To avoid any conflicting addresses, > private network have turned to ARIN for permission to assign registered > space to the interconnecting networks only between such entities. This > proposal seeks to codify in explicit language what has become operative > practice. huh? i thought one of the big promises of 2547[bis] was that it handled vpns with the same overlapping private space. now you want the world to bear the cost? gimme a break. randy From randy at psg.com Tue Apr 6 14:59:32 2004 From: randy at psg.com (Randy Bush) Date: Tue, 6 Apr 2004 11:59:32 -0700 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity References: <16497.48375.974671.981181@roam.psg.com> <007601c41c06$d4a8a4a0$938c23a6@mcilink.com> Message-ID: <16498.65044.440262.838430@roam.psg.com> > It is unfair to the topic to restrict the discussion to MPLS > VPNs, then with what 10s of thousands of pe-ce subnets do you claim experience and relevance? > though the issue is fully present there also. The problem is > that multiple private interconnecting networks, regardless of the > underlying technology, must interoperate. A working IP address > scheme among business partners, extranet customers, and > application service customers is not practically supportable in > these situations without globally unique IP addresses. > Administering RFC-1918 space across multiple administrative > domains is not feasible on any commercial scale. > > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Monday, April 05, 2004 3:09 PM > To: William Copeland > Cc: 'Bill Darte'; 'Azinger, Marla'; ppml at arin.net > Subject: RE: [ppml] Policy Proposal 2004-3: Global Addresses for Private N > etwork Inter-Connectivity > > > To address the questions about the magnitude of private network numbering > > and the process used to number them thus far: > > > > The authors of the proposal have first-hand knowledge of 10's of thousands > > of PE-CE subnets that are numbered from globally unique address space. > > Given the growing popularity of private network interconnection, there are > > perhaps 100's of thousands if not millions of such address assignments > > today. Also, and again from the author's view point, these assignments > were > > made with the full knowledge of and full disclosure to ARIN or its > > representatives within our respective corporations. The current rules of > > ARIN, though a bit vague on the subject, have been interpreted thus far to > > allow such assignments between private networks. > > > > Because the private network connections are quite complex and the networks > > involved are quite large, the private address spaces employed by the > various > > agencies are often well populated. To avoid any conflicting addresses, > > private network have turned to ARIN for permission to assign registered > > space to the interconnecting networks only between such entities. This > > proposal seeks to codify in explicit language what has become operative > > practice. > > huh? i thought one of the big promises of 2547[bis] was that it > handled vpns with the same overlapping private space. now you > want the world to bear the cost? gimme a break. > > randy > From bicknell at ufp.org Wed Apr 7 22:56:11 2004 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 7 Apr 2004 22:56:11 -0400 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private N etwork Inter-Connectivity In-Reply-To: <16497.48375.974671.981181@roam.psg.com> References: <50C9C45A7E8DCE41A19F7A94715BABFD02A01E@kronos.cait.wustl.edu> <004901c41b15$d9ae2bb0$938c23a6@mcilink.com> <16497.48375.974671.981181@roam.psg.com> Message-ID: <20040408025611.GA78363@ussenterprise.ufp.org> In a message written on Mon, Apr 05, 2004 at 01:09:27PM -0700, Randy Bush wrote: > huh? i thought one of the big promises of 2547[bis] was that it > handled vpns with the same overlapping private space. now you > want the world to bear the cost? gimme a break. 2547[bis] happily handles 10's, or 100's of thousands of overlapping VPNs. However, that has nothing to do with the current discussion. The current problem is what happens when those 10's or 100's of thousands of /overlapping/ VPN's want to interconnect with each other. That's not a technology question. I'm not going to express a position on if it is prudent for all of those private IP VPN's to connect to each other or not, but allocating a /30 per interconnection is likely far more IP conservative than converting the whole VPN to public IP just because it wants to connect to 10 other VPN's. Did you bother to read the several hundred posts on the subject, or pay attention to the public policy discussion before posting? Your opinion is one of the most uninformed I have seen posted yet. It assumes a technology that is only tangentially related, and doesn't address any of the on-point issues. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From einarb at arin.net Thu Apr 8 12:24:15 2004 From: einarb at arin.net (Einar Bohlin) Date: Thu, 8 Apr 2004 12:24:15 -0400 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity In-Reply-To: Message-ID: 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): Non-connected Networks 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. Regards, 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 From desterdick at verizon.com Thu Apr 8 13:48:22 2004 From: desterdick at verizon.com (desterdick at verizon.com) Date: Thu, 8 Apr 2004 13:48:22 -0400 Subject: [ppml] Policy Proposal 2004-3: Global Addresses for Private Network Inter-Connectivity Message-ID: 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 networks: 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 (http://www.arin.net/library/minutes/ARIN_XII/ppm_minutes_day1.html#15) 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. Mark Desterdick "Einar Bohlin" 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 et Inter-Connectivity 04/08/2004 12:24 PM 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): Non-connected Networks 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. Regards, 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 From bicknell at ufp.org Mon Apr 12 13:13:33 2004 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 12 Apr 2004 13:13:33 -0400 Subject: [ppml] A comprehensive discussion of whois and public data. Message-ID: <20040412171333.GA5883@ussenterprise.ufp.org> $Author: bicknell $ - $Date: 2004/04/12 17:12:20 $ - $Revision: 1.6 $ I've been doing a lot of research into WHOIS and the various proposals that have been made. A history will be published in the next issue of the ARIN newsletter. Drawing on that history and all of the current debates I see a light at the end of the tunnel. It is my personal opinion that much of the challenge individuals and their proposals face is the lack of an overall plan. A proposed change may be good for one group, but without updating the other apects of policy it may have disasterous implications for other groups. Fortunately I don't see most of the proposals and desires as all that incompatable. While I'm sure my ideas will not make everyone happy, I think there might be a compromise position hidden in the details. To that end, this is a very long, but I hope comprehensive look at the situation. This is not a proposal, and is not in the proposal process at this point. Indeed, for many reasons I don't know how to make it a proposal right now. To make sense this document contains several proposals, and repeals several existing proposals, and that all must happen as a package or not at all to make sense. The current policy process is not friendly to these sort of multi-part proposals, indeed they are often shot down due to a minor flaw in a single part. Rather, for now I would like to see if the various parties do see this as a sort of acceptable middle ground. Please think on this before responding. I attempted to look at the problem individuals were trying to solve, not their proposed solution. While I may not have solved your problem your way, I hope that I have solved it in a way you can accept. Note, this is NOT a current proposal. It is NOT on the agenda for Vancouver. I post this now to get feedback, and so I can talk to people at Vancouver about these ideas. Enough intro, to the meat of the matter... There is a lack of consensus on the purpose of the "Whois" database. Indeed, it has lead a schizophrenic existence. Starting as the Internet White Pages, moving to the single point of all Domain/IP/ASN Info (at InterNIC) to today when "whois" properly is no more than a protocol to get at various databases, one of which is run by ARIN. Indeed, let's start with this most basic fact. It's not the "Whois" database. It's a database of ARIN public information that's available via the WHOIS protocol, also available via a web interface (http://ws.arin.net/cgi-bin/whois.pl), and in bulk form via FTP (http://www.arin.net/library/agreements/bulkwhois.pdf). This is a gross overloading of terms. I'll start with a new term: ARIN PUBLIC INFORMATION DATABASE The ARIN Public Information Database (APID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed public information and decided to publish. There is a corresponding database that also needs to be defined. ARIN collects other information in the course of business that do not get published. Examples include Network Maps from companies, their credit card information for billing, and internal contacts not listed in the public database. I'll give that a definition as well. ARIN CONFIDENTIAL INFORMATION DATABASE The ARIN Confidential Information Database (ACID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed is confidential information that should be kept under a strict privacy policy. {Note, a privacy policy needs to be defined for ACID, but I believe that is outside the scope of this particular document as it focuses on the public information.} Now that we have precise terms for the groups of data, a statement can be made about how that data should be published: ARIN shall publish the APID in the following methods using industry standard practices: - Via the WHOIS protocol. - Via a query form accessible via the HTTP protocol. - Via FTP to users who complete the bulk data form. - Via CDROM to users who complete the bulk data form. All data provided shall be subject to an AUP. The AUP shall be written by ARIN staff/legal and posted on the ARIN website. ARIN may require a signed copy of the AUP before providing bulk data. So far the definitions have been easy, now the harder parts. What goes in the public database, and what uses of that information are supported. I'll tackle the latter item first, as it impacts what goes in the database. Clearly the first use of this data is to support ARIN's business of allocating numbers. ARIN must collect data to implement the address allocation policies as outlined by the community. ARIN then creates data as various items are issued to the ARIN user base. The second use of data is nearly as important though, and that is one of community verification. The community uses the APID, and other sources, to verify that entities are using the resources they are supposed to be using. Since there is no "police force" this sort of community policing is absolutely required. Note that today in the case of RWHOIS the community may have to query a server run by someone other than ARIN to get some information. Community verification has two aspects to it. First, the community may want a third party to provide some verification that resources have been allocated. Second the community may want to verify that ARIN is doing its job properly. Unfortunately there is a problem with the second use. ARIN may use information in the ACID database (including but not limited to network maps, business plans, and customer network information) during the course of business. Since these items are not available in the APID it would be impossible for someone to audit ARIN's track record based on the APID alone. Due to the fact that it would be impossible to audit ARIN based on the APID data, and due to the fact that I know of no attempts to ever audit ARIN (or any other RIR based on that data) it would seem that item is of low importance. Indeed, were an audit to be necessary an outside party would most likely have to come in with NDA access to the ACID database for it to be properly performed. The third use of data is in statistics gathering. First order statistics (how much of resource X is in use, how fast is it being used) are necessary for the community to determine policies for distributing resources, and to determine when resource pools are exhausted and new solutions must be found. The second order statistics are generally used by third party research firms who perform some level of data mining on the APID to produce statics like the relative uses in different geographic areas, market segments, and other groupings that don't directly show up in the APID. The fourth use of data is as a contact database. For operational and abuse reasons it may be necessary to find a contact e-mail address, phone number, or mailing address for the person or entity who has been assigned space. The question that arises with contact information is what level of information is required, however that will be addressed with what information goes into the APID, not with the general categories of data. In addition to the supported uses, there are some uses that are expressly prohibited: Contact information from the APID should not be used to send unsolicited commercial e-mail, postal mail, or via any other method of delivery advertising a product or service should be prohibited. No information from the APID should be used to violate any state, federal, or local law. This leaves a potentially huge grey area of uses of the APID that are not on the supported or prohibited list. All of these uses should be allowed, but ARIN makes no assurances that the data in the APID will be fit for any of those purposes, or that the data in the APID may be changed at a later time in a way which may have adverse affects on these unsupported applications. Any users who have a new application they feel should be supported need to have that application approved by the membership to be added to the supported application list to ensure it will be considered with future proposals. Finally, to offer the above in proposal form: ARIN shall make the APID available for the following uses (supported uses): 1 ARIN's use in implementing ARIN policies and other business. 2 Community verification, allowing members of the community to confirm the proper users of the various resources ARIN controls. 3 Statistic gathering by ARIN and third parties on resource utilization. 4 As a contact database to facilitate communication with the person or entity responsible for a particular resource. ARIN prohibits the use of the APID for the following uses: 1 Sending any unsolicited commercial correspondence advertising a product or service to any address (physical or electronic) listed in the APID. 2 Using data in the APID to facilitate violating any state, federal, or local law. ARIN shall allow all non-prohibited uses of the APID, however unless those uses are listed as a supported use the data set may be changed in such a way as to render them ineffective, or they may be blocked outright as deemed necessary by ARIN staff. Users of applications not listed who are concerned that they are supported should introduce a proposal to add their application to the supported list. Now, last but not least, since we know what are the supported uses of the APID we can look at what information is required to be in the APID to support each point. Clearly the data set that needs to be supported in total is the union of all of the individual data sets. Supported use #1 - No data needs to be listed in the APID to support ARIN's implementation of policies. All data could be listed in the ACID for these purposes. Supported use #2 - For community verification all resources managed by ARIN need to be listed, along with contact information. A mechanism should be supplied to allow the delegation by resource holders for subsets of the resource where desired by the holder. For the purposes of verification delegation of subsets is completely optional. Supported use #3 - Statistics are one of the biggest problems. First order statistics are generally published by ARIN outside of the APID or ACID, and there is little need for that data to be replicated by outside parties. Of more interest in second order data. In order to get the most useful second order statistics the groups gathering that data would like the largest amount of information present in the database. Aside from the ARIN membership using some of the statistics presented from third parties, there has been no consensus to date on ARIN funding or making available specific data for those uses. As a result, while statistics should be a supported use, they should not that this time influence what is, or is not in the APID. ARIN may want to develop a program such that under NDA and other controls approved organizations can access portions of the ACID database in order to get additional data. Supported use #4 - For use as a contact database, all resources managed by ARIN need to be listed, along with contact information. In addition, policies and procedures need to be in place to keep that contact information up to date. Realizing that contact information is a management burden, ARIN should support the minimum set of data that allows for generally accepted methods of communication. To that end, ARIN shall list e-mail, phone, and postal contacts for all direct resource delegations, and have a procedure to periodically verify that information. The contact must verify that they are responsible for the resource in question, and that the contacts listed are the correct ones for dealing with any issues resulting from the use of that resource. A mechanism should be supplied to allow for the delegation of a subset of a resource along with contact information. Delegated contact information shall be verified using the same procedure as direct delegations. These subdelegation should be marked as able to be further sub-delegated or not. A sticky point in e-mail, but much more so in some of the public policy meetings is that there is not agreement on the valid uses for APID data. One one end, some want APID to revert back to it's earlier behavior of being a sort of white pages for the Internet. The opposite view is that only the highest level of information should be in the database, and that any further information should be sought from the organization listed in the database. The first thing to do is look for precedent. While the initial database was all encompassing, as early as 1994 that started to change in policy (and possibly a bit earlier in practice). An interesting case study here is the similar-but-different case of DNS names. If "harvard.edu" delegates "cs.harvard.edu" to the CS Department for use there is no requirement DNS Registrars be notified. There is no protocol requirement to put contact information (or anything besides basic nameserver IP's) in the protocol. There is the ability in the protocol (via RP records, and TXT records) to list that information. However, if that information is not listed and you want to know something about "cs.harvard.edu" you must back up one level in the tree to "harvard.edu", contact them and hope they will pass you along to the right people. Perhaps more interesting from a practical point of view is that a smaller amount of valid contact information is generally much more useful than a larger set of invalid data. In addition, there is a cost to maintaining valid data, in that ARIN must expend resources keeping the data set up to date. All of these point to a minimal, but highly verified and accurate data set as being the cheapest solution that also provides the highest probability of getting a valid contact. As a last point on this subject, there are cases where the entity that has been given use of a resource, and the person who should be listed as a contact for a resource are different. For instance, managed services companies often allocate resources for their customers, but are tasked with answering all external queries about those resources, and either answering them directly for their client or forwarding them to their client as appropriate. The system adopted should support these situations, has having the proper contact in these cases is far more likely to lead to useful information than having the actual user of the space listed. Finally, this leads to the policy of what should be in the APID: ARIN shall publish verified contact information and the resource(s) allocated (including identification for that allocation, like date of allocation or other information identified by ARIN) in the APID in the following cases: - All resources delegated by ARIN. - If allowed by the parent delegation, and requested by the contact listed with the parent, a subdelegation of a resource originally delegated by ARIN. ARIN shall insure all contact information in the APID is verified from time to time and is correct to the best of ARIN's ability. To comment on the implementation. I suspect SWIP as it exists today would remain, simply having a two flags added to the template. "Make public", and "allow downstream to SWIP". Both would default to no, making all information appear only in the ACID. Sites using rwhois could choose to restrict access to their rwhois server to ARIN staff netblocks only if they do not whish to make their information public. Last but not least, some teeth are needed. Without them companies could simply not comply with the policies. As such a mechanism is needed to punish those who do not comply. There are two ways ARIN may find non-compliance. First, ARIN may be unable to verify contact information during the verification process. In this case the resource should be put in a suspended state, and the parent for that record should be contacted. In the event there is no response for repeated attempts after the resource has been suspended the resource shall be revoked. The second method is that ARIN may be notified that someone is unable to contact an entity. The entity reporting the problem must show proof of attempting to make contact via two different methods. ARIN should then follow the standard contact verification procedure to verify the contact, and if verified seek explanation as to why there was no response. ARIN may set a threshold after which repeated reports by third parties will result in suspension, even if verification succeeds. ARIN may also set a threshold after which it can ignore notices from those sending incomplete reports, or reporting organizations which can document responses. The proposal: If ARIN is unable to verify contact information via the normal verification procedure ARIN shall attempt to notify the parent of the resource to have the information updated. If there is no parent, or if the data is not corrected in a reasonable amount of time the resource shall be SUSPENDED. Once the resource is suspended ARIN shall make one more request of all contacts listed with the resource and the parent resource (if available), and if no response is received in a reasonable amount of time the resource shall be reclaimed. Third parties may report the inability to make contact with a party via information in the APID. In this case ARIN shall attempt the contact verification procedure for that contact immediately. If a response is received, ARIN should document that a problem occured, and the responce from the resource holder. Offenders who fail to repond to third parties more than 4 times per month for three months may have their resources reclaimed at the discression of ARIN staff. If a third party submits reports of the inability to make contact that are subsequently disproven, ARIN may choose to ignore reports from specific companies, people, e-mail addresses, or any other classification means as appropriate. The ARIN staff shall publish the time thresholds and procedural details to implement this policy on the ARIN web site. If a resource is reclaimed under no circumstances shall the holder of that resource be entitled to a refund of any fees. The proposals listed above overlap with some other proposals already passed and in the process. They are enumerated below, along with the reasons they should be abandoned or repealed. * 2002-3 - Residential Customer Privacy. This policy should be repealed, as under my proposal there is no requirement to list residental customers at all. These policies do not conflict, but do not make much sense together. * 2002-4 - Bulk Copies of ARIN's whois This policy should be repealed, as under my proposal there is a definition of when an AUP is needed. These two policies potentially conflict. * 2002-8 - Privatizing POC Information This policy should be repeaed. Under my proposal a company may make available contacts that are only listed in the ACID. My proposal is also flexable in that ARIN staff can allow many more contacts than are on the existing template into the ACID as necessary without them appering in the APID. Indeed, I expect ARIN staff to encourage users (via new forms and methods) to list role accounts in the APID, while providing individuals for the ACID, which should make some interactions much easier for the ARIN staff. * 2003-9 - Whois Acceptable Use Policy (AUP) This policy should be abandoned. My proposal requires an AUP as this proposal does, but leaves it up to ARIN staff and legal to both write the policy and keep it up to date. ARIN staff may want to use this proposal as a template. * 2003-16 POC Verification This policy should be abandoned. My proposal includes POC verification, and allows ARIN staff to define the procedure and publish it on the ARIN web site. ARIN staff may want to use this proposal as a template. * 2003-5 Distributed Information Server Use Requirements This policy should be MODIFIED. This proposal covers many items, most of which are covered in my proposal, however there is one important item which is not. This policy requires rwhois servers to be available 24x7 to the public. This is an important proposal, and should continue on that point alone. If an entity is going to publish information via rwhois they must take commercially reasonable actions to make it available 24x7. Adding that requirement to my proposals would put it in the wrong place. * 2003-11 Purpose and Scope of WHOIS Directory Already abandoned. * 2001-7 Bulk ARIN Whois Data Already obsolete. Last, but by no means least a look at the impact of these changes. First, it is expected there will be no substantial differences in the information collected by ARIN. ARIN will still need the same basic data, and will probably require the same level of detail in the form of SWIP or RWHOIS. The major change is that most of that data will now reside in the ACID, and not the APID. Generally this should allow ARIN more freedom in the internal representation of this data, and should also allow for enhanced privacy. This privacy comes in two forms, individuals and corporations do not have to have their information published directly as long as they make arrangements with someone higher in the heirachy to be responsible for external queries, and it also allows businesses to keep more of their network data private protecting business plans and such. At the same time privacy increases it also increases the ability to use this data for various purposes. Since contact information is verified, and must take responsibility for the space under policy there is a much higher likelihood that the contact information will lead to someone who can help, or who can respond to escalation (eg, legal proceedings). No longer will contact information be listed for people who have no intention of responding, nor will it become stale. Further, if an abuse of the system is detected ARIN will have the ability by policy to terminate that user. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From william at elan.net Mon Apr 12 18:38:11 2004 From: william at elan.net (william(at)elan.net) Date: Mon, 12 Apr 2004 15:38:11 -0700 (PDT) Subject: [ppml] A comprehensive discussion of whois and public data. In-Reply-To: <20040412171333.GA5883@ussenterprise.ufp.org> Message-ID: There are a lot of good points that you make here but a number of things I dont agree with either. More comments are inline but briefly: 1. I don't agree that reassignment information should not be listed at all. Taking from your example we do have record of subdomain.domain.com, with name of the subdomain, list of deligated nameservers that support it, etc. Additionally I have not seen any evidence that audit of arin efficiency is not possible or has not been done based on available records. If anything the opposite is true and its been done either on the specific cases or overall as kind-of statistical thing but making such audits just completed impossible is a bad thing. 2. Your document/post is not very direct on the aspects about private and piblic information. These are very complex issues as can be seen from many laws regarding this on both state and federal levels where some laws specify rights of people to obtain the information and others rights to privacy to medical records and such. 3. I generally agree that lots of existing arin policies need to be rewritten including ones dealing with reassignment data and whois. I publicly and privately said as much (last time no more then month ago to another member of AC) and that will basicly absolute some of the existing proposals. That is however a very big task that may take years time and until it is done we're better off discussing existing proposals as they can close certain holes in existing system and improve it. And generally this is hardly the only part of ARIN policy that needs to be partially reworked. 4. In my opionion the rewrite should not be done as way to "REPEAL" aspects of certain policies in making way for compromise. Instead it should be done to simply create better organized clearer text and definitions and should be be based primarily (or even completely) on the policies already passed so as to absolute them with better version text but not to replace the with something entirely different in the meaning. On Mon, 12 Apr 2004, Leo Bicknell wrote: > $Author: bicknell $ - $Date: 2004/04/12 17:12:20 $ - $Revision: 1.6 $ > > I've been doing a lot of research into WHOIS and the various proposals > that have been made. A history will be published in the next issue > of the ARIN newsletter. Drawing on that history and all of the > current debates I see a light at the end of the tunnel. It is my > personal opinion that much of the challenge individuals and their > proposals face is the lack of an overall plan. A proposed change > may be good for one group, but without updating the other apects > of policy it may have disasterous implications for other groups. Lets not overplay this. On too many occasions negotiators try to create an acceptable compromise agreement by having one side sacrifice something to get something else, the problem is that while it maybe enough to pass the agreement needed at that point, it actually leaves hidden rifts which grow wider in the future and eventually may spell complete disaster (majority of wars have been fought because of these rifts grown from previous compromise agreements). > Fortunately I don't see most of the proposals and desires as all > that incompatable. While I'm sure my ideas will not make everyone > happy, I think there might be a compromise position hidden in the > details. Continuing on my case above, I'd like to point out that situation is such that if you try to introduce points in this "compromise" that every party does not like, the proposal will fail miserably. Unlike cases with some political situations where compromise agreement is a MUST for future for both sides, we do not have such with ARIN as we already have a policy and process to amend it and if we are to do complete rewrite it is not to be a compromise but either a clarification of existing policy or something much much better. It would be worth decision to try to introduce something that would be unpopular (or require sacrificies) from all sides when existing policy system does not have this problem. > To that end, this is a very long, but I hope comprehensive look at > the situation. This is not a proposal, and is not in the proposal > process at this point. Indeed, for many reasons I don't know how > to make it a proposal right now. To make sense this document > contains several proposals, and repeals several existing proposals, > and that all must happen as a package or not at all to make sense. > The current policy process is not friendly to these sort of multi-part > proposals, indeed they are often shot down due to a minor flaw in > a single part. Hrm... This is actually more of an issue with how ARIN process works in general. But I really see nothing in there to defy that possibly larger proposals will be shutdown even faster then smaller ones. If anything, one flow on one side of it may well shutdown it down as well. In fact, I think we have seen this exact thing with last IPv6 proposal. > Rather, for now I would like to see if the various > parties do see this as a sort of acceptable middle ground. Please > think on this before responding. I attempted to look at the problem > individuals were trying to solve, not their proposed solution. > While I may not have solved your problem your way, I hope that I > have solved it in a way you can accept. > > Note, this is NOT a current proposal. It is NOT on the agenda for > Vancouver. I post this now to get feedback, and so I can talk to > people at Vancouver about these ideas. If you want to have a BoF about it, this can be done and I'll actively participate as I think will many others (this can be either done as part or right after ARIN's proposal's BOF or at separate time after the main sessions of the meeting). And in the future we can continue discussion on this list. Note that I'd be against having AC continue discussions of this on its own - I view role AC as more of editor when community calls for it but not as an author - this process of authoring the proposals should be an open one done on this list (preferably) with members of AC participating just like everybody else. > Enough intro, to the meat of the matter... > > There is a lack of consensus on the purpose of the "Whois" database. > Indeed, it has lead a schizophrenic existence. Starting as the > Internet White Pages, moving to the single point of all Domain/IP/ASN > Info (at InterNIC) to today when "whois" properly is no more than > a protocol to get at various databases, one of which is run by ARIN. > > Indeed, let's start with this most basic fact. It's not the "Whois" > database. It's a database of ARIN public information that's available > via the WHOIS protocol, also available via a web interface > (http://ws.arin.net/cgi-bin/whois.pl), and in bulk form via FTP > (http://www.arin.net/library/agreements/bulkwhois.pdf). This is a gross > overloading of terms. I'll start with a new term: > > ARIN PUBLIC INFORMATION DATABASE > > The ARIN Public Information Database (APID) is a collection > of information created and collected by ARIN during the due > course of business which the ARIN membership has deemed public > information and decided to publish. So far so good. Of course, the problem is that above avoids the main issue - we as a membership still need to decide what is andshould be public information include what should be required to be public information. > There is a corresponding database that also needs to be defined. ARIN > collects other information in the course of business that do not get > published. Examples include Network Maps from companies Hey, I personally want to see it all get published! Why should I be looking at the Darth Vader's image instead of a network map :) > their credit > card information for billing, and internal contacts not listed in the > public database. I'll give that a definition as well. > > ARIN CONFIDENTIAL INFORMATION DATABASE > > The ARIN Confidential Information Database (ACID) is a collection > of information created and collected by ARIN during the due course > of business which the ARIN membership has deemed is confidential > information that should be kept under a strict privacy policy. Again as general statement definition this works fine. Same problem with having to decide about what exactly falls under this definition. > {Note, a privacy policy needs to be defined for ACID, but I believe that > is outside the scope of this particular document as it focuses on the > public information.} This I disagree with. We can not and should not proceed with redefinition of whois/data information unless we're willing at the same time to work on the private/public issues of that information. That is not to say that I completely disagree with you - as I recently wrote to somebody else at AC, we need to clear current confusion with policies and clearly separate and define what data is private and what should be public. But these are just better grouping issues as part of the overall system. > Now that we have precise terms for the groups of data, a statement > can be made about how that data should be published: > > ARIN shall publish the APID in the following methods using > industry standard practices: > > - Via the WHOIS protocol. > - Via a query form accessible via the HTTP protocol. > - Via FTP to users who complete the bulk data form. > - Via CDROM to users who complete the bulk data form. > > All data provided shall be subject to an AUP. The AUP shall > be written by ARIN staff/legal and posted on the ARIN website. > ARIN may require a signed copy of the AUP before providing > bulk data. Ok here we have text from my Whois AUP proposal. Obviously I agree :) And in reality like your defitions this is not as much for an "compromise" point. I've not seen anybody that disagreed with above in any serious way. > So far the definitions have been easy, now the harder parts. What > goes in the public database, and what uses of that information are > supported. I'll tackle the latter item first, as it impacts what > goes in the database. > > Clearly the first use of this data is to support ARIN's business > of allocating numbers. ARIN must collect data to implement the > address allocation policies as outlined by the community. ARIN > then creates data as various items are issued to the ARIN user base. Yes, clearly the data that is being gathered is specific to the resources under ARIN's managements - i.e. ip blocks, ASNs and how they are supposed to be used and by who. > The second use of data is nearly as important though, and that is > one of community verification. The community uses the APID, and > other sources, to verify that entities are using the resources they > are supposed to be using. Since there is no "police force" this > sort of community policing is absolutely required. Note that today > in the case of RWHOIS the community may have to query a server run > by someone other than ARIN to get some information. In my view nothing wrong with that as long as that entity is acting responsibly and providing access as ARIN would have done. In reality it does not matter if organization submitted a swip and data is now served by ARIN or if organization serves data directly. Its still same data and same rules should apply. > Community verification has two aspects to it. First, the community > may want a third party to provide some verification that resources > have been allocated. Second the community may want to verify that > ARIN is doing its job properly. Unfortunately there is a problem > with the second use. ARIN may use information in the ACID database > (including but not limited to network maps, business plans, and > customer network information) during the course of business. Since > these items are not available in the APID it would be impossible > for someone to audit ARIN's track record based on the APID alone. Disagree. Its quite possible to audit based on public information - we're not talking about exact audit of each and every detail - this takes tremendous resources and human but appoximation of arin activity and audit based on statistics with overal numbers being in favor of ARIN or against it are quite possible if all the allocations are in the database. > Due to the fact that it would be impossible to audit ARIN based on > the APID data, and due to the fact that I know of no attempts to ever > audit ARIN (or any other RIR based on that data) it would seem that > item is of low importance. See above on why this is not true. As a partial example I've done research on efficiency of RIR allocations with data published at http://www.completewhois.com/statistics/rir_ratios.htm This would not have been possible if it were not for available of data in ARIN database. At the end of January I also wrote script that examined ARIN database in bulk including swips and tried to follow what percentage of space has been swiped in which /8 blocks. I intend to come back to this in the future when some additional necessary tools are ready and when I can run this continuesly for certain period of time and see how it changes for new blocks or blocks that are extended as opposed to old blocks as well as compare this to similar "PA - provider assigned" data from RIPE and APNIC databases. You can view this work as partial audit even if its been done as more of a research kind of way. But the point is its quite possibly to do audits with public data - there is no necessity to have 100% of every detail just overall picture is enough. > Indeed, were an audit to be necessary > an outside party would most likely have to come in with NDA access > to the ACID database for it to be properly performed. An outside agency full audit would only be necessary if we have enough data that something is wrong. More then likely such doubts may happen as a result of some partial audit done based on public information that reveals problems. > The third use of data is in statistics gathering. First order > statistics (how much of resource X is in use, how fast is it being > used) are necessary for the community to determine policies for > distributing resources, and to determine when resource pools are > exhausted and new solutions must be found. The second order > statistics are generally used by third party research firms who > perform some level of data mining on the APID to produce statics > like the relative uses in different geographic areas, market segments, > and other groupings that don't directly show up in the APID. > > The fourth use of data is as a contact database. For operational > and abuse reasons it may be necessary to find a contact e-mail > address, phone number, or mailing address for the person or entity > who has been assigned space. The question that arises with contact > information is what level of information is required, however that > will be addressed with what information goes into the APID, not > with the general categories of data. Of all use of ARIN data - this is the MOST IMPORTANT ONE. > In addition to the supported uses, there are some uses that are > expressly prohibited: > > Contact information from the APID should not be used to send > unsolicited commercial e-mail, postal mail, or via any other method > of delivery advertising a product or service should be prohibited. Agree. > No information from the APID should be used to violate any state, > federal, or local law. Lets be carefull about "any". There are so many laws... In my view the overall data should not violate laws as they are defined in the county where ARIN is registered. And any specific data should in addition to that not violate any possibly stronger local laws in the community where the person or organization who/that submitted data to ARIN operates. > This leaves a potentially huge grey area of uses of the APID that > are not on the supported or prohibited list. All of these uses > should be allowed, but ARIN makes no assurances that the data > in the APID will be fit for any of those purposes, or that the > data in the APID may be changed at a later time in a way which > may have adverse affects on these unsupported applications. Any > users who have a new application they feel should be supported > need to have that application approved by the membership to be > added to the supported application list to ensure it will be > considered with future proposals. I'll reserve my option on this point, though I think ARIN should not have to review every new application for its data - if something is wrong it will be brought to its attention. > Finally, to offer the above in proposal form: > > ARIN shall make the APID available for the following uses > (supported uses): > > 1 ARIN's use in implementing ARIN policies and other > business. > 2 Community verification, allowing members of the community > to confirm the proper users of the various resources ARIN > controls. > 3 Statistic gathering by ARIN and third parties on resource > utilization. > 4 As a contact database to facilitate communication with the > person or entity responsible for a particular resource. > > ARIN prohibits the use of the APID for the following uses: > > 1 Sending any unsolicited commercial correspondence advertising > a product or service to any address (physical or electronic) > listed in the APID. > 2 Using data in the APID to facilitate violating any state, > federal, or local law. The above (both supported and prohibited parts) is basicly what I included as guidance points in rewrite of Whois AUP proposal as something that ARIN Council should futher work on to create an actual text. See below about it > ARIN shall allow all non-prohibited uses of the APID, however > unless those uses are listed as a supported use the data set > may be changed in such a way as to render them ineffective, > or they may be blocked outright as deemed necessary by ARIN > staff. I'm not sure I agree with giving this much power. > Users of applications not listed who are concerned > that they are supported should introduce a proposal to add > their application to the supported list. Again I'm not sure its good idea. > Now, last but not least, since we know what are the supported uses > of the APID we can look at what information is required to be in the > APID to support each point. Clearly the data set that needs to be > supported in total is the union of all of the individual data sets. > > Supported use #1 - No data needs to be listed in the APID to support > ARIN's implementation of policies. All data could be listed in the > ACID for these purposes. I do not see why implementation of policies is purely an confidential matter. In fact public verification as from #2 seems to apply here. > Supported use #2 - For community verification all resources managed > by ARIN need to be listed, along with contact information. A > mechanism should be supplied to allow the delegation by resource > holders for subsets of the resource where desired by the holder. > For the purposes of verification delegation of subsets is completely > optional. I disagree. The deligation is not optional but mandatory for proper audit of ARIN's activities as well for other uses too. > Supported use #3 - Statistics are one of the biggest problems. First > order statistics are generally published by ARIN outside of the APID > or ACID, and there is little need for that data to be replicated by > outside parties. Of more interest in second order data. In order > to get the most useful second order statistics the groups gathering > that data would like the largest amount of information present in > the database. Aside from the ARIN membership using some of the > statistics presented from third parties, there has been no consensus > to date on ARIN funding or making available specific data for those > uses. > > As a result, while statistics should be a supported use, they should > not that this time influence what is, or is not in the APID. That there has been no consencus on ARIN's sponsoring certain projects, does not mean there is not a niche for those statistical projects or that there are no commercial interest in such statistical data. > ARIN may want to develop a program such that under NDA and other > controls approved organizations can access portions of the ACID > database in order to get additional data. If we do not require certain data to be made available, it just will not be. Limiting to NDA will also limit who is willing to actually do these kinds of statistical or other research which is not good for community. We should focus on existing bulk whois agreement instead. > Supported use #4 - For use as a contact database, all resources > managed by ARIN need to be listed, along with contact information. > In addition, policies and procedures need to be in place to keep > that contact information up to date. Ok good so far. > Realizing that contact information > is a management burden, ARIN should support the minimum set of data > that allows for generally accepted methods of communication. Or, come on, - this is just an excuse not to list contact data for actual user, which is a BIG plus during investigations of any kind of abuse activities. As far as burden, its on whoever submitted data to ARIN and they should be required as a matter of policy to keep data up to date and have verification and reporting mechanisms when its not (ARIN may possibly facilitate in such conversation). > To that end, ARIN shall list e-mail, phone, and postal contacts > for all direct resource delegations, and have a procedure to > periodically verify that information. The contact must verify > that they are responsible for the resource in question, and that > the contacts listed are the correct ones for dealing with any > issues resulting from the use of that resource. A mechanism > should be supplied to allow for the delegation of a subset of a > resource along with contact information. Delegated contact > information shall be verified using the same procedure as direct > delegations. These subdelegation should be marked as able to > be further sub-delegated or not. This is what is already being done as ARIN alredy has record indicating if the organization can act as ISP and futher subdeligate or not. > A sticky point in e-mail, but much more so in some of the public > policy meetings is that there is not agreement on the valid uses > for APID data. One one end, some want APID to revert back to it's > earlier behavior of being a sort of white pages for the Internet. > The opposite view is that only the highest level of information > should be in the database, and that any further information should > be sought from the organization listed in the database. > > The first thing to do is look for precedent. While the initial > database was all encompassing, as early as 1994 that started to > change in policy (and possibly a bit earlier in practice). An > interesting case study here is the similar-but-different case of > DNS names. If "harvard.edu" delegates "cs.harvard.edu" to the CS > Department for use there is no requirement DNS Registrars be notified. No, but there is a record of actual subdeligation. It includes at the very minimum actual subdeligation name and also list of dns servers that service the subdomain. What you're proposing that that exist subdomains that there be no public records on tht existance of these subdomains at all in amy public records. > There is no protocol requirement to put contact information (or > anything besides basic nameserver IP's) in the protocol. There is > the ability in the protocol (via RP records, and TXT records) to > list that information. However, if that information is not listed > and you want to know something about "cs.harvard.edu" you must back > up one level in the tree to "harvard.edu", contact them and hope > they will pass you along to the right people. > > Perhaps more interesting from a practical point of view is that a > smaller amount of valid contact information is generally much more > useful than a larger set of invalid data. Its a lot better to know when data has been verified and is valid. This does not mean the rest of the data that has not been verified is not interesting from practical point of view. > In addition, there is a > cost to maintaining valid data, in that ARIN must expend resources > keeping the data set up to date. All of these point to a minimal, > but highly verified and accurate data set as being the cheapest > solution that also provides the highest probability of getting a > valid contact. ARIN should verify contacts for organizations it directly deals with. Verification of the rest of data should be on the hands of these "1st level" organizations with ARIN getting involved as last point and only if organization is not doing anything about it and in that case it itself may fact same "punishment" as if it were directly trying not to maintain proper records. > As a last point on this subject, there are cases where the entity > that has been given use of a resource, and the person who should > be listed as a contact for a resource are different. For instance, > managed services companies often allocate resources for their > customers, but are tasked with answering all external queries about > those resources, and either answering them directly for their client > or forwarding them to their client as appropriate. The system > adopted should support these situations, has having the proper > contact in these cases is far more likely to lead to useful information > than having the actual user of the space listed. No you're wrong as you're mixing things up. One is direct human or robot contact which may well be the ISP and not actual end-user and helps facilitate immediate resolution. The other is tracking down the abusers, stopping it when ISP is not being responsive (want to know how much space they have been deligated), etc. Both parts of data (contact and registrant information) are usefull and important. > Finally, this leads to the policy of what should be in the APID: > > ARIN shall publish verified contact information and the > resource(s) allocated (including identification for that > allocation, like date of allocation or other information > identified by ARIN) in the APID in the following cases: > > - All resources delegated by ARIN. > - If allowed by the parent delegation, and requested by the > contact listed with the parent, a subdelegation of a resource > originally delegated by ARIN. I agree with requiring to be listed only contacts that are verifiable and are willing to be contacted. I disagree about not listing registrant at all or the amount of space they have been deligated. > ARIN shall insure all contact information in the APID is > verified from time to time and is correct to the best of ARIN's > ability. Agreed. > To comment on the implementation. I suspect SWIP as it exists today > would remain, simply having a two flags added to the template. > "Make public", and "allow downstream to SWIP". Both would default > to no, making all information appear only in the ACID. No, no, no. If anything "make public" should be default. Allow to SWIP should become yes if certain contact is added to that SWIP that has such responsibility. > Sites using rwhois could choose to restrict access to their rwhois > server to ARIN staff netblocks only if they do not whish to make their > information public. I have to say that currently rwhois is not such a gree protocol for doing restrictions on who can view only one subset of data. Most who run rwhois have all its data public and if it is not enough for ARIN when its making decision on additional allocation to that organization, then they provide in different form additional information to ARIN. There are also couple organizations that run rwhois server completely private, supposedely only for ARIN's access. > Last but not least, some teeth are needed. Without them companies > could simply not comply with the policies. As such a mechanism > is needed to punish those who do not comply. > > There are two ways ARIN may find non-compliance. First, ARIN may be > unable to verify contact information during the verification process. > In this case the resource should be put in a suspended state, and > the parent for that record should be contacted. Agreed. > In the event there is no response for repeated attempts after the > resource has been suspended the resource shall be revoked. Be carefull with saying that. Are you willing for ARIN to revoke legacy allocations? Or allocations made prior to these new rules where organization did not agree to them? > The second method is that ARIN may be notified that someone is > unable to contact an entity. The entity reporting the problem must > show proof of attempting to make contact via two different methods. > ARIN should then follow the standard contact verification procedure > to verify the contact, and if verified seek explanation as to why > there was no response. > > ARIN may set a threshold after which repeated reports by third > parties will result in suspension, even if verification succeeds. > ARIN may also set a threshold after which it can ignore notices > from those sending incomplete reports, or reporting organizations > which can document responses. These are all details that can be worked out later on. I'm actually not 100% certain if these details should be part of the policy or operating setup that ARIN adapts but we can talk about it more. > The proposal: > > If ARIN is unable to verify contact information via the normal > verification procedure ARIN shall attempt to notify the parent > of the resource to have the information updated. If there is > no parent, or if the data is not corrected in a reasonable > amount of time the resource shall be SUSPENDED. I would change this to having first resource marked as INVALID. > Once the resource is suspended ARIN shall make one more request > of all contacts listed with the resource and the parent resource > (if available), and if no response is received in a reasonable > amount of time the resource shall be reclaimed. And after resource is marked is INVALID and organization does not reestablish resource validity within certain period of time, ARIN should have an option to not renew the resource at its next billing annivessary. Possibly this is pretty simular to how Leo imagines the process above anyway. My opinion is that we should have this all discussed as part of discussions on current POC Verification proposal. > Third parties may report the inability to make contact with a > party via information in the APID. In this case ARIN shall > attempt the contact verification procedure for that contact > immediately. If a response is received, ARIN should document > that a problem occured, and the responce from the resource > holder. Offenders who fail to repond to third parties more > than 4 times per month for three months may have their resources > reclaimed at the discression of ARIN staff. Also should be discussed as possible details for POC Verification. > If a third party submits reports of the inability to make contact > that are subsequently disproven, ARIN may choose to ignore reports > from specific companies, people, e-mail addresses, or any other > classification means as appropriate. > > The ARIN staff shall publish the time thresholds and procedural > details to implement this policy on the ARIN web site. > > If a resource is reclaimed under no circumstances shall the > holder of that resource be entitled to a refund of any fees. If this is done without resource holder having agreed to new policies as part of the service agreement they have signed when they got the resource, then attempts to completely revoke the resource may well lead to court. Opinion of ARIN's legal council should be asked before we proceed on anything similar to above in ARIN policy process. > The proposals listed above overlap with some other proposals already > passed and in the process. They are enumerated below, along with > the reasons they should be abandoned or repealed. > > * 2002-3 - Residential Customer Privacy. > > This policy should be repealed, as under my proposal there is no > requirement to list residental customers at all. These policies > do not conflict, but do not make much sense together. It should be "REPEALED", it should be ABSOLUTED by rewrite of policy that focuses on PUBLIC & PRIVATE information. > * 2002-4 - Bulk Copies of ARIN's whois > > This policy should be repealed, as under my proposal there is a > definition of when an AUP is needed. These two policies potentially > conflict. 2003-9 will ABSOLUTE this policy anyway. > * 2002-8 - Privatizing POC Information > > This policy should be repeaed. Under my proposal a company may > make available contacts that are only listed in the ACID. My > proposal is also flexable in that ARIN staff can allow many more > contacts than are on the existing template into the ACID as necessary > without them appering in the APID. Indeed, I expect ARIN staff to > encourage users (via new forms and methods) to list role accounts in > the APID, while providing individuals for the ACID, which should > make some interactions much easier for the ARIN staff. Same as 2002-3, this should be ABSOLUTED by new PUBLIC/PRIVATE information policy that defines what kind of information is REQUIRED to be public. > * 2003-9 - Whois Acceptable Use Policy (AUP) > > This policy should be abandoned. My proposal requires an AUP as this > proposal does, but leaves it up to ARIN staff and legal to both write > the policy and keep it up to date. ARIN staff may want to use this > proposal as a template. As members of AC should already be aware (including Leo), I proposed exactly that to AC already - that instead of providing exact text of AUP that its main points be included as guide for ARIN legal council to create actual legal document. I intend to proceed in this direction and still awaiting comments from AC on this point as well as comments from ARIN legal council, especially on if he is willing and able to present a draft version of the AUP right after presention of the proposal. Time is short however, if I do not receive comments by end of Wednesday, I'll have no choice but to request update of proposal text on my own (so it would be ready for public policy meeting) and present this new version on the public policy meeting. > * 2003-16 POC Verification > > This policy should be abandoned. My proposal includes POC > verification, and allows ARIN staff to define the procedure and > publish it on the ARIN web site. ARIN staff may want to use this > proposal as a template. Again, I see no reason why the policy should be abandoned. We should try to work on POC verificion mechanism now and if anything try to implement it and see how it works and what can be improved in it. This would help in the future general policy rewrite but its a good on its own and can easily be integrated with future rewrite. > * 2003-5 Distributed Information Server Use Requirements > > This policy should be MODIFIED. This proposal covers many items, > most of which are covered in my proposal, however there is one > important item which is not. This policy requires rwhois servers > to be available 24x7 to the public. This is an important proposal, > and should continue on that point alone. If an entity is going > to publish information via rwhois they must take commercially > reasonable actions to make it available 24x7. Adding that > requirement to my proposals would put it in the wrong place. Same as with 2003-9 and 2003-16, it works on specific issues and when doing overall rewrite of the policy it is also replaced by new whois/database policy and becomes part of it. Neither one should be MODIFIED or ABANDONED. They should all be ABSOLUTED by new better rewrite of policy texts. --- William Leibzon Elan Networks william at elan.net From memsvcs at arin.net Wed Apr 14 11:00:13 2004 From: memsvcs at arin.net (Member Services) Date: Wed, 14 Apr 2004 11:00:13 -0400 (EDT) Subject: [ppml] Policy Proposal 2003-9: WHOIS Acceptable Use Policy Message-ID: <200404141500.LAA28715@ops.arin.net> This policy proposal was previously discussed on this mailing list and at the ARIN XII Public Policy Meeting. The author revised the proposal text. This proposal is open for discussion on this mailing list and it is on the agenda at the upcoming Public Policy Meeting. Member Services American Registry for Internet Numbers (ARIN) ### * ### This proposal obsoletes current bulk WHOIS policy 2002-4 and changes current Bulk WHOIS Acceptable Use Policy (AUP) to become general WHOIS Acceptable Use policy that would apply to all WHOIS queries. In particular: 1. ARIN should create and publish on its website "WHOIS Acceptable Use Policy" that will apply to any type of access to ARIN WHOIS database. This AUP policy should include: a. Information on appropriate use of WHOIS data only for purposes of research and Internet operations. b. Information on inappropriate use of WHOIS data such as for advertising, direct marketing, marketing research or similar purposes. c. Information on restrictions for redistribution of ARIN WHOIS data by third parties in order to insure such redistributed data is used in accordance with requirements of this policy. d. Information on procedures and actions ARIN may take if WHOIS AUP is not followed. 2. Automated Internet-based access to WHOIS data with individual queries (such as by using WHOIS protocol) should include a one-line statement that data is provided and can only be used according to 'ARIN WHOIS Acceptable Use Policy' with a link to where the policy is published on the ARIN website. All other access to WHOIS data must include entire ARIN WHOIS AUP. 3. A policy for bulk WHOIS access should be published on ARIN website as follows: "Access to the entire WHOIS database or large portion of it may be obtained by any organization or individual provided that this organization or individual agrees in writing to ARIN WHOIS Acceptable Use Policy. WHOIS data provided under bulk WHOIS access will not include any information that is marked as private. Access to WHOIS data may be by way of: a. Individual WHOIS queries b. FTP or other type of download c. Hard media distribution (such as CD-ROM) Access provided by means of the public Internet must require authentication if the protocol being used supports it. ARIN may request authentication information be changed on a regular basis for those who desire repeat access to the bulk data. Bulk WHOIS requests for CD-ROM or similar hard media delivery must be filled out and signed individually for each request and ARIN may charge an appropriate fee to cover media and labor costs." From bicknell at ufp.org Mon Apr 19 14:28:10 2004 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 19 Apr 2004 14:28:10 -0400 Subject: [ppml] A comprehensive discussion of whois and public data. In-Reply-To: <20040412171333.GA5883@ussenterprise.ufp.org> References: <20040412171333.GA5883@ussenterprise.ufp.org> Message-ID: <20040419182810.GA67900@ussenterprise.ufp.org> I would like some more feedback, positive or negative. Feel free to find me a the meeting and offer your opinion. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: