From info at arin.net Wed Oct 4 17:34:58 2006 From: info at arin.net (Member Services) Date: Wed, 04 Oct 2006 17:34:58 -0400 Subject: Staff Comments Regarding Policy Proposal 2006-1 Message-ID: <45242902.4000409@arin.net> These are the ARIN staff comments regarding Policy Proposal 2006-1: Residential Customer Privacy. These comments include those of the ARIN General Counsel and ARIN staff, and contain analysis of legal, procedural, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of this proposal may necessitate further analysis by Counsel and staff. Policy Proposal 2006-1 restated below and available at: http://www.arin.net/policy/proposals/2006_1.html. This policy calls for the suppression of certain items of information regarding customers of organizations that receive allocations of Internet number resources from ARIN. The ARIN General Counsel sees no liability risk for ARIN but has some concerns. Counsel states: "However, this type of policy may have a series of impacts in different portions of the Internet community. Let me give a single example: Law enforcement authorities have a desire for real time ability to obtain information of the type that will now be masked. This may increase the burden on ISP's who must be correspondingly contacted more often to obtain such information. The government's might wish a different policy. Issues of customer privacy and how ARIN's policies impact such issues remains an area of ongoing legal concern and attention." ARIN staff concerns relate to whether or not this policy is interpreted to mean suppression of information that is collected as opposed to suppression of information that is available to the general public. ARIN has a stringent non disclosure policy concerning the protecting of information. Such non disclosure can be applied to any information that is to be suppressed from access by the general public. Staff calls to the attention of the community the effect of the suppression of information from the general public that is currently used by those who use this data in research. This data would have a diminished value as the use of a term such as "private residence" or "private customer" may not necessarily reflect the accurate distribution of the address space by the customers of ARIN. The community may want to consider further definition of these terms to provide clarity to the research community. If on the other hand this policy would permit the suppression of information being presented to ARIN, staff has additional concerns to those described above. These concerns relate to the ability of ARIN to verify the validity of the information as it is reported by the customers of ARIN as required by current policy. It would be easier for less than scrupulous organizations when reporting utilization information of the address space entrusted to them to hide or otherwise provide false information such as substituting "private residence" when in fact the information relates to a business. This impacts ARIN's ability to exercise the stewardship role that has been entrusted to it by the community. If adopted this policy replaces policy text in sections 4.2.3.7.6 and 6.5.5.1 as well as remove the words "that includes displaying only the city, state, zip code, and country" from section 3.2. The resource impact of implementing this policy is viewed as moderate. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Changes to the current software suite - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-1: Residential Customer Privacy Policy statement Proposal type: modify (NRPM sections 4.2.3.7.6 and 6.5.5.1) Policy Term: permanent An organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private customer - XYZ Network', and the customer's entire address may be replaced with 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. NRPM Section 3.2 on Distributed Information Server Use Requirements (from policy proposal 2003-5) is also updated by striking the words "that includes displaying only the city, state, zip code, and country". Policy Rationale This policy allows for a residential customer's entire physical address to be suppressed, not just the street name and number. It also removes the US-centric phrases "state" and "zip code" from the NRPM, reflecting ARIN's broader service area. In many cases, a postal code or even a city name can identify few enough individuals, particularly considering the set of those likely to have their own IP assignments, that the intent of policy proposal 2003-3 is constructively defeated. Timetable for implementation: Immediately upon approval. From info at arin.net Wed Oct 4 17:35:17 2006 From: info at arin.net (Member Services) Date: Wed, 04 Oct 2006 17:35:17 -0400 Subject: Staff Comments Regarding Policy Proposal 2006-2 Message-ID: <45242915.403@arin.net> These are ARIN staff comments regarding Policy Proposal 2006-2: Micro-allocations for Internal infrastructure. These comments include those of the ARIN General Counsel and ARIN staff, and contain analysis of legal, procedural, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of this proposal may necessitate further analysis by Counsel and staff. Policy Proposal 2006-2 restated below and available at: http://www.arin.net/policy/proposals/2006_2.html. This policy provides for organizations using only a single aggregate requiring additional noncontiguous IP space for their internal infrastructure not to be routed in the global Internet routine table. The ARIN General Counsel sees no liability risk for ARIN. ARIN staff believes the policy is not entirely clear. Specifically, the term 'justification' is broad and requires further definition. ARIN cannot verify the blocks allocated under this policy are not routed. In the event that these blocks are routed, staff proposes revoking the number resources. This policy appears to be directed towards allocations, the community may want to consider further definition of this policy regarding end user assignments to provide clarity on this point. If adopted this policy statement will be inserted into a new section numbered 6.10.2. The existing policy text under 6.10 will be renumbered to 6.10.1. The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure Policy statement Proposal type: modify Policy term: permanent Policy statement: 6.10.1 Micro-allocations for Internal Infrastructure Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide technical justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations must be allocated from specific blocks reserved only for this purpose. Policy Rationale Organizations that have only a single aggregate may require additional noncontiguous IP space for their internal infrastructure. This space should not be routed in the global Internet routing table. This will provide for the protection of internal infrastructure and support for applications that are sensitive to long convergence times like VoIP. It is important to note that the additional prefix allocation will not negatively impact the global routing table size as the additional prefix should not be routed. BGP Re-Convergence ISPs use BGP to originate their aggregate from multiple nodes within their infrastructure. They do this by routing their aggregate to discard on multiple devices. This ensures the Internet can reach the aggregate even when one or more nodes fail. If the next hop for a route is reachable via an aggregate that is in the routing table, then failures affecting the reachability of the next hop are subject to BGP hold timers, which can cause traffic to be dropped for the length of the bgp hold time (typically 3 minutes) The BGP re-convergence problem results when a multi-homed customer is announcing the same route to two different edge routers. When the edge router sourcing the primary path fails, the local address which is acting as the next hop, is removed from the IGP. If the next hop is still reachable through an aggregate or covering route, then the route will not be immediately invalidated in bgp. Until the bgp session with the failed device times out, traffic will be drawn to the device originating the aggregate, which is routed to discard and traffic will be dropped. After the bgp session with the failed device times out, the route will be removed and the next best route will be used. To minimize route failover time, you must ensure that the local addresses of the infrastructure, that act as next-hops for Internet routes, are NOT numbered with addresses that are a more specific than the aggregate. A detailed description of the problem space follows in the next three paragraphs. Having BGP next-hops that are not aggregated can cause faster convergence for customers who have multiple links to multiple routers of a single upstream AS. Take the case where a customer has two connections, link1 to edge-router1 and link2 to edge-router2, to a single upstream AS. The customer has an eBGP session with the loopback 2001:DB8::1/128 on edge-router1 and with loopback 2001:DB8::2/128 on edge-router2. The customer advertises a single prefix 2001:DB8:1000::/48 to both edge-router1 and edge-router2. The edge routers set next-hop self. The upstream ISP will have two paths to the prefix 2001:DB8:1000::/48, one with a protocol next-hop of 2001:DB8::1 and one with a protocol next-hop of 2001:DB8::2. Assume the upstream ISP's entire network prefers the path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 due to lower BGP MED value. Also assume that all of the address space owned by the upstream ISP is 2001:DB8::/32, and the loopbacks of both edge routers are a more specific of the aggregate /32. The upstream ISP has a pull-up route for 2001:DB8::/32 in the core of the network. This allows for the aggregation of all the more specific routes of 2001:DB8::/32. It insures the stability of the 2001:DB8::/32 announcement, while preventing an isolated edge router from advertising reachability to the network. If edge-router1 fails then 2001:DB8::1/128 will be immediately removed from the IGP. The preferred prefix for 2001:DB8:1000::/48 with a next-hop of 2001:DB8::1 will remain a valid bgp route and will continue to be the best path because 2001:DB8::1 is reachable through the pull-up route 2001:DB8::/32. Traffic will get blackholed for up to three minutes (BGP default hold time) until the BGP prefix 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 times out. Only then will traffic get forwarded to the next best path for 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::2. If instead the loopbacks of the edge routers (or any BGP protocol next-hop addresses) are not part of the 2001:DB8::/32 aggregate, and there is no aggregate that covers the edge router loopbacks, then convergence will be much quicker. Assume that edge-router1 is using 2001:408::1 and edge-router2 is using 2001:408::2, and the only pull-up route is 2001:DB8::/32. In this case once edge-router1 fails, the IGP will detect it and remove 2001:408::1/128 from the IGP. This will invalidate the preferred path to 201:DB8:1000::/48 with a protocol next-hop of 2001:408:1 as there will be no route to the next hop (or even a less specific of this address). Once the path is invalidated, then the next best path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:408::2 will be declared best. Convergence times will be on the order of magnitude of the IGP failure detection and path re-calculation, typically less than one second. --------------- | Core Router |static route | |2001:DB8::/32 discard ----+------+--- | | / \ /-------------/ \--------\ / \ / /----------------------------\ \ | | | | ------+---+-- --+---+------ |Core Router|static route |Core Router|static route | |2001:DB8::/32 discard | |2001:DB8::/32 discard ---------+--- ---------+--- | | ---------+--------- ---------+--------- | edge-router1 | | edge-router2 | | 2001:DB8::1/128 | | 2001:DB8::2/128 | ---------+--------- ---------+--------- | | \ link1 link2 / \------------\ /---------/ \ / | | ----+---------+---- | CPE | | | ---------+--------- | LAN 2001:DB8:1000::/48 Internal Infrastructure Security Considerations Internal infrastructure could be numbered out of space that is not routed or reachable by the public Internet. This could be used to secure internal only services in a multi-layered approach by filtering direct network connections in the forwarding plane, and not routing the network in the global Internet routing table. Internal services which could take advantage of these layers of protection include: SNMP services, iBGP mesh, Out-of-Band management network(s), remote access to the network devices that make up the network in question. A layered security approach will help to prevent breaches in security via singular config management problems. Additionally, having all of the services out of an aggregate block will simplify the configuration management situation. In essence, this allows for a two tier approach of protecting infrastructure, both in the control plane by not routing the network, and in the forwarding plane by utilizing packet filters which are easily constructed and managed due to the uniqueness of the internal infrastructure block. Private Address Considerations Private addresses are not appropriate for a number of reasons. A public Internet network using private addresses internally may create confusion if trace routes contain private addresses. Additional problems may result due to wide spread filtering of private address space. ICMP messages may get dropped due to such a policy. This can lead to perceived odd behavior and make troubleshooting difficult. Additionally, the consequences of accidentally routing private ip space that is not globally unique, are potentially worse than if you accidentally announced globally unique space. DNS for private address space is today provided by blackhole-1.iana.org. and blackhole-2.iana.org. A provider who wants to maintain forward and reverse DNS sanity has to hijack those ip addresses to provide consistent DNS resolution. This will cause any users who's traffic transits that provider's network to also get 'inconsistent' answers with respect to the private address space in question. For management and troubleshooting purposes, it is important that infrastructure which provides Internet route reachability be numbered with addresses that resolve through DNS. Also, global uniqueness of addressing is important in minimizing renumbering efforts as organizations (and their networks) merge. RFC 4193 provides for neither of these needs. Timetable for implementation: Immediate From info at arin.net Wed Oct 4 17:35:29 2006 From: info at arin.net (Member Services) Date: Wed, 04 Oct 2006 17:35:29 -0400 Subject: Staff Comments Regarding Policy Proposal 2006-3 Message-ID: <45242921.7020106@arin.net> These are the ARIN staff comments regarding Policy Proposal 2006-3: Capturing Originations in Templates. These comments include those of the ARIN General Counsel and ARIN staff, and contain analysis of legal, procedural, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of this proposal may necessitate further analysis by Counsel and staff. Policy Proposal 2006-3 restated below and available at: http://www.arin.net/policy/proposals/2006_3.html. This policy provides for capture and publicly available mapping of authorized prefix originations by ASNs. The ARIN General Counsel sees no liability risk for ARIN. ARIN staff believes the policy is not entirely clear. Specifically the term "user" could apply to both direct registrants as well as reassignments and needs further definition. The policy duplicates capabilities of the routing registry and could be addressed by enhancing this existing functionality. If adopted the policy statement will be inserted into a new section numbered 3.5. The resource impact of implementing this policy is significant. Barring any unforeseen resource requirements, this policy could be implemented within 3-6 months from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Template change - Revision to Registration Software - Revision to Directory Services - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-3: Capturing Originations in Templates Policy statement Proposal type: new Policy term: permanent Policy statement: ARIN will collect an optional field in all IPv4 and IPv6 address block transactions (allocation and assignment requests, reallocation and reassignment actions, transfer and experimental requests). This additional field will be used to record a list of the ASes that the user permits to originate address prefixes within the address block. ARIN will produce a collection of the mappings from address blocks to ASes permitted to originate that address block, The collection will consist of a list where each entry will consist, at a minimum, of an address block, a list of AS numbers, and a tag indicating the type of delegation of the address block. This collection will be produced at least daily. ARIN will make the collected mappings from address blocks to AS numbers available for bulk transfer in one or more formats chosen at its own discretion, informed by the community's current needs. This data will not be subject to any redistribution restrictions -- it may be republished or repackaged it any form. Should ARIN choose to use WHOIS bulk transfer as the bulk form of data access required by this paragraph, the address block to AS mappings will not be subject to any redistribution restrictions, but the remainder of the WHOIS data will remain subject to the terms of the then-current AUP regarding bulk access to WHOIS data. ARIN may also make the collected or individual mappings from address blocks to AS numbers available in other forms, possibly query services, chosen at its own discretion, informed by the community's current needs. ARIN may require agreement to an acceptable use policy for access to the data in these forms. Policy Rationale Origination of prefixes by ASes that have no authority for the origination is a recurring problem in the Internet routing system. A list of authorized prefix originations would be beneficial to operators in * constructing routing filter lists to counter bogus originations, * interacting with customers requesting routing of a prefix, and * diagnosing routing problems. A list of authorized prefix originations is also the necessary first step for any known solution for securing the routing system. Prefix originations can be stored in routing registry RPSL route objects. However, the authority for addresses and for ASes belongs to the RIRs. There is presently no mechanism to translate ARIN's authority for number resources to an IRR. Furthermore, operators have been less than diligent in creating and maintaining route objects. Capturing the prefix origination authorization in number resource registrations with ARIN has two main goals: * benefit from the scrutiny with which ARIN verifies initial requests and authenticates subsequent transactions, and * inherit the operators' self-discipline in completing resource requests and transactions. As an additional benefit, this could take a step toward populating the IRR with data known to be accurate. The intended use of this data means that both query for individual entries and bulk access to a list of the collected entries, without restriction on redistribution, is required. This policy requires that the additional data be provided through the usual whois query service and some bulk access service that has no restrictions. It permits ARIN to provide the bulk access through the existing bulk whois service if the new additional data is not subject to the bulk whois AUP restrictions. The policy does not limit ARIN to providing only those two services (whois query and unrestricted bulk access); other additional services may be developed at ARIN's discretion. It is expected that entries in the list of collected entries will include at a minimum the present NetRange and NetType attributes, with a new attribute, perhaps named OriginatingASList, for the list of permitted originating ASes. This policy will presumably be incorporated into NRPM section 3.4. Timetable for implementation: Within sixty (60) days of approval. From info at arin.net Wed Oct 11 09:58:31 2006 From: info at arin.net (Member Services) Date: Wed, 11 Oct 2006 08:58:31 -0500 Subject: ARIN XVIII Meeting Report Now Available Message-ID: <003001c6ed3d$56584050$1e00080a@arin.net> The ARIN community recently concluded the ARIN XVIII Public Policy and Members Meetings, held in St. Louis, Missouri, 11-13 October 2006. The meeting report includes presentations, webcast archives, summary notes, and transcripts of these meetings, and is now available on the ARIN website at: http://www.arin.net/meetings/minutes/ARIN_XVIII/ In addition to these files, the page referenced above has links to presentations for the Sunday "Networking with IPv6" workshop and tutorials. We thank all in the community who participated either in person or remotely, and look forward to seeing you all again for ARIN XIX in San Juan, Puerto Rico, 22-25 April 2007. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Oct 11 10:07:09 2006 From: info at arin.net (Member Services) Date: Wed, 11 Oct 2006 09:07:09 -0500 Subject: ARIN XVIII Now Underway [corrected] Message-ID: <003101c6ed3e$8b0a6f70$1e00080a@arin.net> The ARIN XVIII Public Policy and Members Meeting is now underway in St. Louis, Missouri. For those in the community unable to make it to St. Louis for the meeting, ARIN is once again offering a webcast of the Public Policy and Members Meetings via RealNetworks Helix Server. The times of the broadcast are as follows (All times are Central Daylight Time (CDT), (UTC/GMT -5 hours): Public Policy Meeting (Policy and technical discussions) Wednesday, 11 October 9AM - 5PM Thursday, 12 October 9AM - 5PM Members Meeting (ARIN reports and speeches by Board, Advisory Council and NRO NC candidates ) Friday, 13 October 9 AM - 12PM For those who already registered to participate remotely, you may send in questions or comments during the times listed above. The full agenda is available at http://www.arin.net/ARIN-XVIII/agenda.html. For details about how to connect to the webcast, or to refer to the Remote Participation Acceptable Use Policy, please see: http://www.arin.net/ARIN-XVIII/webcast.html Regards, Member Services American Registry for Internet Numbers (ARIN) P.S. Apologies for the premature posting of the meeting report availability. From info at arin.net Wed Oct 11 18:46:50 2006 From: info at arin.net (Member Services) Date: Wed, 11 Oct 2006 18:46:50 -0400 Subject: Proposed Policy: Changes to IPv6 initial allocation criteria Message-ID: <452D745A.3010409@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. Since this proposal was received within 10 days of the next scheduled meeting of the ARIN Advisory Council, the review period will be extended to the regularly scheduled meeting that occurs after the upcoming meeting. If the AC accepts the proposal or reaches an agreement with the author, then the proposal will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal or can not reach an agreement with the author, then the AC will notify the community of their decision with an explanation; at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Changes to IPv6 initial allocation criteria Author: Jordi Palet Martinez Proposal Version: 1 Submission Date: 11/10/2006 Proposal type: delete Policy term: permanent Policy statement: Delete section 6.5.1.1 d. of NRPM Rationale: The existing policy is fine for an existing and known ISP in the ARIN region, but is not considering the case of new ISPs, which may want to start offering IPv6 services. Is artificial to ask them for start with IPv4 services (which typically will do, but not necessarily), wait for weeks/months (?) to be "known", and then come back for the IPv6 allocation request. In addition to that, they need to have a plan for more than 200 /48 assignments. The first question here is that there is room for business with one or just a few IPv6 customers, and it seems irrational not allowing this type of business to be possible, may be even it can be considered against the anti-trust regulations. Second point is regarding the usage of the /48. An ISP may decide to assign a different prefix size, example a cellular operator with probably will use /64. Is important to clarify that the "200" comes from historical reasons when this proposal was jointly developed with RIPE and APNIC, but the situation is that other regions such as LACNIC and AfriNIC already got rid of this requirement, and in both, RIPE and APNIC is under discussion. This may even bring to a possible "untrue" plan to be suggested by an ISP if he needs to get an IPv6 prefix allocated. Regarding the restriction of the usage in 5 years, I think is enough with the criteria indicated in c that the address space is advertised, as there is no ISP interested in getting a prefix which is not being used. Is an operational cost that doesn't make sense if there is not business beyond covering it, never mind if we talk about a few months or a few years. In summary, the proposal will allow new ISPs, ISPs with a reduced number of customers, or ISPs willing to offer only IPv6 services, to immediately access this resource. No financial/liability implications for the community and ARIN are foreseen, on the other way around, it will allow ARIN better fulfilling its mission. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Fri Oct 13 14:31:07 2006 From: info at arin.net (Member Services) Date: Fri, 13 Oct 2006 14:31:07 -0400 Subject: Policy Proposal 2006-1: Residential Customer Privacy - Abandoned Message-ID: <452FDB6B.2000509@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed policy proposal 2006-1: Residential Customer Privacy. It has determined that there is no community consensus in favor of the proposal and should thus be abandoned. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 12 October 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVIII/mem.html In order for this proposal to be further considered the author must use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 20 October 2006. The current policy proposal text is provided below and is also available http://www.arin.net/policy/proposals/2006_1.html The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html. Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-1: Residential Customer Privacy Policy statement Proposal type: modify (NRPM sections 4.2.3.7.6 and 6.5.5.1) Policy Term: permanent An organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private customer - XYZ Network', and the customer's entire address may be replaced with 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. NRPM Section 3.2 on Distributed Information Server Use Requirements (from policy proposal 2003-5) is also updated by striking the words "that includes displaying only the city, state, zip code, and country". Policy Rationale This policy allows for a residential customer's entire physical address to be suppressed, not just the street name and number. It also removes the US-centric phrases "state" and "zip code" from the NRPM, reflecting ARIN's broader service area. In many cases, a postal code or even a city name can identify few enough individuals, particularly considering the set of those likely to have their own IP assignments, that the intent of policy proposal 2003-3 is constructively defeated. Timetable for implementation: Immediately upon approval. From info at arin.net Fri Oct 13 14:31:18 2006 From: info at arin.net (Member Services) Date: Fri, 13 Oct 2006 14:31:18 -0400 Subject: Policy Proposal 2006-2: Micro-allocations for Internal infrastructure - Last Call Message-ID: <452FDB76.10404@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 12 October 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVIII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2006_2.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 27 October 2006. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure Policy statement Proposal type: modify Policy term: permanent Policy statement: 6.10.1 Micro-allocations for Internal Infrastructure Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide technical justification indicating why a separate non-routed block is required. Justification must include why a sub-allocation of currently held IP space cannot be utilized. Internal infrastructure allocations must be allocated from specific blocks reserved only for this purpose. Policy Rationale Organizations that have only a single aggregate may require additional noncontiguous IP space for their internal infrastructure. This space should not be routed in the global Internet routing table. This will provide for the protection of internal infrastructure and support for applications that are sensitive to long convergence times like VoIP. It is important to note that the additional prefix allocation will not negatively impact the global routing table size as the additional prefix should not be routed. BGP Re-Convergence ISPs use BGP to originate their aggregate from multiple nodes within their infrastructure. They do this by routing their aggregate to discard on multiple devices. This ensures the Internet can reach the aggregate even when one or more nodes fail. If the next hop for a route is reachable via an aggregate that is in the routing table, then failures affecting the reachability of the next hop are subject to BGP hold timers, which can cause traffic to be dropped for the length of the bgp hold time (typically 3 minutes) The BGP re-convergence problem results when a multi-homed customer is announcing the same route to two different edge routers. When the edge router sourcing the primary path fails, the local address which is acting as the next hop, is removed from the IGP. If the next hop is still reachable through an aggregate or covering route, then the route will not be immediately invalidated in bgp. Until the bgp session with the failed device times out, traffic will be drawn to the device originating the aggregate, which is routed to discard and traffic will be dropped. After the bgp session with the failed device times out, the route will be removed and the next best route will be used. To minimize route failover time, you must ensure that the local addresses of the infrastructure, that act as next-hops for Internet routes, are NOT numbered with addresses that are a more specific than the aggregate. A detailed description of the problem space follows in the next three paragraphs. Having BGP next-hops that are not aggregated can cause faster convergence for customers who have multiple links to multiple routers of a single upstream AS. Take the case where a customer has two connections, link1 to edge-router1 and link2 to edge-router2, to a single upstream AS. The customer has an eBGP session with the loopback 2001:DB8::1/128 on edge-router1 and with loopback 2001:DB8::2/128 on edge-router2. The customer advertises a single prefix 2001:DB8:1000::/48 to both edge-router1 and edge-router2. The edge routers set next-hop self. The upstream ISP will have two paths to the prefix 2001:DB8:1000::/48, one with a protocol next-hop of 2001:DB8::1 and one with a protocol next-hop of 2001:DB8::2. Assume the upstream ISP's entire network prefers the path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 due to lower BGP MED value. Also assume that all of the address space owned by the upstream ISP is 2001:DB8::/32, and the loopbacks of both edge routers are a more specific of the aggregate /32. The upstream ISP has a pull-up route for 2001:DB8::/32 in the core of the network. This allows for the aggregation of all the more specific routes of 2001:DB8::/32. It insures the stability of the 2001:DB8::/32 announcement, while preventing an isolated edge router from advertising reachability to the network. If edge-router1 fails then 2001:DB8::1/128 will be immediately removed from the IGP. The preferred prefix for 2001:DB8:1000::/48 with a next-hop of 2001:DB8::1 will remain a valid bgp route and will continue to be the best path because 2001:DB8::1 is reachable through the pull-up route 2001:DB8::/32. Traffic will get blackholed for up to three minutes (BGP default hold time) until the BGP prefix 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::1 times out. Only then will traffic get forwarded to the next best path for 2001:DB8:1000::/48 with a protocol next-hop of 2001:DB8::2. If instead the loopbacks of the edge routers (or any BGP protocol next-hop addresses) are not part of the 2001:DB8::/32 aggregate, and there is no aggregate that covers the edge router loopbacks, then convergence will be much quicker. Assume that edge-router1 is using 2001:408::1 and edge-router2 is using 2001:408::2, and the only pull-up route is 2001:DB8::/32. In this case once edge-router1 fails, the IGP will detect it and remove 2001:408::1/128 from the IGP. This will invalidate the preferred path to 201:DB8:1000::/48 with a protocol next-hop of 2001:408:1 as there will be no route to the next hop (or even a less specific of this address). Once the path is invalidated, then the next best path to 2001:DB8:1000::/48 with a protocol next-hop of 2001:408::2 will be declared best. Convergence times will be on the order of magnitude of the IGP failure detection and path re-calculation, typically less than one second. --------------- | Core Router |static route | |2001:DB8::/32 discard ----+------+--- | | / \ /-------------/ \--------\ / \ / /----------------------------\ \ | | | | ------+---+-- --+---+------ |Core Router|static route |Core Router|static route | |2001:DB8::/32 discard | |2001:DB8::/32 discard ---------+--- ---------+--- | | ---------+--------- ---------+--------- | edge-router1 | | edge-router2 | | 2001:DB8::1/128 | | 2001:DB8::2/128 | ---------+--------- ---------+--------- | | \ link1 link2 / \------------\ /---------/ \ / | | ----+---------+---- | CPE | | | ---------+--------- | LAN 2001:DB8:1000::/48 Internal Infrastructure Security Considerations Internal infrastructure could be numbered out of space that is not routed or reachable by the public Internet. This could be used to secure internal only services in a multi-layered approach by filtering direct network connections in the forwarding plane, and not routing the network in the global Internet routing table. Internal services which could take advantage of these layers of protection include: SNMP services, iBGP mesh, Out-of-Band management network(s), remote access to the network devices that make up the network in question. A layered security approach will help to prevent breaches in security via singular config management problems. Additionally, having all of the services out of an aggregate block will simplify the configuration management situation. In essence, this allows for a two tier approach of protecting infrastructure, both in the control plane by not routing the network, and in the forwarding plane by utilizing packet filters which are easily constructed and managed due to the uniqueness of the internal infrastructure block. Private Address Considerations Private addresses are not appropriate for a number of reasons. A public Internet network using private addresses internally may create confusion if trace routes contain private addresses. Additional problems may result due to wide spread filtering of private address space. ICMP messages may get dropped due to such a policy. This can lead to perceived odd behavior and make troubleshooting difficult. Additionally, the consequences of accidentally routing private ip space that is not globally unique, are potentially worse than if you accidentally announced globally unique space. DNS for private address space is today provided by blackhole-1.iana.org. and blackhole-2.iana.org. A provider who wants to maintain forward and reverse DNS sanity has to hijack those ip addresses to provide consistent DNS resolution. This will cause any users who's traffic transits that provider's network to also get 'inconsistent' answers with respect to the private address space in question. For management and troubleshooting purposes, it is important that infrastructure which provides Internet route reachability be numbered with addresses that resolve through DNS. Also, global uniqueness of addressing is important in minimizing renumbering efforts as organizations (and their networks) merge. RFC 4193 provides for neither of these needs. Timetable for implementation: Immediate From info at arin.net Fri Oct 13 14:31:33 2006 From: info at arin.net (Member Services) Date: Fri, 13 Oct 2006 14:31:33 -0400 Subject: Policy Proposal 2006-3: Capturing Originations in Templates - Last Call Message-ID: <452FDB85.6070906@arin.net> The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has reviewed Policy Proposal 2006-3: Capturing Originations in Templates and has determined that there is community consensus in favor of the proposal to move it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 12 October 2006. The results of the AC meeting were reported by the Chair of the AC at the member meeting. This report can be found at http://www.arin.net/meetings/minutes/ARIN_XVIII/mem.html The policy proposal text is provided below and is also available at http://www.arin.net/policy/proposals/2006_3.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 27 October 2006. The ARIN Internet Resource Policy Evaluation Process can be found at http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Policy Proposal 2006-3: Capturing Originations in Templates Policy statement Proposal type: new Policy term: permanent Policy statement: ARIN will collect an optional field in all IPv4 and IPv6 address block transactions (allocation and assignment requests, reallocation and reassignment actions, transfer and experimental requests). This additional field will be used to record a list of the ASes that the user permits to originate address prefixes within the address block. ARIN will produce a collection of the mappings from address blocks to ASes permitted to originate that address block, The collection will consist of a list where each entry will consist, at a minimum, of an address block, a list of AS numbers, and a tag indicating the type of delegation of the address block. This collection will be produced at least daily. ARIN will make the collected mappings from address blocks to AS numbers available for bulk transfer in one or more formats chosen at its own discretion, informed by the community's current needs. This data will not be subject to any redistribution restrictions -- it may be republished or repackaged it any form. Should ARIN choose to use WHOIS bulk transfer as the bulk form of data access required by this paragraph, the address block to AS mappings will not be subject to any redistribution restrictions, but the remainder of the WHOIS data will remain subject to the terms of the then-current AUP regarding bulk access to WHOIS data. ARIN may also make the collected or individual mappings from address blocks to AS numbers available in other forms, possibly query services, chosen at its own discretion, informed by the community's current needs. ARIN may require agreement to an acceptable use policy for access to the data in these forms. Policy Rationale Origination of prefixes by ASes that have no authority for the origination is a recurring problem in the Internet routing system. A list of authorized prefix originations would be beneficial to operators in * constructing routing filter lists to counter bogus originations, * interacting with customers requesting routing of a prefix, and * diagnosing routing problems. A list of authorized prefix originations is also the necessary first step for any known solution for securing the routing system. Prefix originations can be stored in routing registry RPSL route objects. However, the authority for addresses and for ASes belongs to the RIRs. There is presently no mechanism to translate ARIN's authority for number resources to an IRR. Furthermore, operators have been less than diligent in creating and maintaining route objects. Capturing the prefix origination authorization in number resource registrations with ARIN has two main goals: * benefit from the scrutiny with which ARIN verifies initial requests and authenticates subsequent transactions, and * inherit the operators' self-discipline in completing resource requests and transactions. As an additional benefit, this could take a step toward populating the IRR with data known to be accurate. The intended use of this data means that both query for individual entries and bulk access to a list of the collected entries, without restriction on redistribution, is required. This policy requires that the additional data be provided through the usual whois query service and some bulk access service that has no restrictions. It permits ARIN to provide the bulk access through the existing bulk whois service if the new additional data is not subject to the bulk whois AUP restrictions. The policy does not limit ARIN to providing only those two services (whois query and unrestricted bulk access); other additional services may be developed at ARIN's discretion. It is expected that entries in the list of collected entries will include at a minimum the present NetRange and NetType attributes, with a new attribute, perhaps named OriginatingASList, for the list of permitted originating ASes. This policy will presumably be incorporated into NRPM section 3.4. Timetable for implementation: Within sixty (60) days of approval. From info at arin.net Fri Oct 13 14:31:47 2006 From: info at arin.net (Member Services) Date: Fri, 13 Oct 2006 14:31:47 -0400 Subject: Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria Message-ID: <452FDB93.3090605@arin.net> On 12 October 2006 the ARIN Advisory Council (AC) concluded its review of 'Changes to IPv6 initial allocation criteria' and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2006_7.html All persons in the community are encouraged to discuss Policy Proposal 2006-7 prior to it being presented at the ARIN Public Policy Meeting in the spring of 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria Author: Jordi Palet Martinez Proposal Version: 1 Submission Date: 11/10/2006 Proposal type: delete Policy term: permanent Policy statement: Delete section 6.5.1.1 d. of NRPM Rationale: The existing policy is fine for an existing and known ISP in the ARIN region, but is not considering the case of new ISPs, which may want to start offering IPv6 services. Is artificial to ask them for start with IPv4 services (which typically will do, but not necessarily), wait for weeks/months (?) to be "known", and then come back for the IPv6 allocation request. In addition to that, they need to have a plan for more than 200 /48 assignments. The first question here is that there is room for business with one or just a few IPv6 customers, and it seems irrational not allowing this type of business to be possible, may be even it can be considered against the anti-trust regulations. Second point is regarding the usage of the /48. An ISP may decide to assign a different prefix size, example a cellular operator with probably will use /64. Is important to clarify that the "200" comes from historical reasons when this proposal was jointly developed with RIPE and APNIC, but the situation is that other regions such as LACNIC and AfriNIC already got rid of this requirement, and in both, RIPE and APNIC is under discussion. This may even bring to a possible "untrue" plan to be suggested by an ISP if he needs to get an IPv6 prefix allocated. Regarding the restriction of the usage in 5 years, I think is enough with the criteria indicated in c that the address space is advertised, as there is no ISP interested in getting a prefix which is not being used. Is an operational cost that doesn't make sense if there is not business beyond covering it, never mind if we talk about a few months or a few years. In summary, the proposal will allow new ISPs, ISPs with a reduced number of customers, or ISPs willing to offer only IPv6 services, to immediately access this resource. No financial/liability implications for the community and ARIN are foreseen, on the other way around, it will allow ARIN better fulfilling its mission. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Wed Oct 25 09:34:37 2006 From: info at arin.net (Member Services) Date: Wed, 25 Oct 2006 09:34:37 -0400 Subject: Policy Proposal: Reinstatement of PGP Authentication Method In-Reply-To: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> References: <82A5AA4A-2843-40A0-94F6-80B2D800A65F@pch.net> Message-ID: <453F67ED.3020306@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. This proposal was received within 10 days of the next scheduled meeting of the ARIN Advisory Council; the review period may be extended to the regularly scheduled meeting that occurs after the upcoming meeting. If the AC accepts the proposal or reaches an agreement with the author, then the proposal will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal or can not reach an agreement with the author, then the AC will notify the community of their decision with an explanation; at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Reinstatement of PGP Authentication Method Authors: Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Submission Date: Tuesday, October 24, 2006 Proposal type: New Policy term: Permanent Policy statement: ADDITION TO NRPM 3.5 Authentication Methods ARIN supports three authentication methods for communication with resource recipients. 3.5.1 Mail-From This section intentionally left blank. 3.5.2 PGP ARIN accepts PGP-signed email as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 3.5.3 X.509 This section intentionally left blank. UPDATES TO TEMPLATES ARIN shall include the auth-type field in request templates as necessary to distinguish between cryptographic and mail-from authentication methods. UPDATES TO DOCUMENTATION ARIN shall update documentation as appropriate, to explain the differences between mail-from, PGP, and X.509 authentication methods. KEY USE IN COMMUNICATION: ARIN shall accept PGP-signed communications, validate the signature, compare it to the identity of the authorized POCs for records referenced in the correspondence, and act appropriately based upon the validity or invalidity of the signature. ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail which they originate with their own individual keys. ARIN shall accept PGP-encrypted communications which are encrypted using ARIN's hostmaster public key. ARIN shall not encrypt any outgoing communications, except by explicit mutual prior agreement with the recipient. NON-BINDING RECOMMENDED KEY MANAGEMENT PRACTICES: It is recommended that ARIN utilize normal POC-verification processes as necessary to accommodate users who lose the private key or passphrase associated with the POCs for their crypt-auth protected resources. It is recommended that ARIN exercise reasonable caution in preventing the proliferation of copies of the hostmaster private key and passphrase. It is recommended that ARIN print out a copy of the private key and passphrase, and secure them in a safe-deposit box outside of ARIN's physical premises, which any two ARIN officers might access in the event that the operating copy of the key is lost or compromised. It is recommended that ARIN publish the hostmaster public key on the ARIN web site, in a manner similar to that of the other RIRs: http://lacnic.net/hostmaster-pub-key.txt https://www.ripe.net/rs/pgp/ncc-pgpkey-2006.asc ftp://ftp.apnic.net/pub/zones/PUBLIC_KEY It is recommended that ARIN publish the hostmaster public key by submitting it to common PGP keyservers which, among others, might include: pgp.mit.edu www.pgp.net It is recommended that ARIN attempt to cross-sign the hostmaster PGP keys of the other four RIRs and ICANN. It is recommended that ARIN's hostmaster public key be signed by members of the ARIN board of trustees. Rationale: Globally, PGP is the most commonly used cryptographic authentication method between RIRs and resource recipients who wish to protect their resource registration records against unauthorized modification. The PGP-auth authentication method is supported by RIPE, APNIC, LACNIC, and AfriNIC, and it was historically supported by the InterNIC prior to ARIN's formation. By contrast, current ARIN resource recipients have only two options: "mail-from," which is trivially spoofed and should not be relied upon to protect important database objects, and X.509, which involves a rigorous and lengthy proof-of-identity process and compels use of a compatible MUA, a combination which has dissuaded virtually all of ARIN's constituents. There isn't a lot of work to do here, and certainly nothing tricky. The hostmaster key has existed since InterNIC days, and ARIN staff have verified that the key and passphrase are still known and working fine. This is simple code, which all the other RIRs deployed without a second thought or complaint. If RIPE and APNIC have always done this, the InterNIC did it before ARIN was formed, and LACNIC and AfriNIC took this for granted as a part of their startup process, we see no reason why ARIN should be the only RIR to not offer this most basic of protections to its members. We need to get PGP support reinstated, so that our records can be protected against hijacking and vandalism, and so we won't look like idiots as the only one of the five regions that can't figure this stuff out. Timetable for implementation: Immediate From info at arin.net Wed Oct 25 09:34:48 2006 From: info at arin.net (Member Services) Date: Wed, 25 Oct 2006 09:34:48 -0400 Subject: Policy Proposal: Documentation of the Mail-From Authentication Method In-Reply-To: References: Message-ID: <453F67F8.5050307@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. This proposal was received within 10 days of the next scheduled meeting of the ARIN Advisory Council; the review period may be extended to the regularly scheduled meeting that occurs after the upcoming meeting. If the AC accepts the proposal or reaches an agreement with the author, then the proposal will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal or can not reach an agreement with the author, then the AC will notify the community of their decision with an explanation; at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Documentation of the Mail-From Authentication Method Authors: Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Proposal Version: 1 Submission Date: Tuesday, October 24, 2006 Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 3.5.1 Mail-From This section intentionally left blank. ADDITION TO THE NRPM 3.5.1 Mail-From Mail-From is the default authentication method by which registration records are protected from vandalism. If a registrant fails to designate a more secure method, any subsequent email which bears the sender address of an authorized Point of Contact may be deemed authentic with regard to the registrant's records. Since it is trivial to forge a sender address, Mail-From should not be regarded as secure. Use of Mail-From authentication is not recommended to any registrant who has the means to implement either of the more secure cryptographic authentication methods. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 3.5 to the NRPM. Section 3.5 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the mail-from authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Wed Oct 25 09:35:01 2006 From: info at arin.net (Member Services) Date: Wed, 25 Oct 2006 09:35:01 -0400 Subject: Policy Proposal: Documentation of the X.509 Authentication Method In-Reply-To: References: Message-ID: <453F6805.3010100@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. This proposal was received within 10 days of the next scheduled meeting of the ARIN Advisory Council; the review period may be extended to the regularly scheduled meeting that occurs after the upcoming meeting. If the AC accepts the proposal or reaches an agreement with the author, then the proposal will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal or can not reach an agreement with the author, then the AC will notify the community of their decision with an explanation; at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Documentation of the X.509 Authentication Method Authors: Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Proposal Version: 1 Submission Date: Tuesday, October 24, 2006 Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 3.5.3 X.509 This section intentionally left blank. ADDITION TO THE NRPM 3.5.3 X.509 ARIN accepts X.509-signed transactions as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 3.5 to the NRPM. Section 3.5 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the X.509 authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Wed Oct 25 12:48:24 2006 From: info at arin.net (Member Services) Date: Wed, 25 Oct 2006 12:48:24 -0400 Subject: ARIN XVIII Meeting Report Now Available Message-ID: <453F9558.5010300@arin.net> The ARIN community recently concluded the ARIN XVIII Public Policy and Members Meetings, held in St. Louis, Missouri, 11-13 October 2006. The meeting report includes presentations, summary notes, and transcripts of these meetings, and is now available on the ARIN website at: http://www.arin.net/meetings/minutes/ARIN_XVIII/ The archives of the webcast will be added to the meeting report when they become available. In addition to these files, the page referenced above has links to presentations for the Sunday "Networking with IPv6" workshop and tutorials. We thank all in the community who participated either in person or remotely, and look forward to seeing you all again for ARIN XIX, which will take place 22-25 April 2007. Regards, Member Services American Registry for Internet Numbers (ARIN)