From narten at us.ibm.com Fri Jul 1 00:53:02 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 01 Jul 2011 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201107010453.p614r278011442@rotala.raleigh.ibm.com> Total of 107 messages in the last 7 days. script run at: Fri Jul 1 00:53:02 EDT 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 17.76% | 19 | 17.34% | 153564 | owen at delong.com 9.35% | 10 | 17.54% | 155335 | jcurran at arin.net 14.02% | 15 | 12.85% | 113766 | bill at herrin.us 12.15% | 13 | 10.19% | 90270 | joelja at bogus.com 6.54% | 7 | 4.61% | 40800 | jmaimon at chl.com 5.61% | 6 | 4.25% | 37633 | adurand at juniper.net 4.67% | 5 | 3.85% | 34059 | mysidia at gmail.com 3.74% | 4 | 4.44% | 39313 | alh-ietf at tndh.net 3.74% | 4 | 4.06% | 35932 | mike at nationwideinc.com 2.80% | 3 | 3.41% | 30218 | ipng at 69706e6720323030352d30312d31340a.nosense.org 1.87% | 2 | 2.43% | 21541 | kkargel at polartel.com 1.87% | 2 | 2.17% | 19223 | farmer at umn.edu 1.87% | 2 | 1.37% | 12170 | hannigan at gmail.com 1.87% | 2 | 1.33% | 11780 | matthew at matthew.at 1.87% | 2 | 1.28% | 11336 | bensons at queuefull.net 0.93% | 1 | 1.15% | 10148 | lsawyer at gci.com 0.93% | 1 | 0.98% | 8640 | wesley.george at twcable.com 0.93% | 1 | 0.91% | 8067 | cengel at conxeo.com 0.93% | 1 | 0.84% | 7436 | victor.kuarsingh at gmail.com 0.93% | 1 | 0.80% | 7046 | david.kessens at nsn.com 0.93% | 1 | 0.79% | 6994 | george.herbert at gmail.com 0.93% | 1 | 0.75% | 6660 | scottleibrand at gmail.com 0.93% | 1 | 0.70% | 6186 | narten at us.ibm.com 0.93% | 1 | 0.69% | 6071 | tedm at ipinc.net 0.93% | 1 | 0.66% | 5887 | info at arin.net 0.93% | 1 | 0.63% | 5589 | cgrundemann at gmail.com --------+------+--------+----------+------------------------ 100.00% | 107 |100.00% | 885664 | Total From info at arin.net Fri Jul 1 15:22:22 2011 From: info at arin.net (ARIN) Date: Fri, 01 Jul 2011 15:22:22 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) Message-ID: <4E0E1E6E.9090905@arin.net> ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Shared Space for IPv4 Address Extension (w/IETF considerations) Proposal Originator: William Herrin Proposal Version: 1 Date: 6/30/2011 Proposal type: new Policy term: This policy shall remain in effect until publication of an RFC that implements the expectations for the /10 address block this policy describes. Upon RFC publication, ARIN shall cede the /10 to IANA for use with the RFC and then strike this policy from the NRPM. Policy statement: A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 address extension. This block will not be allocated or assigned to any single organization, but is to be shared by Service Providers for internal use for IPv4 address extension deployments until connected networks fully support IPv6. Examples of such needs include: IPv4 addresses between home gateways and NAT444 translators. ARIN shall advise the IETF of the /10 reserved and shall request that the IETF determine issues associated with using the /10 as described, set appropriate constraints on the use of the block and publish an RFC documenting the block's recommended use. ARIN shall make manpower and other resources available to the IETF as necessary to facilitate such activity. ARIN constituents are strongly discouraged from using the reserved /10 until an RFC is published as there are expected to be technical issues where software makes assumptions about NAT based on the IP address assigned to the machine. Rationale: This policy proposal is substantively identical to ARIN draft policy 2011-5 which achieved consensus and was recommended to the Board of Trustees for adoption in May 2011. The Internet Architecture Board was asked to comment on the draft policy and expressed concern that the IETF may be the appropriate vehicle for assigning addresses to a new use case rather than to a registrant. In order to act on such a proposal, the IETF will require addresses from an RIR. An insufficient supply of such addresses remains available to them from IANA. As the ARIN community wishes the IETF to create a shared ISP space, it must enact policy which provides the necessary addresses. As modified from proposal 2011-5, this proposal allocates the needed block of addresses and then asks the IETF to develop the appropriate technical rules of use. Because the world marches on and Internet Service Providers have an immediate and pressing need to begin their NAT444 and similar deployments, ARIN region users are discouraged but not prohibited from using the reserved /10 while the IETF works through the process. Note that this policy anticipates successful completion of the IETF process and publication of an RFC. It intentionally includes no provision for revoking the reservation should discussion within the IETF stall. Any such revocation will require discussion within the ARIN policy community of the IETF's findings followed by new policy proposals. The first paragraph of this proposal was copied verbatim from draft 2011-5 in the hopes of maintaining the consensus that draft achieved. The remainder of this rationale is also copied verbatim from draft 2011-5: The Internet community is rapidly consuming the remaining supply of unallocated IPv4 addresses. During the transition period to IPv6, it is imperative that Service Providers maintain IPv4 service for devices and networks that are currently incapable of upgrading to IPv6. Consumers must be able to reach the largely IPv4 Internet after exhaustion. Without a means to share addresses, people or organizations who gain Internet access for the first time, or those who switch providers, or move to another area, will be unable to reach the IPv4 Internet. Further, many CPE router devices used to provide residential or small-medium business services have been optimized for IPv4 operation, and typically require replacement in order to fully support the transition to IPv6 (either natively or via one of many transition technologies). In addition, various consumer devices including IP-enabled televisions, gaming consoles, medical and family monitoring devices, etc. are IPv4-only, and cannot be upgraded. While these will eventually be replaced with dual-stack or IPv6 capable devices, this transition will take many years. As these are typically consumer-owned devices, service providers do not have control over the speed of their replacement cycle. However, consumers have an expectation that they will continue to receive IPv4 service, and that such devices will continue to have IPv4 Internet connectivity after the IPv4 pool is exhausted, even if the customer contracts for new service with a new provider. Until such customers replace their Home Gateways and all IPv4-only devices with IPv6-capable devices, Service Providers will be required to continue to offer IPv4 services through the use of an IPv4 address sharing technology such as NAT444. A recent study showed that there is no part of RFC1918 space which would not overlap with some IPv4 gateways, and therefore to prevent address conflicts, new address space is needed. Service providers are currently presented with three options for obtaining sufficient IPv4 address space for NAT444/IPv4 extension deployments: (1) Request allocations under the NRPM; (2) share address space with other providers (this proposal); or (3) use address space allocated to another entity (i.e. .squat.). Of the three options, option 2 (this proposal) is preferable, as it will minimize the number of addresses used for IPv4 extension deployments while preserving the authority of IANA and RIRs. Timetable for implementation: immediate From info at arin.net Fri Jul 1 15:24:03 2011 From: info at arin.net (ARIN) Date: Fri, 01 Jul 2011 15:24:03 -0400 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region Message-ID: <4E0E1ED3.3090209@arin.net> ARIN-prop-155 IPv4 Number Resources for Use Within Region ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 Number Resources for Use Within Region Proposal Originator: Robert Seastrom Proposal Version: 1.0 Date: 2011-07-01 Proposal type: NEW Policy term: PERMANENT Policy statement: Insert the following text in the NRPM: 4.2.1.7 - Presence within the ARIN region These IPv4 addresses are issued solely for use in networks within the ARIN region. Organizations requesting IPv4 addresses from ARIN must provide documentation to demonstrate the addresses will be used to number customers/devices within the ARIN region and must agree to use the addresses solely for that purpose. This requirement shall be binding only on number resources requested after its ratification by the ARIN Board of Trustees. 4.3.7 - Presence within the ARIN region These IPv4 addresses are issued solely for use in networks within the ARIN region. Organizations requesting IPv4 addresses from ARIN must provide documentation to demonstrate the addresses will be used to number customers/devices within the ARIN region and must agree to use the addresses solely for that purpose. This requirement shall be binding only on number resources requested after its ratification by the ARIN Board of Trustees. Rationale: ICANN's ICP-2 document established a framework for _regional_ Internet registries, each to serve a well-defined geographically scoped constituency. The various RIRs will exhaust their free-pools at different times. This creates a situation in which requesting organizations attempt an end-run on ICP-2 and the RIR framework by coming directly to ARIN for space to use outside the ARIN region. In other cases, subsidiaries, sister organizations located within the ARIN region, or global organizations headquartered within the ARIN region have requested space that is ultimately destined for use outside the ARIN region. Failure to address this situation in a timely fashion will grant an unfair advantage to large multinationals who will be able to "shop around" requests for space and hasten RIR free pool runout in the ARIN region. Leaving this loophole unaddressed is incompatible with ARIN's principle of stewardship. This problem is not unique to ARIN. Similar proposals are under consideration in the LACNIC and AfriNIC regions. Timetable for implementation: Immediate From info at arin.net Fri Jul 1 15:29:56 2011 From: info at arin.net (ARIN) Date: Fri, 01 Jul 2011 15:29:56 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) Message-ID: <4E0E2034.4080309@arin.net> ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Shared Space for IPv4 Address Extension (w/IETF considerations) Proposal Originator: William Herrin Proposal Version: 1 Date: 6/30/2011 Proposal type: new Policy term: This policy shall remain in effect until publication of an RFC that implements the expectations for the /10 address block this policy describes. Upon RFC publication, ARIN shall cede the /10 to IANA for use with the RFC and then strike this policy from the NRPM. Policy statement: A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 address extension. This block will not be allocated or assigned to any single organization, but is to be shared by Service Providers for internal use for IPv4 address extension deployments until connected networks fully support IPv6. Examples of such needs include: IPv4 addresses between home gateways and NAT444 translators. ARIN shall advise the IETF of the /10 reserved and shall request that the IETF determine issues associated with using the /10 as described, set appropriate constraints on the use of the block and publish an RFC documenting the block's recommended use. ARIN shall make manpower and other resources available to the IETF as necessary to facilitate such activity. ARIN constituents are strongly discouraged from using the reserved /10 until an RFC is published as there are expected to be technical issues where software makes assumptions about NAT based on the IP address assigned to the machine. Rationale: This policy proposal is substantively identical to ARIN draft policy 2011-5 which achieved consensus and was recommended to the Board of Trustees for adoption in May 2011. The Internet Architecture Board was asked to comment on the draft policy and expressed concern that the IETF may be the appropriate vehicle for assigning addresses to a new use case rather than to a registrant. In order to act on such a proposal, the IETF will require addresses from an RIR. An insufficient supply of such addresses remains available to them from IANA. As the ARIN community wishes the IETF to create a shared ISP space, it must enact policy which provides the necessary addresses. As modified from proposal 2011-5, this proposal allocates the needed block of addresses and then asks the IETF to develop the appropriate technical rules of use. Because the world marches on and Internet Service Providers have an immediate and pressing need to begin their NAT444 and similar deployments, ARIN region users are discouraged but not prohibited from using the reserved /10 while the IETF works through the process. Note that this policy anticipates successful completion of the IETF process and publication of an RFC. It intentionally includes no provision for revoking the reservation should discussion within the IETF stall. Any such revocation will require discussion within the ARIN policy community of the IETF's findings followed by new policy proposals. The first paragraph of this proposal was copied verbatim from draft 2011-5 in the hopes of maintaining the consensus that draft achieved. The remainder of this rationale is also copied verbatim from draft 2011-5: The Internet community is rapidly consuming the remaining supply of unallocated IPv4 addresses. During the transition period to IPv6, it is imperative that Service Providers maintain IPv4 service for devices and networks that are currently incapable of upgrading to IPv6. Consumers must be able to reach the largely IPv4 Internet after exhaustion. Without a means to share addresses, people or organizations who gain Internet access for the first time, or those who switch providers, or move to another area, will be unable to reach the IPv4 Internet. Further, many CPE router devices used to provide residential or small-medium business services have been optimized for IPv4 operation, and typically require replacement in order to fully support the transition to IPv6 (either natively or via one of many transition technologies). In addition, various consumer devices including IP-enabled televisions, gaming consoles, medical and family monitoring devices, etc. are IPv4-only, and cannot be upgraded. While these will eventually be replaced with dual-stack or IPv6 capable devices, this transition will take many years. As these are typically consumer-owned devices, service providers do not have control over the speed of their replacement cycle. However, consumers have an expectation that they will continue to receive IPv4 service, and that such devices will continue to have IPv4 Internet connectivity after the IPv4 pool is exhausted, even if the customer contracts for new service with a new provider. Until such customers replace their Home Gateways and all IPv4-only devices with IPv6-capable devices, Service Providers will be required to continue to offer IPv4 services through the use of an IPv4 address sharing technology such as NAT444. A recent study showed that there is no part of RFC1918 space which would not overlap with some IPv4 gateways, and therefore to prevent address conflicts, new address space is needed. Service providers are currently presented with three options for obtaining sufficient IPv4 address space for NAT444/IPv4 extension deployments: (1) Request allocations under the NRPM; (2) share address space with other providers (this proposal); or (3) use address space allocated to another entity (i.e. .squat.). Of the three options, option 2 (this proposal) is preferable, as it will minimize the number of addresses used for IPv4 extension deployments while preserving the authority of IANA and RIRs. Timetable for implementation: immediate From info at arin.net Fri Jul 1 15:32:34 2011 From: info at arin.net (ARIN) Date: Fri, 01 Jul 2011 15:32:34 -0400 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region Message-ID: <4E0E20D2.70609@arin.net> ARIN-prop-155 IPv4 Number Resources for Use Within Region ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 Number Resources for Use Within Region Proposal Originator: Robert Seastrom Proposal Version: 1.0 Date: 2011-07-01 Proposal type: NEW Policy term: PERMANENT Policy statement: Insert the following text in the NRPM: 4.2.1.7 - Presence within the ARIN region These IPv4 addresses are issued solely for use in networks within the ARIN region. Organizations requesting IPv4 addresses from ARIN must provide documentation to demonstrate the addresses will be used to number customers/devices within the ARIN region and must agree to use the addresses solely for that purpose. This requirement shall be binding only on number resources requested after its ratification by the ARIN Board of Trustees. 4.3.7 - Presence within the ARIN region These IPv4 addresses are issued solely for use in networks within the ARIN region. Organizations requesting IPv4 addresses from ARIN must provide documentation to demonstrate the addresses will be used to number customers/devices within the ARIN region and must agree to use the addresses solely for that purpose. This requirement shall be binding only on number resources requested after its ratification by the ARIN Board of Trustees. Rationale: ICANN's ICP-2 document established a framework for _regional_ Internet registries, each to serve a well-defined geographically scoped constituency. The various RIRs will exhaust their free-pools at different times. This creates a situation in which requesting organizations attempt an end-run on ICP-2 and the RIR framework by coming directly to ARIN for space to use outside the ARIN region. In other cases, subsidiaries, sister organizations located within the ARIN region, or global organizations headquartered within the ARIN region have requested space that is ultimately destined for use outside the ARIN region. Failure to address this situation in a timely fashion will grant an unfair advantage to large multinationals who will be able to "shop around" requests for space and hasten RIR free pool runout in the ARIN region. Leaving this loophole unaddressed is incompatible with ARIN's principle of stewardship. This problem is not unique to ARIN. Similar proposals are under consideration in the LACNIC and AfriNIC regions. Timetable for implementation: Immediate From owen at delong.com Fri Jul 1 17:00:09 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Jul 2011 14:00:09 -0700 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <4E0E1ED3.3090209@arin.net> References: <4E0E1ED3.3090209@arin.net> Message-ID: <51BE88F5-E6E7-44B3-81C0-20E747C914C8@delong.com> I oppose this proposal. There are a number of ARIN-Region-Based ISPs and other organizations that have international networks and prefer to get all of their number resources from one RIR and have been doing so for many years. There is no justification to suddenly discontinue this practice. I am not opposed to the apparent primary intent of this policy which is to prevent registry shopping by organizations not primarily within the ARIN region, but, suddenly blocking the legitimate use of ARIN resources to number global networks would have significant negative impacts on a number of organizations. Owen Full disclosure: I work for an ISP that has allocations from ARIN and from APNIC. The vast majority of our space comes from ARIN and we have operations in the RIPE, ARIN, and APNIC regions as well as numbering customers in the APNIC, AfriNIC, ARIN, RIPE, and LACNIC regions. Some historical customers in APNIC region are numbered from ARIN space prior to our getting space from APNIC. We now use the APNIC space to number our customers in that region. All other regions we are using ARIN space at this time. As such, my employer is one such organization that would be negatively impacted by this policy. On Jul 1, 2011, at 12:24 PM, ARIN wrote: > ARIN-prop-155 IPv4 Number Resources for Use Within Region > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > ## * ## > > Policy Proposal Name: IPv4 Number Resources for Use Within Region > > Proposal Originator: Robert Seastrom > > Proposal Version: 1.0 > > Date: 2011-07-01 > > Proposal type: NEW > > Policy term: PERMANENT > > Policy statement: > > Insert the following text in the NRPM: > > 4.2.1.7 - Presence within the ARIN region > > These IPv4 addresses are issued solely for use in networks within the > ARIN region. Organizations requesting IPv4 addresses from ARIN must > provide documentation to demonstrate the addresses will be used to > number customers/devices within the ARIN region and must agree to use > the addresses solely for that purpose. This requirement shall be > binding only on number resources requested after its ratification by > the ARIN Board of Trustees. > > > 4.3.7 - Presence within the ARIN region > > These IPv4 addresses are issued solely for use in networks within the > ARIN region. Organizations requesting IPv4 addresses from ARIN must > provide documentation to demonstrate the addresses will be used to > number customers/devices within the ARIN region and must agree to use > the addresses solely for that purpose. This requirement shall be > binding only on number resources requested after its ratification by > the ARIN Board of Trustees. > > Rationale: > > ICANN's ICP-2 document established a framework for _regional_ > Internet registries, each to serve a well-defined geographically > scoped constituency. > > The various RIRs will exhaust their free-pools at different times. > This creates a situation in which requesting organizations attempt an > end-run on ICP-2 and the RIR framework by coming directly to ARIN for > space to use outside the ARIN region. In other cases, subsidiaries, > sister organizations located within the ARIN region, or global > organizations headquartered within the ARIN region have requested > space that is ultimately destined for use outside the ARIN region. > > Failure to address this situation in a timely fashion will grant an > unfair advantage to large multinationals who will be able to "shop > around" requests for space and hasten RIR free pool runout in the ARIN region. > > Leaving this loophole unaddressed is incompatible with ARIN's > principle of stewardship. > > This problem is not unique to ARIN. Similar proposals are under > consideration in the LACNIC and AfriNIC regions. > > Timetable for implementation: Immediate > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Fri Jul 1 17:02:04 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Jul 2011 14:02:04 -0700 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <4E0E1E6E.9090905@arin.net> References: <4E0E1E6E.9090905@arin.net> Message-ID: I support this proposal as written. Owen On Jul 1, 2011, at 12:22 PM, ARIN wrote: > > ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Policy Proposal Name: Shared Space for IPv4 Address Extension (w/IETF considerations) > > Proposal Originator: William Herrin > > Proposal Version: 1 > > Date: 6/30/2011 > > Proposal type: new > > Policy term: > > This policy shall remain in effect until publication of an RFC that > implements the expectations for the /10 address block this policy > describes. Upon RFC publication, ARIN shall cede the /10 to IANA > for use with the RFC and then strike this policy from the NRPM. > > Policy statement: > > A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 > address extension. This block will not be allocated or assigned to any > single organization, but is to be shared by Service Providers for > internal use for IPv4 address extension deployments until connected > networks fully support IPv6. Examples of such needs include: IPv4 > addresses between home gateways and NAT444 translators. > > ARIN shall advise the IETF of the /10 reserved and shall request that > the IETF determine issues associated with using the /10 as described, > set appropriate constraints on the use of the block and publish an RFC > documenting the block's recommended use. ARIN shall make manpower and > other resources available to the IETF as necessary to facilitate such > activity. > > ARIN constituents are strongly discouraged from using the reserved /10 > until an RFC is published as there are expected to be technical > issues where software makes assumptions about NAT based on the IP > address assigned to the machine. > > Rationale: > > This policy proposal is substantively identical to ARIN draft policy 2011-5 > which achieved consensus and was recommended to the Board of Trustees for > adoption in May 2011. The Internet Architecture Board was asked to comment > on the draft policy and expressed concern that the IETF may be the > appropriate vehicle for assigning addresses to a new use case rather > than to a registrant. > > In order to act on such a proposal, the IETF will require addresses from > an RIR. An insufficient supply of such addresses remains available to > them from IANA. As the ARIN community wishes the IETF to create a > shared ISP space, it must enact policy which provides the necessary > addresses. > > As modified from proposal 2011-5, this proposal allocates the needed > block of addresses and then asks the IETF to develop the appropriate > technical rules of use. > > Because the world marches on and Internet Service Providers have an > immediate and pressing need to begin their NAT444 and similar deployments, > ARIN region users are discouraged but not prohibited from using the > reserved /10 while the IETF works through the process. > > Note that this policy anticipates successful completion of the IETF process > and publication of an RFC. It intentionally includes no provision for revoking > the reservation should discussion within the IETF stall. Any such revocation > will require discussion within the ARIN policy community of the IETF's > findings followed by new policy proposals. > > The first paragraph of this proposal was copied verbatim from draft 2011-5 > in the hopes of maintaining the consensus that draft achieved. The > remainder of this rationale is also copied verbatim from draft 2011-5: > > The Internet community is rapidly consuming the remaining supply of > unallocated IPv4 addresses. During the transition period to IPv6, it is > imperative that Service Providers maintain IPv4 service for devices and > networks that are currently incapable of upgrading to IPv6. > Consumers must be able to reach the largely IPv4 Internet after > exhaustion. Without a means to share addresses, people or organizations > who gain Internet access for the first time, or those who switch > providers, or move to another area, will be unable to reach the IPv4 > Internet. > > Further, many CPE router devices used to provide residential or > small-medium business services have been optimized for IPv4 operation, > and typically require replacement in order to fully support the > transition to IPv6 (either natively or via one of many transition > technologies). In addition, various consumer devices including > IP-enabled televisions, gaming consoles, medical and family monitoring > devices, etc. are IPv4-only, and cannot be upgraded. While these will > eventually be replaced with dual-stack or IPv6 capable devices, this > transition will take many years. As these are typically consumer-owned > devices, service providers do not have control over the speed of their > replacement cycle. However, consumers have an expectation that they > will continue to receive IPv4 service, and that such devices will > continue to have IPv4 Internet connectivity after the IPv4 pool is > exhausted, even if the customer contracts for new service with a new > provider. > > Until such customers replace their Home Gateways and all IPv4-only > devices with IPv6-capable devices, Service Providers will be required to > continue to offer IPv4 services through the use of an IPv4 address > sharing technology such as NAT444. A recent study showed that there is > no part of RFC1918 space which would not overlap with some IPv4 > gateways, and therefore to prevent address conflicts, new address space > is needed. > > Service providers are currently presented with three options for > obtaining sufficient IPv4 address space for NAT444/IPv4 extension > deployments: (1) Request allocations under the NRPM; (2) share address > space with other providers (this proposal); or (3) use address space > allocated to another entity (i.e. .squat.). Of the three options, > option 2 (this proposal) is preferable, as it will minimize the number > of addresses used for IPv4 extension deployments while preserving the > authority of IANA and RIRs. > > Timetable for implementation: immediate > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From Matthew.Wilder at telus.com Fri Jul 1 18:22:49 2011 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Fri, 1 Jul 2011 16:22:49 -0600 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) Message-ID: I also support this policy as written. Matthew Wilder -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, July 01, 2011 03:06 PM Mountain Standard Time To: ARIN Cc: ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) I support this proposal as written. Owen On Jul 1, 2011, at 12:22 PM, ARIN wrote: > > ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Policy Proposal Name: Shared Space for IPv4 Address Extension (w/IETF considerations) > > Proposal Originator: William Herrin > > Proposal Version: 1 > > Date: 6/30/2011 > > Proposal type: new > > Policy term: > > This policy shall remain in effect until publication of an RFC that > implements the expectations for the /10 address block this policy > describes. Upon RFC publication, ARIN shall cede the /10 to IANA > for use with the RFC and then strike this policy from the NRPM. > > Policy statement: > > A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 > address extension. This block will not be allocated or assigned to any > single organization, but is to be shared by Service Providers for > internal use for IPv4 address extension deployments until connected > networks fully support IPv6. Examples of such needs include: IPv4 > addresses between home gateways and NAT444 translators. > > ARIN shall advise the IETF of the /10 reserved and shall request that > the IETF determine issues associated with using the /10 as described, > set appropriate constraints on the use of the block and publish an RFC > documenting the block's recommended use. ARIN shall make manpower and > other resources available to the IETF as necessary to facilitate such > activity. > > ARIN constituents are strongly discouraged from using the reserved /10 > until an RFC is published as there are expected to be technical > issues where software makes assumptions about NAT based on the IP > address assigned to the machine. > > Rationale: > > This policy proposal is substantively identical to ARIN draft policy 2011-5 > which achieved consensus and was recommended to the Board of Trustees for > adoption in May 2011. The Internet Architecture Board was asked to comment > on the draft policy and expressed concern that the IETF may be the > appropriate vehicle for assigning addresses to a new use case rather > than to a registrant. > > In order to act on such a proposal, the IETF will require addresses from > an RIR. An insufficient supply of such addresses remains available to > them from IANA. As the ARIN community wishes the IETF to create a > shared ISP space, it must enact policy which provides the necessary > addresses. > > As modified from proposal 2011-5, this proposal allocates the needed > block of addresses and then asks the IETF to develop the appropriate > technical rules of use. > > Because the world marches on and Internet Service Providers have an > immediate and pressing need to begin their NAT444 and similar deployments, > ARIN region users are discouraged but not prohibited from using the > reserved /10 while the IETF works through the process. > > Note that this policy anticipates successful completion of the IETF process > and publication of an RFC. It intentionally includes no provision for revoking > the reservation should discussion within the IETF stall. Any such revocation > will require discussion within the ARIN policy community of the IETF's > findings followed by new policy proposals. > > The first paragraph of this proposal was copied verbatim from draft 2011-5 > in the hopes of maintaining the consensus that draft achieved. The > remainder of this rationale is also copied verbatim from draft 2011-5: > > The Internet community is rapidly consuming the remaining supply of > unallocated IPv4 addresses. During the transition period to IPv6, it is > imperative that Service Providers maintain IPv4 service for devices and > networks that are currently incapable of upgrading to IPv6. > Consumers must be able to reach the largely IPv4 Internet after > exhaustion. Without a means to share addresses, people or organizations > who gain Internet access for the first time, or those who switch > providers, or move to another area, will be unable to reach the IPv4 > Internet. > > Further, many CPE router devices used to provide residential or > small-medium business services have been optimized for IPv4 operation, > and typically require replacement in order to fully support the > transition to IPv6 (either natively or via one of many transition > technologies). In addition, various consumer devices including > IP-enabled televisions, gaming consoles, medical and family monitoring > devices, etc. are IPv4-only, and cannot be upgraded. While these will > eventually be replaced with dual-stack or IPv6 capable devices, this > transition will take many years. As these are typically consumer-owned > devices, service providers do not have control over the speed of their > replacement cycle. However, consumers have an expectation that they > will continue to receive IPv4 service, and that such devices will > continue to have IPv4 Internet connectivity after the IPv4 pool is > exhausted, even if the customer contracts for new service with a new > provider. > > Until such customers replace their Home Gateways and all IPv4-only > devices with IPv6-capable devices, Service Providers will be required to > continue to offer IPv4 services through the use of an IPv4 address > sharing technology such as NAT444. A recent study showed that there is > no part of RFC1918 space which would not overlap with some IPv4 > gateways, and therefore to prevent address conflicts, new address space > is needed. > > Service providers are currently presented with three options for > obtaining sufficient IPv4 address space for NAT444/IPv4 extension > deployments: (1) Request allocations under the NRPM; (2) share address > space with other providers (this proposal); or (3) use address space > allocated to another entity (i.e. .squat.). Of the three options, > option 2 (this proposal) is preferable, as it will minimize the number > of addresses used for IPv4 extension deployments while preserving the > authority of IANA and RIRs. > > Timetable for implementation: immediate > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From lsawyer at gci.com Fri Jul 1 18:25:39 2011 From: lsawyer at gci.com (Leif Sawyer) Date: Fri, 1 Jul 2011 14:25:39 -0800 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <4E0E2034.4080309@arin.net> References: <4E0E2034.4080309@arin.net> Message-ID: <18B2C6E38A3A324986B392B2D18ABC51F4895321@fnb1mbx01.gci.com> I support this proposal as writ. > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > Sent: Friday, July 01, 2011 11:30 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 > Address Extension (w/IETF considerations) > > > ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF > considerations) > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may > be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their > deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Policy Proposal Name: Shared Space for IPv4 Address Extension (w/IETF > considerations) > > Proposal Originator: William Herrin > > Proposal Version: 1 > > Date: 6/30/2011 > > Proposal type: new > > Policy term: > > This policy shall remain in effect until publication of an RFC that > implements the expectations for the /10 address block this policy > describes. Upon RFC publication, ARIN shall cede the /10 to IANA > for use with the RFC and then strike this policy from the NRPM. > > Policy statement: > > A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 > address extension. This block will not be allocated or assigned to any > single organization, but is to be shared by Service Providers for > internal use for IPv4 address extension deployments until connected > networks fully support IPv6. Examples of such needs include: IPv4 > addresses between home gateways and NAT444 translators. > > ARIN shall advise the IETF of the /10 reserved and shall request that > the IETF determine issues associated with using the /10 as described, > set appropriate constraints on the use of the block and publish an RFC > documenting the block's recommended use. ARIN shall make manpower and > other resources available to the IETF as necessary to facilitate such > activity. > > ARIN constituents are strongly discouraged from using the reserved /10 > until an RFC is published as there are expected to be technical > issues where software makes assumptions about NAT based on the IP > address assigned to the machine. > > Rationale: > > This policy proposal is substantively identical to ARIN draft > policy 2011-5 > which achieved consensus and was recommended to the Board of > Trustees for > adoption in May 2011. The Internet Architecture Board was > asked to comment > on the draft policy and expressed concern that the IETF may be the > appropriate vehicle for assigning addresses to a new use case rather > than to a registrant. > > In order to act on such a proposal, the IETF will require > addresses from > an RIR. An insufficient supply of such addresses remains available to > them from IANA. As the ARIN community wishes the IETF to create a > shared ISP space, it must enact policy which provides the necessary > addresses. > > As modified from proposal 2011-5, this proposal allocates the needed > block of addresses and then asks the IETF to develop the appropriate > technical rules of use. > > Because the world marches on and Internet Service Providers have an > immediate and pressing need to begin their NAT444 and similar > deployments, > ARIN region users are discouraged but not prohibited from using the > reserved /10 while the IETF works through the process. > > Note that this policy anticipates successful completion of > the IETF process > and publication of an RFC. It intentionally includes no provision for > revoking > the reservation should discussion within the IETF stall. Any such > revocation > will require discussion within the ARIN policy community of the IETF's > findings followed by new policy proposals. > > The first paragraph of this proposal was copied verbatim from > draft 2011-5 > in the hopes of maintaining the consensus that draft achieved. The > remainder of this rationale is also copied verbatim from draft 2011-5: > > The Internet community is rapidly consuming the remaining supply of > unallocated IPv4 addresses. During the transition period to > IPv6, it is > imperative that Service Providers maintain IPv4 service for > devices and > networks that are currently incapable of upgrading to IPv6. > Consumers must be able to reach the largely IPv4 Internet after > exhaustion. Without a means to share addresses, people or > organizations > who gain Internet access for the first time, or those who switch > providers, or move to another area, will be unable to reach the IPv4 > Internet. > > Further, many CPE router devices used to provide residential or > small-medium business services have been optimized for IPv4 operation, > and typically require replacement in order to fully support the > transition to IPv6 (either natively or via one of many transition > technologies). In addition, various consumer devices including > IP-enabled televisions, gaming consoles, medical and family monitoring > devices, etc. are IPv4-only, and cannot be upgraded. While these will > eventually be replaced with dual-stack or IPv6 capable devices, this > transition will take many years. As these are typically > consumer-owned > devices, service providers do not have control over the speed of their > replacement cycle. However, consumers have an expectation that they > will continue to receive IPv4 service, and that such devices will > continue to have IPv4 Internet connectivity after the IPv4 pool is > exhausted, even if the customer contracts for new service with a new > provider. > > Until such customers replace their Home Gateways and all IPv4-only > devices with IPv6-capable devices, Service Providers will be > required to > continue to offer IPv4 services through the use of an IPv4 address > sharing technology such as NAT444. A recent study showed > that there is > no part of RFC1918 space which would not overlap with some IPv4 > gateways, and therefore to prevent address conflicts, new > address space > is needed. > > Service providers are currently presented with three options for > obtaining sufficient IPv4 address space for NAT444/IPv4 extension > deployments: (1) Request allocations under the NRPM; (2) share address > space with other providers (this proposal); or (3) use address space > allocated to another entity (i.e. .squat.). Of the three options, > option 2 (this proposal) is preferable, as it will minimize the number > of addresses used for IPv4 extension deployments while preserving the > authority of IANA and RIRs. > > Timetable for implementation: immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From gary.buhrmaster at gmail.com Fri Jul 1 19:42:33 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 1 Jul 2011 23:42:33 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <4E0E1E6E.9090905@arin.net> References: <4E0E1E6E.9090905@arin.net> Message-ID: On Fri, Jul 1, 2011 at 19:22, ARIN wrote: > > ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF > considerations) I support this proposal as written. From gary.buhrmaster at gmail.com Fri Jul 1 20:01:03 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sat, 2 Jul 2011 00:01:03 +0000 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <4E0E1ED3.3090209@arin.net> References: <4E0E1ED3.3090209@arin.net> Message-ID: On Fri, Jul 1, 2011 at 19:24, ARIN wrote: > ARIN-prop-155 IPv4 Number Resources for Use Within Region I oppose this policy as written. I think it is too extreme to require all addresses be used in any one region. What about customers with remote sites in another region? Network infrastructure addresses? I am sure there are many other cases where to require absolutes like this just would not make any sense, but this policy provides no wiggle room for common sense. I could, perhaps, be convinced to support a modified proposal which indicates the organization requesting the addresses must show the intent to use addresses substantially within the ARIN region (whether that is 33%, 51%, or 98%, is for another discussion). Gary From joelja at bogus.com Fri Jul 1 20:21:21 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 1 Jul 2011 17:21:21 -0700 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <4E0E20D2.70609@arin.net> References: <4E0E20D2.70609@arin.net> Message-ID: <7B73D41D-8BC2-4589-83D4-0E0F0244996E@bogus.com> Oppose, As a north american resource holder with network connectivity which extends beyond the bounds of the ARIN region this policy is applies a condition which would have previously been unworkable and presumably would be (with shrinking minimum allocations) in the future. It imposes topological considerations on newly assigned resources for multinational operations domiciled in the ARIN region, in a way that favors some new entrants or returning resource holders over others. joel On Jul 1, 2011, at 12:32 PM, ARIN wrote: > > ARIN-prop-155 IPv4 Number Resources for Use Within Region > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > ## * ## > > Policy Proposal Name: IPv4 Number Resources for Use Within Region > > Proposal Originator: Robert Seastrom > > Proposal Version: 1.0 > > Date: 2011-07-01 > > Proposal type: NEW > > Policy term: PERMANENT > > Policy statement: > > Insert the following text in the NRPM: > > 4.2.1.7 - Presence within the ARIN region > > These IPv4 addresses are issued solely for use in networks within the > ARIN region. Organizations requesting IPv4 addresses from ARIN must > provide documentation to demonstrate the addresses will be used to > number customers/devices within the ARIN region and must agree to use > the addresses solely for that purpose. This requirement shall be > binding only on number resources requested after its ratification by > the ARIN Board of Trustees. > > > 4.3.7 - Presence within the ARIN region > > These IPv4 addresses are issued solely for use in networks within the > ARIN region. Organizations requesting IPv4 addresses from ARIN must > provide documentation to demonstrate the addresses will be used to > number customers/devices within the ARIN region and must agree to use > the addresses solely for that purpose. This requirement shall be > binding only on number resources requested after its ratification by > the ARIN Board of Trustees. > > Rationale: > > ICANN's ICP-2 document established a framework for _regional_ > Internet registries, each to serve a well-defined geographically > scoped constituency. > > The various RIRs will exhaust their free-pools at different times. > This creates a situation in which requesting organizations attempt an > end-run on ICP-2 and the RIR framework by coming directly to ARIN for > space to use outside the ARIN region. In other cases, subsidiaries, > sister organizations located within the ARIN region, or global > organizations headquartered within the ARIN region have requested > space that is ultimately destined for use outside the ARIN region. > > Failure to address this situation in a timely fashion will grant an > unfair advantage to large multinationals who will be able to "shop > around" requests for space and hasten RIR free pool runout in the ARIN > region. > > Leaving this loophole unaddressed is incompatible with ARIN's > principle of stewardship. > > This problem is not unique to ARIN. Similar proposals are under > consideration in the LACNIC and AfriNIC regions. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From jeffrey.lyon at blacklotus.net Fri Jul 1 20:28:22 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 1 Jul 2011 20:28:22 -0400 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <7B73D41D-8BC2-4589-83D4-0E0F0244996E@bogus.com> References: <4E0E20D2.70609@arin.net> <7B73D41D-8BC2-4589-83D4-0E0F0244996E@bogus.com> Message-ID: I would like to see this rewritten to indicate that the IP space must be used either a) entirely within the ARIN region or b) by an organization doing business in the ARIN region which would allow a global organization to expand internationally with the ARIN issued space. Jeff On Fri, Jul 1, 2011 at 8:21 PM, Joel Jaeggli wrote: > Oppose, > > As a north american resource holder with network connectivity which extends beyond the bounds of the ARIN region this policy is applies a condition which would have previously been unworkable and presumably would be (with shrinking minimum allocations) in the future. It imposes ?topological considerations on newly assigned resources for multinational operations domiciled in the ARIN region, in a way that favors some new entrants or returning resource holders over others. > > joel > > On Jul 1, 2011, at 12:32 PM, ARIN wrote: > >> >> ARIN-prop-155 IPv4 Number Resources for Use Within Region >> >> ARIN received the following policy proposal and is posting it to the >> Public Policy Mailing List (PPML) in accordance with the Policy >> Development Process. >> >> The ARIN Advisory Council (AC) will review the proposal at their next >> regularly scheduled meeting (if the period before the next regularly >> scheduled meeting is less than 10 days, then the period may be extended >> to the subsequent regularly scheduled meeting). The AC will decide how >> to utilize the proposal and announce the decision to the PPML. >> >> The AC invites everyone to comment on the proposal on the PPML, >> particularly their support or non-support and the reasoning >> behind their opinion. Such participation contributes to a thorough >> vetting and provides important guidance to the AC in their deliberations. >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Mailing list subscription information can be found >> at: https://www.arin.net/mailing_lists/ >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> ## * ## >> >> Policy Proposal Name: IPv4 Number Resources for Use Within Region >> >> Proposal Originator: Robert Seastrom >> >> Proposal Version: 1.0 >> >> Date: 2011-07-01 >> >> Proposal type: ?NEW >> >> Policy term: PERMANENT >> >> Policy statement: >> >> Insert the following text in the NRPM: >> >> 4.2.1.7 - Presence within the ARIN region >> >> These IPv4 addresses are issued solely for use in networks within the >> ARIN region. Organizations requesting IPv4 addresses from ARIN must >> provide documentation to demonstrate the addresses will be used to >> number customers/devices within the ARIN region and must agree to use >> the addresses solely for that purpose. ?This requirement shall be >> binding only on number resources requested after its ratification by >> the ARIN Board of Trustees. >> >> >> 4.3.7 - Presence within the ARIN region >> >> These IPv4 addresses are issued solely for use in networks within the >> ARIN region. Organizations requesting IPv4 addresses from ARIN must >> provide documentation to demonstrate the addresses will be used to >> number customers/devices within the ARIN region and must agree to use >> the addresses solely for that purpose. ?This requirement shall be >> binding only on number resources requested after its ratification by >> the ARIN Board of Trustees. >> >> Rationale: >> >> ICANN's ICP-2 document established a framework for _regional_ >> Internet registries, each to serve a well-defined geographically >> scoped constituency. >> >> The various RIRs will exhaust their free-pools at different times. >> This creates a situation in which requesting organizations attempt an >> end-run on ICP-2 and the RIR framework by coming directly to ARIN for >> space to use outside the ARIN region. ?In other cases, subsidiaries, >> sister organizations located within the ARIN region, or global >> organizations headquartered within the ARIN region have requested >> space that is ultimately destined for use outside the ARIN region. >> >> Failure to address this situation in a timely fashion will grant an >> unfair advantage to large multinationals who will be able to "shop >> around" ?requests for space and hasten RIR free pool runout in the ARIN >> region. >> >> Leaving this loophole unaddressed is incompatible with ARIN's >> principle of stewardship. >> >> This problem is not unique to ARIN. ?Similar proposals are under >> consideration in the LACNIC and AfriNIC regions. >> >> Timetable for implementation: ?Immediate >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From matthew at matthew.at Fri Jul 1 21:53:26 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 01 Jul 2011 18:53:26 -0700 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <4E0E2034.4080309@arin.net> References: <4E0E2034.4080309@arin.net> Message-ID: <4E0E7A16.2050008@matthew.at> Support as written. Anything that uses up more of ARIN's free pool in an arbitrary way is good. Matthew Kaufman From matthew at matthew.at Fri Jul 1 21:54:47 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 01 Jul 2011 18:54:47 -0700 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <4E0E20D2.70609@arin.net> References: <4E0E20D2.70609@arin.net> Message-ID: <4E0E7A67.8050105@matthew.at> Oppose. Unenforceable, among other things. If I have 200 new workstations at my development center in India that reach the Internet via an MPLS tunnel back to my firewall in San Jose and I need addresses for them, those addresses are being used where exactly? What if the firewall does NAT? Matthew Kaufman From jcurran at arin.net Sat Jul 2 01:18:58 2011 From: jcurran at arin.net (John Curran) Date: Sat, 2 Jul 2011 05:18:58 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <4E0E2034.4080309@arin.net> References: <4E0E2034.4080309@arin.net> Message-ID: <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> All - Policy proposal ARIN-prop-154 does not result in a materially different Internet number resource management policy from the Draft Policy 2011-5 (which is already within the ARIN Policy Development Process and is before the Board of Trustees having been recommended for adoption by the ARIN AC.) ARIN-prop-154 does propose a procedure for implementation of the policy change and the suggested procedure for implementation will be provided to the ARIN Board of Trustees for their ongoing consideration of Draft Policy 2011-5 (regardless of the disposition of ARIN-prop-154.) As the policy proposal in ARIN-prop-154 overlaps significantly with an existing Draft Policy already in the Policy Development Process and recommended for adoption, it is the staff position that ARIN-prop-154 is outside the scope of the the ARIN Policy Development Process PDP (per "PART ONE- PRINCIPLE, 2. Scope", noted below) and its abandonment will be recommended to the ARIN AC during their initial policy proposal evaluation. The ARIN AC may choose not to abandon the policy proposal and continue work on it, recognizing that any ARIN Board of Trustees outcome with respect to the existing recommended Draft Policy 2011-5 may obviate their development efforts with respect to ARIN-prop-154. FYI, /John John Curran President and CEO ARIN >From - > 2. Scope > ... > ? This version of the ARIN PDP is designed to bring forth clear, technically sound and useful policy; reduce overlapping policy proposals; require both staff and legal assessments; give adequate opportunity for discussion prior to each public policy meeting; and provide a means of review prior to possible adoption. --- > ## * ## > > Policy Proposal Name: Shared Space for IPv4 Address Extension (w/IETF > considerations) > > Proposal Originator: William Herrin > > Proposal Version: 1 > > Date: 6/30/2011 > > Proposal type: new > > Policy term: > > This policy shall remain in effect until publication of an RFC that > implements the expectations for the /10 address block this policy > describes. Upon RFC publication, ARIN shall cede the /10 to IANA > for use with the RFC and then strike this policy from the NRPM. > > Policy statement: > > A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 > address extension. This block will not be allocated or assigned to any > single organization, but is to be shared by Service Providers for > internal use for IPv4 address extension deployments until connected > networks fully support IPv6. Examples of such needs include: IPv4 > addresses between home gateways and NAT444 translators. > > ARIN shall advise the IETF of the /10 reserved and shall request that > the IETF determine issues associated with using the /10 as described, > set appropriate constraints on the use of the block and publish an RFC > documenting the block's recommended use. ARIN shall make manpower and > other resources available to the IETF as necessary to facilitate such > activity. > > ARIN constituents are strongly discouraged from using the reserved /10 > until an RFC is published as there are expected to be technical > issues where software makes assumptions about NAT based on the IP > address assigned to the machine. > > Rationale: > > This policy proposal is substantively identical to ARIN draft policy 2011-5 > which achieved consensus and was recommended to the Board of Trustees for > adoption in May 2011. The Internet Architecture Board was asked to comment > on the draft policy and expressed concern that the IETF may be the > appropriate vehicle for assigning addresses to a new use case rather > than to a registrant. > > In order to act on such a proposal, the IETF will require addresses from > an RIR. An insufficient supply of such addresses remains available to > them from IANA. As the ARIN community wishes the IETF to create a > shared ISP space, it must enact policy which provides the necessary > addresses. > > As modified from proposal 2011-5, this proposal allocates the needed > block of addresses and then asks the IETF to develop the appropriate > technical rules of use. > > Because the world marches on and Internet Service Providers have an > immediate and pressing need to begin their NAT444 and similar deployments, > ARIN region users are discouraged but not prohibited from using the > reserved /10 while the IETF works through the process. > > Note that this policy anticipates successful completion of the IETF process > and publication of an RFC. It intentionally includes no provision for > revoking > the reservation should discussion within the IETF stall. Any such > revocation > will require discussion within the ARIN policy community of the IETF's > findings followed by new policy proposals. > > The first paragraph of this proposal was copied verbatim from draft 2011-5 > in the hopes of maintaining the consensus that draft achieved. The > remainder of this rationale is also copied verbatim from draft 2011-5: > > The Internet community is rapidly consuming the remaining supply of > unallocated IPv4 addresses. During the transition period to IPv6, it is > imperative that Service Providers maintain IPv4 service for devices and > networks that are currently incapable of upgrading to IPv6. > Consumers must be able to reach the largely IPv4 Internet after > exhaustion. Without a means to share addresses, people or organizations > who gain Internet access for the first time, or those who switch > providers, or move to another area, will be unable to reach the IPv4 > Internet. > > Further, many CPE router devices used to provide residential or > small-medium business services have been optimized for IPv4 operation, > and typically require replacement in order to fully support the > transition to IPv6 (either natively or via one of many transition > technologies). In addition, various consumer devices including > IP-enabled televisions, gaming consoles, medical and family monitoring > devices, etc. are IPv4-only, and cannot be upgraded. While these will > eventually be replaced with dual-stack or IPv6 capable devices, this > transition will take many years. As these are typically consumer-owned > devices, service providers do not have control over the speed of their > replacement cycle. However, consumers have an expectation that they > will continue to receive IPv4 service, and that such devices will > continue to have IPv4 Internet connectivity after the IPv4 pool is > exhausted, even if the customer contracts for new service with a new > provider. > > Until such customers replace their Home Gateways and all IPv4-only > devices with IPv6-capable devices, Service Providers will be required to > continue to offer IPv4 services through the use of an IPv4 address > sharing technology such as NAT444. A recent study showed that there is > no part of RFC1918 space which would not overlap with some IPv4 > gateways, and therefore to prevent address conflicts, new address space > is needed. > > Service providers are currently presented with three options for > obtaining sufficient IPv4 address space for NAT444/IPv4 extension > deployments: (1) Request allocations under the NRPM; (2) share address > space with other providers (this proposal); or (3) use address space > allocated to another entity (i.e. .squat.). Of the three options, > option 2 (this proposal) is preferable, as it will minimize the number > of addresses used for IPv4 extension deployments while preserving the > authority of IANA and RIRs. > > Timetable for implementation: immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Sat Jul 2 03:04:08 2011 From: bill at herrin.us (William Herrin) Date: Sat, 2 Jul 2011 03:04:08 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> Message-ID: On Sat, Jul 2, 2011 at 1:18 AM, John Curran wrote: > Policy proposal ARIN-prop-154 does not result in a materially different > Internet number resource management policy from the Draft Policy 2011-5 > (which is already within the ARIN Policy Development Process and is before > the Board of Trustees having been recommended for adoption by the ARIN AC.) > > ARIN-prop-154 does propose a procedure for implementation of the policy > change and the suggested procedure for implementation will be provided to > the ARIN Board of Trustees for their ongoing consideration of Draft Policy > 2011-5 (regardless of the disposition of ARIN-prop-154.) > > As the policy proposal in ARIN-prop-154 overlaps significantly with > an existing Draft Policy already in the Policy Development Process and > recommended for adoption, it is the staff position that ARIN-prop-154 > is outside the scope of the the ARIN Policy Development Process PDP > (per "PART ONE- PRINCIPLE, 2. Scope", noted below) and its abandonment > will be recommended to the ARIN AC during their initial policy proposal > evaluation. John- Respectfully, when quoting part 7 of the PDP's scope section, I think you may have overlooked parts 1 through 6. It starts by stating what's included in policy: "Policies developed through the PDP are community self-regulatory statements that mandate or constrain actions." It goes on to elaborate the specific subset of this which is excluded. For example, "Policies developed through the PDP do not describe a step-by-step process," aka a Procedure. This is why the paragraph describing the policy's duration is not a part of the policy statement. Another is that policies to not define services, such as a whois or web server. Yet another is that policies do not set fees. However, nothing in the PDP or bylaws precludes the policy-level requirement that ARIN solicit activity from another standards body. That would be paragraph 2. And nothing in the PDP excludes a policy-level statement of principles offered as clarification for the policy's users. That would be paragraph 3. And if paragraph 1 duplicates a draft policy before the board, paragraphs 2 and 3 do not. Now, during previous policy proposals, I've been advised that I can't offer a proposal that modifies another proposal not yet adopted. So I can't offer paragraphs 2 and 3 by themselves. I can only offer the entire change from current policy, including the pending paragraph 1 copied from draft 2011-5. You can't have it one way last time and the other way this time. That's called "arbitrary and capricious." So make up your mind -- do I offer policy proposals as the modify current policy understanding that the overlap will be discarded if the other policy is adopted, or do I offer policy proposals as they modify policy and other current proposals? If the board faithfully follows the PDP, it will most likely remand 2011-5 to the AC for further development in light of the IAB's comments. It could attempt to make corrections itself, but it would have to step rather far beyond what achieved consensus to do so. Upon remand, the AC may find it valuable to have some text they can merge in for which discussion and expressions of consensus have already occurred. And if the board elects to abandon 2011-5 in light of the IAB's comments then prop 154 will no longer be duplicative. In short, I respectfully submit that your advice regarding the PDP is in error and should the AC find prop 154 to be of value, it should follow the second course of action: >?The ARIN AC may choose not to abandon the policy proposal > and continue work on it, recognizing that any ARIN Board of Trustees > outcome with respect to the existing recommended Draft Policy 2011-5 > may obviate their development efforts with respect to ARIN-prop-154. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Sat Jul 2 03:16:55 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Jul 2011 00:16:55 -0700 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> Message-ID: <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> Respectfully, John, as things stand at this moment, I disagree. I believe that proposal 154 calls for ARIN to designate and set aside the specific /10. While the board may be intending to do so, it is not clear that draft policy 2011-5 requires that to be done and until the board actually makes such an announcement, proposal 154 remains non-duplicative and relevant as a policy proposal. As such, I would recommend that the AC put 154 on the docket at their next meeting and consider it in scope until such time as the board actually takes and announces action that would obviate the need for 154. If that happens, then, I would support abandoning 154 at that time as it would then be out of scope. Owen On Jul 1, 2011, at 10:18 PM, John Curran wrote: > All - > > Policy proposal ARIN-prop-154 does not result in a materially different > Internet number resource management policy from the Draft Policy 2011-5 > (which is already within the ARIN Policy Development Process and is before > the Board of Trustees having been recommended for adoption by the ARIN AC.) > > ARIN-prop-154 does propose a procedure for implementation of the policy > change and the suggested procedure for implementation will be provided to > the ARIN Board of Trustees for their ongoing consideration of Draft Policy > 2011-5 (regardless of the disposition of ARIN-prop-154.) > > As the policy proposal in ARIN-prop-154 overlaps significantly with > an existing Draft Policy already in the Policy Development Process and > recommended for adoption, it is the staff position that ARIN-prop-154 > is outside the scope of the the ARIN Policy Development Process PDP > (per "PART ONE- PRINCIPLE, 2. Scope", noted below) and its abandonment > will be recommended to the ARIN AC during their initial policy proposal > evaluation. The ARIN AC may choose not to abandon the policy proposal > and continue work on it, recognizing that any ARIN Board of Trustees > outcome with respect to the existing recommended Draft Policy 2011-5 > may obviate their development efforts with respect to ARIN-prop-154. > > FYI, > /John > > John Curran > President and CEO > ARIN > >> From - > >> 2. Scope >> ... >> ? This version of the ARIN PDP is designed to bring forth clear, technically sound and useful policy; reduce overlapping policy proposals; require both staff and legal assessments; give adequate opportunity for discussion prior to each public policy meeting; and provide a means of review prior to possible adoption. > > > --- > >> ## * ## >> >> Policy Proposal Name: Shared Space for IPv4 Address Extension (w/IETF >> considerations) >> >> Proposal Originator: William Herrin >> >> Proposal Version: 1 >> >> Date: 6/30/2011 >> >> Proposal type: new >> >> Policy term: >> >> This policy shall remain in effect until publication of an RFC that >> implements the expectations for the /10 address block this policy >> describes. Upon RFC publication, ARIN shall cede the /10 to IANA >> for use with the RFC and then strike this policy from the NRPM. >> >> Policy statement: >> >> A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 >> address extension. This block will not be allocated or assigned to any >> single organization, but is to be shared by Service Providers for >> internal use for IPv4 address extension deployments until connected >> networks fully support IPv6. Examples of such needs include: IPv4 >> addresses between home gateways and NAT444 translators. >> >> ARIN shall advise the IETF of the /10 reserved and shall request that >> the IETF determine issues associated with using the /10 as described, >> set appropriate constraints on the use of the block and publish an RFC >> documenting the block's recommended use. ARIN shall make manpower and >> other resources available to the IETF as necessary to facilitate such >> activity. >> >> ARIN constituents are strongly discouraged from using the reserved /10 >> until an RFC is published as there are expected to be technical >> issues where software makes assumptions about NAT based on the IP >> address assigned to the machine. >> >> Rationale: >> >> This policy proposal is substantively identical to ARIN draft policy 2011-5 >> which achieved consensus and was recommended to the Board of Trustees for >> adoption in May 2011. The Internet Architecture Board was asked to comment >> on the draft policy and expressed concern that the IETF may be the >> appropriate vehicle for assigning addresses to a new use case rather >> than to a registrant. >> >> In order to act on such a proposal, the IETF will require addresses from >> an RIR. An insufficient supply of such addresses remains available to >> them from IANA. As the ARIN community wishes the IETF to create a >> shared ISP space, it must enact policy which provides the necessary >> addresses. >> >> As modified from proposal 2011-5, this proposal allocates the needed >> block of addresses and then asks the IETF to develop the appropriate >> technical rules of use. >> >> Because the world marches on and Internet Service Providers have an >> immediate and pressing need to begin their NAT444 and similar deployments, >> ARIN region users are discouraged but not prohibited from using the >> reserved /10 while the IETF works through the process. >> >> Note that this policy anticipates successful completion of the IETF process >> and publication of an RFC. It intentionally includes no provision for >> revoking >> the reservation should discussion within the IETF stall. Any such >> revocation >> will require discussion within the ARIN policy community of the IETF's >> findings followed by new policy proposals. >> >> The first paragraph of this proposal was copied verbatim from draft 2011-5 >> in the hopes of maintaining the consensus that draft achieved. The >> remainder of this rationale is also copied verbatim from draft 2011-5: >> >> The Internet community is rapidly consuming the remaining supply of >> unallocated IPv4 addresses. During the transition period to IPv6, it is >> imperative that Service Providers maintain IPv4 service for devices and >> networks that are currently incapable of upgrading to IPv6. >> Consumers must be able to reach the largely IPv4 Internet after >> exhaustion. Without a means to share addresses, people or organizations >> who gain Internet access for the first time, or those who switch >> providers, or move to another area, will be unable to reach the IPv4 >> Internet. >> >> Further, many CPE router devices used to provide residential or >> small-medium business services have been optimized for IPv4 operation, >> and typically require replacement in order to fully support the >> transition to IPv6 (either natively or via one of many transition >> technologies). In addition, various consumer devices including >> IP-enabled televisions, gaming consoles, medical and family monitoring >> devices, etc. are IPv4-only, and cannot be upgraded. While these will >> eventually be replaced with dual-stack or IPv6 capable devices, this >> transition will take many years. As these are typically consumer-owned >> devices, service providers do not have control over the speed of their >> replacement cycle. However, consumers have an expectation that they >> will continue to receive IPv4 service, and that such devices will >> continue to have IPv4 Internet connectivity after the IPv4 pool is >> exhausted, even if the customer contracts for new service with a new >> provider. >> >> Until such customers replace their Home Gateways and all IPv4-only >> devices with IPv6-capable devices, Service Providers will be required to >> continue to offer IPv4 services through the use of an IPv4 address >> sharing technology such as NAT444. A recent study showed that there is >> no part of RFC1918 space which would not overlap with some IPv4 >> gateways, and therefore to prevent address conflicts, new address space >> is needed. >> >> Service providers are currently presented with three options for >> obtaining sufficient IPv4 address space for NAT444/IPv4 extension >> deployments: (1) Request allocations under the NRPM; (2) share address >> space with other providers (this proposal); or (3) use address space >> allocated to another entity (i.e. .squat.). Of the three options, >> option 2 (this proposal) is preferable, as it will minimize the number >> of addresses used for IPv4 extension deployments while preserving the >> authority of IANA and RIRs. >> >> Timetable for implementation: immediate >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Sat Jul 2 04:00:02 2011 From: bill at herrin.us (William Herrin) Date: Sat, 2 Jul 2011 04:00:02 -0400 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <4E0E1ED3.3090209@arin.net> References: <4E0E1ED3.3090209@arin.net> Message-ID: On Fri, Jul 1, 2011 at 3:24 PM, ARIN wrote: > ARIN-prop-155 IPv4 Number Resources for Use Within Region Oppose as written. However, I do think Robert has identified a legitimate problem. It costs less than $5000/year to establish and maintain a US corporation. If I'm a French or Japanese telco, what policy stops me from creating a Delaware ISP subsidiary whose sole existence is acquiring ARIN IP addresses and assigning them for well documented use in my European or Asian operations? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at arin.net Sat Jul 2 04:03:35 2011 From: jcurran at arin.net (John Curran) Date: Sat, 2 Jul 2011 08:03:35 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> Message-ID: <542727D7-A68D-4BDB-9D9B-3262642545BD@arin.net> On Jul 2, 2011, at 9:04 AM, William Herrin wrote: > Respectfully, when quoting part 7 of the PDP's scope section, I think > you may have overlooked parts 1 through 6. It starts by stating what's > included in policy: "Policies developed through the PDP are community > self-regulatory statements that mandate or constrain actions." It goes > on to elaborate the specific subset of this which is excluded. "The ARIN PDP is the process by which all policies governing the management of Internet number resources in the ARIN region are developed by and for the ARIN community. " and "Policies developed through the PDP do not describe a step-by-step process. Such a process is a called a procedure." and "Internet number resource policies are distinctly separate from ARIN general business practices and procedures. ARIN's general business practices (including fees) and procedures are not within the purview of the Policy Development Process" > However, nothing in the PDP or bylaws precludes the policy-level > requirement that ARIN solicit activity from another standards body. You wish ARIN to reserve a /10 block, then advise the IETF of the block, and then work with the IETF to determine appropriate constraints on the use of the block, and then publish an RFC with the results. This appears to me to be an implementation procedure, not a policy for management of Internet number resources. > You can't have it one way last time and the other way this time. > That's called "arbitrary and capricious." So make up your mind -- do I > offer policy proposals as the modify current policy understanding that > the overlap will be discarded if the other policy is adopted, or do I > offer policy proposals as they modify policy and other current > proposals? You would work with the AC to modify the current Draft Policy accordingly. However, in this particular case, the Draft Policy is no longer with the ARIN AC, it is with the ARIN Board. > If the board faithfully follows the PDP, it will most likely remand > 2011-5 to the AC for further development in light of the IAB's > comments. It easily could do that, in which case the Draft Policy could be changed to more completely explain how the /10 address block should be managed. Instructions to ARIN to implement particular actions not pertaining to the management of Internet number resources are not Internet number resource policy, particularly when the proposal contains instructions on how to interact with another organization which is already covered by existing agreements. It is up to the ARIN Board of Trustees to provide guidance in such matters. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Sat Jul 2 04:04:33 2011 From: jcurran at arin.net (John Curran) Date: Sat, 2 Jul 2011 08:04:33 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> Message-ID: <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> On Jul 2, 2011, at 9:16 AM, Owen DeLong wrote: > Respectfully, John, as things stand at this moment, I disagree. I believe that > proposal 154 calls for ARIN to designate and set aside the specific /10. > While the board may be intending to do so, it is not clear that draft policy > 2011-5 requires that to be done and until the board actually makes such an > announcement, proposal 154 remains non-duplicative and relevant as > a policy proposal. Owen - Upon adoption, Draft Policy 2011-5 requires that a contiguous /10 IPv4 block be reserved for this purpose. If adopted, ARIN-prop-154 would also require that a contiguous /10 IPv4 block be reserved for this purpose. If 2011-5 hadn't been recommended to the ARIN Board of Trustees, then I could see the ARIN AC accepting ARIN-prop-154 on the docket and merging it with the draft policy. (I would at that time advise against language not germane to Internet number resource management of the address block, but that's another issue) As it is, with 2011-5 recommended for adoption, the ARIN AC has given the question to the ARIN Board of Trustees. Since the question also deals with issues such as how we respect existing relationships with other organizations while still meeting the needs of the community, it is actually quite appropriate that the ARIN Board deliberate on the matter. > As such, I would recommend that the AC put 154 on the docket at their > next meeting and consider it in scope until such time as the board actually > takes and announces action that would obviate the need for 154. If that > happens, then, I would support abandoning 154 at that time as it would > then be out of scope. You are free to recommend any course of action as you see fit. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Sat Jul 2 05:13:00 2011 From: bill at herrin.us (William Herrin) Date: Sat, 2 Jul 2011 05:13:00 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <542727D7-A68D-4BDB-9D9B-3262642545BD@arin.net> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <542727D7-A68D-4BDB-9D9B-3262642545BD@arin.net> Message-ID: On Sat, Jul 2, 2011 at 4:03 AM, John Curran wrote: > On Jul 2, 2011, at 9:04 AM, William Herrin wrote: >> However, nothing in the PDP or bylaws precludes the policy-level >> requirement that ARIN solicit activity from another standards body. > > You wish ARIN to reserve a /10 block, then advise the IETF of the block, > and then work with the IETF to determine appropriate constraints on the > use of the block, and then publish an RFC with the results. > > This appears to me to be an implementation procedure, not a policy for > management of Internet number resources. John, That's not actually what paragraph 2 says. It says two separate things. First: "ARIN shall advise the IETF of the /10 reserved and shall request that the IETF determine issues associated with using the /10 as described, set appropriate constraints on the use of the block and publish an RFC documenting the block's recommended use." This would mean the same thing if I rewrote it as, "ARIN shall ask the IETF to create an RFC." I used more words to make the request clearer but it means the same thing. The word "then" doesn't appear in my text and isn't meant to be implied by it. A procedure is a series of steps while a policy is a set of parameters for creating procedures. This isn't a series of anything. It's one thing. The IETF makes an RFC. They get to turn that into steps and they know how to do that. The second thing paragraph 2 says is: "ARIN shall make manpower and other resources available to the IETF as necessary to facilitate such activity." This is an authorization to provide resources to the IETF should the IETF need them to fulfill the request to make an RFC. It's not a step in a procedure, it's an authorization to create procedures. A policy by any other name. >> You can't have it one way last time and the other way this time. >> That's called "arbitrary and capricious." So make up your mind -- do I >> offer policy proposals as the modify current policy understanding that >> the overlap will be discarded if the other policy is adopted, or do I >> offer policy proposals as they modify policy and other current >> proposals? > > You would work with the AC to modify the current Draft Policy accordingly. And the procedure for doing that is what, exactly? How about drafting a proposal and letting the AC merge in whatever parts it likes? Does that sound like it might be a legitimate procedure for "working with the AC to modify a draft?" > Instructions to ARIN to implement particular actions not pertaining to > the management of Internet number resources are not Internet number resource > policy, I would say that RFC1918 pertains to the management of Internet number resources. Wouldn't you? So how exactly would asking the IETF to create an RFC governing a new shared space fail to pertain to the management of Internet number resources? > particularly when the proposal contains instructions on how to > interact with another organization which is already covered by existing > agreements. Although I don't believe anything in 154 violates any agreements that ARIN has with anybody else, I note that while breaches of law, bylaws and articles of incorporation are called out as excluded from policy proposals, incompatibility with third-party Memorandums of Understanding is not. Perhaps this was an oversight, but until the PDP is changed to say different I choose to see it as wisdom: changes in policy should compel a renegotiation of MoU's where appropriate rather than a succession of behind-the-scenes MoU's boxing ARIN in until address policy is no longer bottom-up. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ppml at rs.seastrom.com Sat Jul 2 11:06:05 2011 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Sat, 02 Jul 2011 11:06:05 -0400 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: (William Herrin's message of "Sat, 2 Jul 2011 04:00:02 -0400") References: <4E0E1ED3.3090209@arin.net> Message-ID: <86y60g7mea.fsf@seastrom.com> William Herrin writes: > On Fri, Jul 1, 2011 at 3:24 PM, ARIN wrote: >> ARIN-prop-155 IPv4 Number Resources for Use Within Region > > Oppose as written. I wrote this proposal as a starting point, and expected plenty of spirited discussion surrounding it. Didn't expect that it would be quite so overwhelmingly "oppose", but those are the breaks. Unfortunately there are no easy answers to a lot of the concerns that folks have raised as reasons for opposing it. It would be extremely easy to go down the rat-hole of trying to dictate operational constraints by making the policy statement 4x as large, and what would happen is that ultimately some creative person would figure out a loophole and all of our efforts would be for naught until the next policy cycle, at which point we'd probably be overtaken by events. The Board doesn't like such policy proposals and will surely remand them for further discussion, at which point we end up kind of hosed because of the aforementioned cycle. I believe that we ought to have a policy to address the situation you elucidate below. That's why I wrote this proposal. Sussing out where the community wants to take this (or even if collectively we want to ignore the rising tide of opportunities for abuse and just be fatalistic about v4 exhaustion) is part of the whole point of the PDP. Discussion and modification encouraged. > However, I do think Robert has identified a legitimate problem. As much as I would like to take credit for original thought, word on the street is that others have already "identified" it. :-( > It costs less than $5000/year to establish and maintain a US > corporation. It can be done for an order of magnitude less. > If I'm a French or Japanese telco, what policy stops me from creating > a Delaware ISP subsidiary whose sole existence is acquiring ARIN IP > addresses and assigning them for well documented use in my European or > Asian operations? You tell me. ;-) cheers, -r From bill at herrin.us Sat Jul 2 12:54:20 2011 From: bill at herrin.us (William Herrin) Date: Sat, 2 Jul 2011 12:54:20 -0400 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <86y60g7mea.fsf@seastrom.com> References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> Message-ID: On Sat, Jul 2, 2011 at 11:06 AM, Robert E. Seastrom wrote: > William Herrin writes: >> It costs less than $5000/year to establish and maintain a US >> corporation. > > It can be done for an order of magnitude less. Hi Robert, Not really. If you're dotting the i's and crossing the t's there are going to be federal, state and local filings to stay on top of as well as state and local licensing fees. You'll need a local lawyer to handle all of this for you and he charges by the hour. He'll need an accountant to prepare and file the nominal taxes. You're also going to need a local mail drop that forwards received mail to you, preferably not an obvious PO box number. You'll need a vonage phone with a local number. You'll need someone to host an email forwarding service based in-region. And you'll need a domain name and web site describing a generic network consulting service with businessy art so that your address application doesn't throw any red flags. When all is said and done, it takes several thousand dollars a year to create and maintain the shell company. >> If I'm a French or Japanese telco, what policy stops me from creating >> a Delaware ISP subsidiary whose sole existence is acquiring ARIN IP >> addresses and assigning them for well documented use in my European or >> Asian operations? > > You tell me. ?;-) No policy that I'm aware of. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Sat Jul 2 13:17:10 2011 From: bill at herrin.us (William Herrin) Date: Sat, 2 Jul 2011 13:17:10 -0400 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> Message-ID: On Sat, Jul 2, 2011 at 11:06 AM, Robert E. Seastrom wrote: > Unfortunately there are no easy answers to a lot of the concerns that > folks have raised as reasons for opposing it. Hi Robert, Perhaps something along the lines of "Organizations holding ARIN-region IPv4 addresses shall employ IPv4 addresses within the ARIN region equivalent to at least 75% of the ARIN-region address holding. Failure to do so is deemed region-shopping fraud." This way you don't have to be super careful about which addresses you put where and you can use ARIN IPs in your minor overseas operations without getting in to trouble. But if you're really an out-region entity with a minor in-region presence, you don't get to go to ARIN for more addresses than your in-region presence justifies. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Sat Jul 2 13:19:59 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 2 Jul 2011 12:19:59 -0500 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: References: <4E0E1ED3.3090209@arin.net> Message-ID: On Sat, Jul 2, 2011 at 3:00 AM, William Herrin wrote: > On Fri, Jul 1, 2011 at 3:24 PM, ARIN wrote: >> ARIN-prop-155 IPv4 Number Resources for Use Within Region > > Oppose as written. > > However, I do think Robert has identified a legitimate problem. It > costs less than $5000/year to establish and maintain a US corporation. I also oppose as written and agree there is a legitimate problem... I will suggest something less strict.... eg '' 4.2.1.7 - Presence within the ARIN region These IPv4 addresses are allowed to be issued or transferred solely to organizations that intend to allocate/assign all requested resources to networks/hosts within the ARIN region, or that receive an AS number from ARIN for use with networks/sites connected within the ARIN region. Organizations must provide ARIN with documentation and proper technical justification showing which addresses are assigned to any host or network outside the ARIN region, and maintain this with the documentation of IPv4 address utilization. Exhaustion of IPv4 address space in other regions is not a valid technical justification, and no organization is eligible to be issued or transferred resources, if the total utilization of all ARIN assigned resources for customers/hosts within the ARIN region will be 5% or less. 5. ... In order to be assigned an AS Number, each requesting organization must provide ARIN with verification that it has one of the following: 1. A unique routing policy (its policy differs from its border gateway peers), and at least two of its border gateway devices are physically located in the ARIN region. 2. A multihomed site located in the ARIN region. ... '' -- -J From owen at delong.com Sat Jul 2 17:29:28 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Jul 2011 14:29:28 -0700 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> Message-ID: <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> On Jul 2, 2011, at 1:04 AM, John Curran wrote: > On Jul 2, 2011, at 9:16 AM, Owen DeLong wrote: > >> Respectfully, John, as things stand at this moment, I disagree. I believe that >> proposal 154 calls for ARIN to designate and set aside the specific /10. >> While the board may be intending to do so, it is not clear that draft policy >> 2011-5 requires that to be done and until the board actually makes such an >> announcement, proposal 154 remains non-duplicative and relevant as >> a policy proposal. > > Owen - > > Upon adoption, Draft Policy 2011-5 requires that a contiguous /10 IPv4 > block be reserved for this purpose. > Since the board has not yet ratified and I haven't received any indication that would cause me to believe that the board will ratify 2011-5 in the absence of IAB approval to do so. > If adopted, ARIN-prop-154 would also require that a contiguous /10 IPv4 > block be reserved for this purpose. > But 154 requires a set-aside of the space regardless of whether the IAB approves using it for that purpose or not. It provides for the public to know what block was set aside, though ARIN is instructed to discourage its use prior to IAB/IESG/IETF approval. > If 2011-5 hadn't been recommended to the ARIN Board of Trustees, then I > could see the ARIN AC accepting ARIN-prop-154 on the docket and merging > it with the draft policy. (I would at that time advise against language > not germane to Internet number resource management of the address block, > but that's another issue) > Since you bring it up, care to specify which language you consider not germane to number resource policy? > As it is, with 2011-5 recommended for adoption, the ARIN AC has given the > question to the ARIN Board of Trustees. Since the question also deals > with issues such as how we respect existing relationships with other > organizations while still meeting the needs of the community, it is > actually quite appropriate that the ARIN Board deliberate on the matter. > I believe that proposal 154 addresses some of those issues in a more direct and head-on manner and if it receives community consensus (there does appear to be strong support so far), that would send a rather clear message to the board about the desires of the community. I agree that it is appropriate for the board to deliberate the manner. I also feel that it is appropriate for the community to take further action to express their desires to the board and to insure that options are not overtaken by events while the board engages in said deliberation. >> As such, I would recommend that the AC put 154 on the docket at their >> next meeting and consider it in scope until such time as the board actually >> takes and announces action that would obviate the need for 154. If that >> happens, then, I would support abandoning 154 at that time as it would >> then be out of scope. > > You are free to recommend any course of action as you see fit. > Yep... I was aware of that, but, thanks for the confirmation. Owen From owen at delong.com Sat Jul 2 17:43:49 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Jul 2011 14:43:49 -0700 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> Message-ID: <93FF1FD8-53BF-4AD8-97D9-5C5E7E732764@delong.com> On Jul 2, 2011, at 10:17 AM, William Herrin wrote: > On Sat, Jul 2, 2011 at 11:06 AM, Robert E. Seastrom > wrote: >> Unfortunately there are no easy answers to a lot of the concerns that >> folks have raised as reasons for opposing it. > > Hi Robert, > > Perhaps something along the lines of "Organizations holding > ARIN-region IPv4 addresses shall employ IPv4 addresses within the ARIN > region equivalent to at least 75% of the ARIN-region address holding. > Failure to do so is deemed region-shopping fraud." > I'm not 100% sure that many existing and perfectly legitimate providers would actually meet that test. There are 5 regions. Not wanting to deal with more than one of them could lead to a provider having approximately 20% in each region without "region shopping". Perhaps instead of requiring a flat 75%, require that "Organizations holding ARIN-region IPv4 addressses shall employ IPv4 addresses within the ARIN region greater than or equal to their ARIN resource holdings deployed in any single other region." > This way you don't have to be super careful about which addresses you > put where and you can use ARIN IPs in your minor overseas operations > without getting in to trouble. But if you're really an out-region > entity with a minor in-region presence, you don't get to go to ARIN > for more addresses than your in-region presence justifies. > What if you're a global entity that has large networks in several regions? Owen From mysidia at gmail.com Sat Jul 2 21:28:20 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 2 Jul 2011 20:28:20 -0500 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <93FF1FD8-53BF-4AD8-97D9-5C5E7E732764@delong.com> References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <93FF1FD8-53BF-4AD8-97D9-5C5E7E732764@delong.com> Message-ID: On Sat, Jul 2, 2011 at 4:43 PM, Owen DeLong wrote: > I'm not 100% sure that many existing and perfectly legitimate providers would > actually meet that test. There are 5 regions. Not wanting to deal with more than > one of them could lead to a provider having approximately 20% in each region > without "region shopping". Perhaps then, the requirement could be that "20% or more of each allocation or transfer requested must be for assignment within the ARIN region. And an additional special utilization criterion must be met, considering only hosts in the ARIN region and resources allocated for use in the ARIN region, in addition to the global utilization criterion." It is not as if the new allocation will be contiguous with a previous one. Unless the new allocation request is split across regions, there is not a technical network-related reason to meet that request using the same RIR that allocated other networks. ARIN should not necessarily support global organizations' desire to deal with only one RIR in every circumstance, just because they might consider it more expedient. If an org needs a new /16, and every single host in that allocation is going to be in Europe, then they should be compelled to obtain the allocation from RIPE, the proper relevant region for that network. Regardless of whether they have other networks in a different region (or not) > Perhaps instead of requiring a flat 75%, require that "Organizations holding > ARIN-region IPv4 addressses shall employ IPv4 addresses within the ARIN > region greater than or equal to their ARIN resource holdings deployed in any > single other region." > -- -JH From jcurran at arin.net Sun Jul 3 06:20:41 2011 From: jcurran at arin.net (John Curran) Date: Sun, 3 Jul 2011 10:20:41 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> Message-ID: <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> On Jul 2, 2011, at 11:29 PM, Owen DeLong wrote: > But 154 requires a set-aside of the space regardless of whether the IAB > approves using it for that purpose or not. It provides for the public to know > what block was set aside, though ARIN is instructed to discourage its use > prior to IAB/IESG/IETF approval. Owen - ARIN already consulted with the IAB precisely on the point of making such an allocation as described in Draft Policy 2011-5 and received the response which I already posted to this list (to the effect that the IAB believes that the adoption of the policy by ARIN and subsequent allocation would be in conflict with the provisions in RFC2860) That response will be provided to the ARIN Board (which took Draft Policy 2011-5 under advisement) to determine the best path forward, which could still have ARIN reserving space for this purpose or even making the /10 allocation while the matter in still being discussed within the IETF. That is up to the Board to decide based on their consideration of the IAB response, as it is not a matter of policy but instead is matter of ARIN's agreements and relation to other Internet bodies. If ARIN-prop-154 were to be recommended for adoption by the Board, it also would be sent to the Board with note to the effect that that ARIN staff recommends consulting with the IAB prior implementation of this draft policy. Since ARIN works are part of the Internet Registry system in cooperation with the IANA, and there is an MOU between ICANN and IAB which delineates the appropriate roles, any recommended draft policy that runs contrary to that agreement will be sent to the Board with such a recommendation to consult with the IAB prior to implementation. > Since you bring it up, care to specify which language you consider not > germane to number resource policy? Number reosource policy does not specify ARIN's relationships with other parties; the specific language in question includes: "ARIN shall advise the IETF of the /10 reserved and shall request that the IETF determine issues associated with using the /10 as described, set appropriate constraints on the use of the block and publish an RFC documenting the block's recommended use. ARIN shall make manpower and other resources available to the IETF as necessary to facilitate such activity." Whether an ARIN policy even should direct the IETF in such a manner, particularly after receiving differing advice from the IAB, is not a question of number resource policy. > I believe that proposal 154 addresses some of those issues in a more direct > and head-on manner and if it receives community consensus (there does > appear to be strong support so far), that would send a rather clear message > to the board about the desires of the community. I'm certain that the Board is well-aware that the community desires this reservation. The community also has to realize that the development of the Internet Protocol, including the Internet Protocol address space, is subject to the technical oversight of the IETF (that is indeed the purpose of the RFC 2860 agreement.) If the community doesn't feel that there is any technical issue with this reservation, then folks should definitely engage with the IETF to make plain why this is the case. > I agree that it is appropriate for the board to deliberate the manner. I also feel > that it is appropriate for the community to take further action to express their > desires to the board and to insure that options are not overtaken by events > while the board engages in said deliberation. Please elaborate on this point. Are you concerned that there will not be a /10 block available for this purpose by the time the ARIN Board considers the IAB response? Thanks, /John John Curran President and CEO ARIN From ppml at rs.seastrom.com Sun Jul 3 10:19:12 2011 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Sun, 03 Jul 2011 10:19:12 -0400 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: (William Herrin's message of "Sat, 2 Jul 2011 12:54:20 -0400") References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> Message-ID: <86oc1ba1lr.fsf@seastrom.com> William Herrin writes: > On Sat, Jul 2, 2011 at 11:06 AM, Robert E. Seastrom > wrote: >> William Herrin writes: >>> It costs less than $5000/year to establish and maintain a US >>> corporation. >> >> It can be done for an order of magnitude less. > > Hi Robert, > > Not really. > > If you're dotting the i's and crossing the t's there are going to be > federal, state and local filings to stay on top of as well as state > and local licensing fees. You'll need a local lawyer to handle all of > this for you and he charges by the hour. He'll need an accountant to > prepare and file the nominal taxes. You're also going to need a local > mail drop that forwards received mail to you, preferably not an > obvious PO box number. You'll need a vonage phone with a local number. > You'll need someone to host an email forwarding service based > in-region. And you'll need a domain name and web site describing a > generic network consulting service with businessy art so that your > address application doesn't throw any red flags. > > When all is said and done, it takes several thousand dollars a year to > create and maintain the shell company. That's a good point; I was thinking solely of the corporate maintenance aspects of the 501(c)3 for which I'm treasurer. Our phone lines don't get counted since we need them anyway, our PO box isn't factored in since we need it anyway... we're not trying to create an illusion here, it's just What We Do. Even if you factor in all those costs of completing the illusion, it's chump change for someone who needs the addresses though. >>> If I'm a French or Japanese telco, what policy stops me from creating >>> a Delaware ISP subsidiary whose sole existence is acquiring ARIN IP >>> addresses and assigning them for well documented use in my European or >>> Asian operations? >> >> You tell me. ?;-) > > No policy that I'm aware of. -r From jmaimon at chl.com Sun Jul 3 12:02:37 2011 From: jmaimon at chl.com (Joe Maimon) Date: Sun, 03 Jul 2011 12:02:37 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <4E0E2034.4080309@arin.net> References: <4E0E2034.4080309@arin.net> Message-ID: <4E10929D.3070008@chl.com> ARIN wrote: > > ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF > considerations) > > A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 > address extension. This block will not be allocated or assigned to any > single organization, but is to be shared by Service Providers for > internal use for IPv4 address extension deployments until connected > networks fully support IPv6. Examples of such needs include: IPv4 > addresses between home gateways and NAT444 translators. Duck rules. An allocation in all but name. I do not support as written. If the concern is that by the time this policy has a green light for implementation there wont be available space, I will point out that a solution to this problem was already attempted, http://lists.arin.net/pipermail/arin-ppml/2010-April/017410.html I urge any reservation proposal to be vanilla in similar vein. Joe From mysidia at gmail.com Sun Jul 3 12:27:50 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 3 Jul 2011 11:27:50 -0500 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <4E0E1E6E.9090905@arin.net> References: <4E0E1E6E.9090905@arin.net> Message-ID: On Fri, Jul 1, 2011 at 2:22 PM, ARIN wrote: > > ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF > considerations) > I support PROP 154 as written and in preference over 2011-05. -- -JH From bill at herrin.us Sun Jul 3 12:58:22 2011 From: bill at herrin.us (William Herrin) Date: Sun, 3 Jul 2011 12:58:22 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> Message-ID: On Sun, Jul 3, 2011 at 6:20 AM, John Curran wrote: > ?ARIN already consulted with the IAB precisely on the point of making such > ?an allocation as described in Draft Policy 2011-5 and received the response > ?which I already posted to this list (to the effect that the IAB believes > ?that the adoption of the policy by ARIN and subsequent allocation would be > ?in conflict with the provisions in RFC2860) > > ?That is up to the Board to decide based on their consideration of the > ?IAB response, as it is not a matter of policy but instead is matter of > ?ARIN's agreements and relation to other Internet bodies. John, In the PDP which the Board created and approved, the Board did not exclude from policy the direction they are asked to take with respect to relations with other Internet bodies. Quite the contrary, we talk about it all the time in things like draft 2011-1. You can repeat your claim all you want but it isn't supported. The Board may ultimately decide that 154 is bad policy, even if the AC recommends it. It's their job to be that final filter. But you are mistaken to think that things which touch on ARIN's relationship with other Internet bodies are not policy or that they should not be debated in this forum. > ?I'm certain that the Board is well-aware that the community desires this > ?reservation. ?The community also has to realize that the development of > ?the Internet Protocol, including the Internet Protocol address space, > ?is subject to the technical oversight of the IETF (that is indeed the > ?purpose of the RFC 2860 agreement.) ?If the community doesn't feel that > ?there is any technical issue with this reservation, then folks should > ?definitely engage with the IETF to make plain why this is the case. With the benefit of the IAB's comments, and the benefit of comments from Joel and Tony among others, it seems obvious to me that the IETF MUST be involved with technical oversight of the function 2011-5 proposes. If there is someone to whom that doesn't seem obvious, let them speak up. But that isn't the end of the story; it's only the beginning. For one thing, the addresses have to come from somewhere and ARIN is the reasonable source. Whether ARIN should be that source is a matter of policy. For another, this industry has a long history of pushing technology out there as it becomes needed and then bringing it into compliance once it has been properly standardized. Kflex before v92. Cisco POE before 802.3af. Prestandard 802.11n. And for sure 2011-5 is needed and needed yesterday. Whether we follow that industry tradition in this matter is not a question of law or business practice, it's a question of policy. It is entirely appropriate that this forum seek consensus and advise the board as to what posture we want them to adopt. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Sun Jul 3 14:20:46 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 3 Jul 2011 13:20:46 -0500 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> Message-ID: On Sat, Jul 2, 2011 at 12:18 AM, John Curran wrote: > Policy proposal ARIN-prop-154 does not result in a materially different > Internet number resource management policy from the Draft Policy 2011-5 > (which is already within the ARIN Policy Development Process and is before > the Board of Trustees having been recommended for adoption by the ARIN AC.) Prop 154 does result in a materially different policy; prop 154 requires ARIN cede management of the reserved /10, if an RFC is published. 2011-05 does not allow ARIN to do that. 154 requires use of address space to be discouraged until the IETF can provide technical assessment. Even if 2011-05 is accepted, there will still be some merit to considering PROP 154 as a policy revising 2011-05. > ARIN-prop-154 does propose a procedure for implementation of the policy > change and the suggested procedure for implementation will be provided to > the ARIN Board of Trustees for their ongoing consideration of Draft Policy > 2011-5 (regardless of the disposition of ARIN-prop-154.) I don't see an implementation procedure in PROP 154. I see requirements that the implementation procedure must meet, and an authorization to work with the IETF on specific items. > As the policy proposal in ARIN-prop-154 overlaps significantly with > an existing Draft Policy already in the Policy Development Process and > recommended for adoption, it is the staff position that ARIN-prop-154 > is outside the scope of the the ARIN Policy Development Process PDP I do not agree with the stated Staff position on 154, and I strongly disagree that 154 should be abandoned by the AC on the basis of scope. -- -JH From bill at herrin.us Sun Jul 3 18:26:41 2011 From: bill at herrin.us (William Herrin) Date: Sun, 3 Jul 2011 18:26:41 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <4E0E1E6E.9090905@arin.net> References: <4E0E1E6E.9090905@arin.net> Message-ID: > ARIN shall advise the IETF of the /10 reserved and shall request that > the IETF determine issues associated with using the /10 as described, > set appropriate constraints on the use of the block and publish an RFC > documenting the block's recommended use. ARIN shall make manpower and > other resources available to the IETF as necessary to facilitate such > activity. Would anyone object if I replaced this paragraph with: "The IETF is asked to create an RFC governing the use of the allocated /10 for the purpose described. ARIN shall make resources, such as manpower, available to the IETF as necessary to facilitate such activity." I think the original version reads a little too much like explaining to the IETF, step by step, how to do their job. John Curran has called me out on that, and while I disagree with his general position I do think the text can be worded so that it is less likely to be misinterpreted. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at arin.net Sun Jul 3 22:57:05 2011 From: jcurran at arin.net (John Curran) Date: Mon, 4 Jul 2011 02:57:05 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: References: <4E0E1E6E.9090905@arin.net> Message-ID: <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> On Jul 4, 2011, at 12:26 AM, William Herrin wrote: > > Would anyone object if I replaced this paragraph with: > > "The IETF is asked to create an RFC governing the use of the allocated > /10 for the purpose described. ARIN shall make resources, such as > manpower, available to the IETF as necessary to facilitate such > activity." > > I think the original version reads a little too much like explaining > to the IETF, step by step, how to do their job. John Curran has called > me out on that, and while I disagree with his general position I do > think the text can be worded so that it is less likely to be > misinterpreted. Bill - RFC2860 does not indicate that the IETF will create RFCs that "govern the use of the address space"; it states that the assignment of specialised address blocks shall be done by the IANA, only as directed by the criteria and procedures specified in RFCs. The IAB has already indicated that the allocation would be in conflict with these provisions in RFC2860 if done prior to the establishment of consensus within the IETF in this matter. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Mon Jul 4 06:26:51 2011 From: bill at herrin.us (William Herrin) Date: Mon, 4 Jul 2011 06:26:51 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> Message-ID: On Sun, Jul 3, 2011 at 10:57 PM, John Curran wrote: > On Jul 4, 2011, at 12:26 AM, William Herrin wrote: >> Would anyone object if I replaced this paragraph with: >> >> "The IETF is asked to create an RFC governing the use of the allocated >> /10 for the purpose described. ARIN shall make resources, such as >> manpower, available to the IETF as necessary to facilitate such >> activity." >> >> I think the original version reads a little too much like explaining >> to the IETF, step by step, how to do their job. John Curran has called >> me out on that, and while I disagree with his general position I do >> think the text can be worded so that it is less likely to be >> misinterpreted. > > ?RFC2860 does not indicate that the IETF will create RFCs that "govern the > ?use of the address space"; it states that the assignment of specialised > ?address blocks shall be done by the IANA, only as directed by the criteria > ?and procedures specified in RFCs. The IAB has already indicated that the > ?allocation would be in conflict with these provisions in RFC2860 if done > ?prior to the establishment of consensus within the IETF in this matter. John, Yes, I understand your interpretation of the matter. You recommend we punt back to the IETF and let them run with the ball for a while. And if someone else would like to write a proposal that ARIN play lap dog to the IETF on prop 2011-5, I'm sure I can find it within myself not to invent process grounds for objecting. In the mean time, you have a proposal headed for general consensus, advanced primarily by the very folks who vote for six of the seven individuals who sit on the ARIN board. The proposal, in essence, is that ARIN act now and encourage the IETF to catch up when it can. Where the specific word choice sidetracks us, I'd like to fix it. So I ask you: does this replacement resolve your concern with the prior text that it could be viewed as a procedure instead of a policy? I recognize that you have other concerns, but does it resolve that one? On a personal note, I appreciate your engagement on this issue. While I disagree with some of your conclusions, I have found your comments to be valuable and insightful. Not for nothing, but RFC 2860 can reasonably be read to prohibit the IANA from assigning address blocks to organizations who will employ them as anycast addresses. You know, folks like Network Solutions and Neustar. Unlike the shared address space in 2011-5, 2860 explicitly calls out anycast addresses (section 4.3 paragraph 2(b)). Not only that, it prohibits IANA-assigned addresses from being used for experimental protocols that consume IP addresses. 2860 calls experimental protocol addresses out as well. The IETF makes those assignments by RFC. Yet under current ARIN policy, anycast is just another multihomed use and the addresses Facebook uses with the experimental LISP protocol are not subject to revocation. Where is the outrage? You have 2860 wrong. It doesn't prevent ARIN from allocating addresses for use on the public Internet. It only enjoins ARIN from acting as the technical standards body that precisely defines the allocation's use. We can dance the language a little bit more. Make it an allocation which will be made in whole to multiple organizations instead of just one so that in a strict technical reading it is virtually the same as every other allocation we make. After all, we don't guarantee routability of any assignment and 2860 doesn't actually require one registrant to an address block. Global uniqueness is our policy and while there are RFCs, uniqueness is not part of the IANA MOU. But wouldn't you rather assume that the folks in the IETF are not a-holes and instead of trying to foil us will build the shared space we ask for? I've participated in the IETF and I'd like to think my gut reaction would be to think that if ARIN is willing to give up the addresses it must be important enough to do. And wouldn't you rather take ARIN constituents at their word that they need something usable sooner than the IETF can do a comprehensive and correct job of standardizing it? I would. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Mon Jul 4 10:36:50 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 4 Jul 2011 09:36:50 -0500 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: References: <4E0E1E6E.9090905@arin.net> Message-ID: On Sun, Jul 3, 2011 at 5:26 PM, William Herrin wrote: >> ARIN shall advise the IETF of the /10 reserved and shall request that >> the IETF determine issues associated with using the /10 as described, >> set appropriate constraints on the use of the block and publish an RFC >> documenting the block's recommended use. ARIN shall make manpower and >> other resources available to the IETF as necessary to facilitate such >> activity. > Would anyone object if I replaced this paragraph with: > "The IETF is asked to create an RFC governing the use of the allocated > /10 for the purpose described. ARIN shall make resources, such as > manpower, available to the IETF as necessary to facilitate such > activity." > I think the original version reads a little too much like explaining > to the IETF, step by step, how to do their job. John Curran has called The paragraph provides ARIN a list of things to request of the IETF. With the policy proposal the IETF might create an RFC and study issues; or the IETF might not do any of those things, or might do any combination of those things regardless of any request under the policy if accepted. It does not say anything like "The IETF shall perform these steps in order;" it will be up to the IETF which (if any) actions to take, and what order to take those actions in, regardless of what ARIN is asked to request. However, ARIN should acknowledge there might be technical issues with the /10, and the community would benefit as a result of guidance of the IETF on that manner, so it is beneficial ARIN request that. I see no problem with it being policy initially that ARIN request a list of things. But it should be removed from policy, once the IETF has decided one way or another, to provide an RFC reserving the /10, or definitively decided not to reserve additional space. So "some list of things that were to be requested at one time" should not become permanent artifacts of the NRPM. They should either expire/or be removed automatically, as the policy seems to provide for. Although the case where the IETF chooses to not publish an RFC does not appear to be anticipated by the proposal. -- -JH From jcurran at arin.net Mon Jul 4 12:20:02 2011 From: jcurran at arin.net (John Curran) Date: Mon, 4 Jul 2011 16:20:02 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> Message-ID: <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> On Jul 4, 2011, at 12:26 PM, William Herrin wrote: > Yes, I understand your interpretation of the matter. You recommend we > punt back to the IETF and let them run with the ball for a while. And > if someone else would like to write a proposal that ARIN play lap dog > to the IETF on prop 2011-5, I'm sure I can find it within myself not > to invent process grounds for objecting. Bill - RFC2860 indicates that the IETF should establish the criteria and procedures for a reservation of the type proposed in Draft Policy 2011-5. It's not just my recommendation, it is the long-standing agreement regarding the roles of the IETF and the Internet registry system. > So I ask you: does this replacement resolve your concern with the > prior text that it could be viewed as a procedure instead of a policy? > I recognize that you have other concerns, but does it resolve that > one? The change eliminates the specification of a procedure, and as such is an improvement. It does not address the fact that it specifies how ARIN interacts with another organization contrary to existing agreements, nor that it requires an immediate implementation step that the ARIN Board specifically set aside so it could request IAB guidance, nor the fact that the proposal is otherwise is duplicative of an existing draft policy already recommended to the ARIN Board for adoption. > On a personal note, I appreciate your engagement on this issue. While > I disagree with some of your conclusions, I have found your comments > to be valuable and insightful. I am glad this is helpful; I am presently out of the office on personal travel but will do my best to respond in a timely manner. > ... > You have 2860 wrong. It doesn't prevent ARIN from allocating addresses > for use on the public Internet. It only enjoins ARIN from acting as > the technical standards body that precisely defines the allocation's > use. I disagree; RFC 2860 puts into words a specific relationship that has existed for many, many years. > We can dance the language a little bit more. Make it an allocation > which will be made in whole to multiple organizations instead of just > one so that in a strict technical reading it is virtually the same as > every other allocation we make. After all, we don't guarantee > routability of any assignment and 2860 doesn't actually require one > registrant to an address block. Global uniqueness is our policy and > while there are RFCs, uniqueness is not part of the IANA MOU. Absolutely. Whether that would be perverting the intent of RFC2860 would be a determination for the ARIN Board, particularly given that the IAB has already considered this matter at the Board's request and asked that it be taken to the IETF so the technical implications can be considered. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Mon Jul 4 14:14:34 2011 From: bill at herrin.us (William Herrin) Date: Mon, 4 Jul 2011 14:14:34 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> Message-ID: On Mon, Jul 4, 2011 at 12:20 PM, John Curran wrote: > On Jul 4, 2011, at 12:26 PM, William Herrin wrote: >> Yes, I understand your interpretation of the matter. You recommend we >> punt back to the IETF and let them run with the ball for a while. And >> if someone else would like to write a proposal that ARIN play lap dog >> to the IETF on prop 2011-5, I'm sure I can find it within myself not >> to invent process grounds for objecting. > > Bill - RFC2860 indicates that the IETF should establish the criteria > and procedures for a reservation of the type proposed in Draft Policy > 2011-5. John, Prop 154 indicates the same. That's what makes it different from 2011-5. But 154 also facilitates ARIN constituents' operation for the three years it's going to take the IETF to work through the procedures. This community has argued for years as to exactly what we should do with the endgame IPv4 addresses. We've finally reached a strong consensus on how to use those addresses to keep IPv4 limping along while we wait for IPv6 ubiquity. Do you honestly believe that in a million years the authors of RFC 2860 intended to sabotage, delay or play turf wars with that effort? Of course they didn't. And that's how I know with absolute certainty that prop 154 does not violate the -spirit- of RFC 2860. >> We can dance the language a little bit more. > > Absolutely. Whether that would be perverting the intent of RFC2860 > would be a determination for the ARIN Board, particularly given that > the IAB has already considered this matter at the Board's request and > asked that it be taken to the IETF so the technical implications can > be considered. And that's why I don't want to dance the language. Or allocate the addresses to a consortium. Or any other clever circumventions folks will invariably come up with. This situation calls for prompt, effective and honest action by ARIN followed by close cooperation with the IETF. It doesn't call for dithering or being needlessly lawyerly and I'd hate to see careless choices escalate it into something that does. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at arin.net Mon Jul 4 14:37:35 2011 From: jcurran at arin.net (John Curran) Date: Mon, 4 Jul 2011 18:37:35 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> Message-ID: <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> On Jul 4, 2011, at 8:14 PM, William Herrin wrote: > On Mon, Jul 4, 2011 at 12:20 PM, John Curran wrote: >> On Jul 4, 2011, at 12:26 PM, William Herrin wrote: >>> Yes, I understand your interpretation of the matter. You recommend we >>> punt back to the IETF and let them run with the ball for a while. And >>> if someone else would like to write a proposal that ARIN play lap dog >>> to the IETF on prop 2011-5, I'm sure I can find it within myself not >>> to invent process grounds for objecting. >> >> Bill - RFC2860 indicates that the IETF should establish the criteria >> and procedures for a reservation of the type proposed in Draft Policy >> 2011-5. > > John, > > Prop 154 indicates the same. That's what makes it different from > 2011-5. But 154 also facilitates ARIN constituents' operation for the > three years it's going to take the IETF to work through the > procedures. ARIN-prop-154 directs ARIN to perform that allocation, whereas RFC 2860 indicates that should be performed by the IANA in accordance with the criteria and procedures established by the IETF. > This community has argued for years as to exactly what we should do > with the endgame IPv4 addresses. We've finally reached a strong > consensus on how to use those addresses to keep IPv4 limping along > while we wait for IPv6 ubiquity. Do you honestly believe that in a > million years the authors of RFC 2860 intended to sabotage, delay or > play turf wars with that effort? Whether that type of allocation is technically advisable is the domain of the IETF, at least according to RFC 2860 and the guidance we just received by the IAB. /John From bill at herrin.us Mon Jul 4 15:55:29 2011 From: bill at herrin.us (William Herrin) Date: Mon, 4 Jul 2011 15:55:29 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> Message-ID: On Mon, Jul 4, 2011 at 2:37 PM, John Curran wrote: > On Jul 4, 2011, at 8:14 PM, William Herrin wrote: >> On Mon, Jul 4, 2011 at 12:20 PM, John Curran wrote: >>> Bill - RFC2860 indicates that the IETF should establish the criteria >>> and procedures for a reservation of the type proposed in Draft Policy >>> 2011-5. >> >> Prop 154 indicates the same. That's what makes it different from >> 2011-5. But 154 also facilitates ARIN constituents' operation for the >> three years it's going to take the IETF to work through the >> procedures. > > ARIN-prop-154 directs ARIN to perform that allocation, whereas RFC 2860 > indicates that should be performed by the IANA in accordance with the > criteria and procedures established by the IETF. > > Whether that type of allocation is technically advisable is > the domain of the IETF, at least according to RFC 2860 and > the guidance we just received by the IAB. Then may I respectfully encourage you to ask a friendly ear to introduce a policy proposal which would have ARIN defer to the IETF in the manner your prescribe? And then endeavor to gather consensus for that proposal? By asserting a view which demands that the ARIN Board rule in a top-down manner on the subject without so much as attempting to gather consensus for it, you precipitate a scandal. I, for one, want to see the ARIN President 110% committed to the bottom-up policy development process. Especially when it's inconvenient. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at arin.net Mon Jul 4 16:00:25 2011 From: jcurran at arin.net (John Curran) Date: Mon, 4 Jul 2011 20:00:25 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> Message-ID: <341369D0-2345-4B58-8889-2F34811D28A8@arin.net> On Jul 4, 2011, at 9:55 PM, William Herrin wrote: >> Whether that type of allocation is technically advisable is >> the domain of the IETF, at least according to RFC 2860 and >> the guidance we just received by the IAB. > > Then may I respectfully encourage you to ask a friendly ear to > introduce a policy proposal which would have ARIN defer to the IETF in > the manner your prescribe? And then endeavor to gather consensus for > that proposal? Bill - Absolutely no policy proposal is necessary; Draft Policy 2011-5 has been recommended for adoption by the ARIN AC for adopted, and the Board asked that we consult with the IAB before implementation. The AC sent it to the Board, and now the Board has to determine what is most appropriate for the organization, as is its proper role when it comes to ARIN's relation with other Internet bodies. FYI, /John John Curran President and CEO ARIN From scottleibrand at gmail.com Mon Jul 4 21:04:36 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 4 Jul 2011 18:04:36 -0700 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> Message-ID: <-3062469297194053724@unknownmsgid> On Jul 4, 2011, at 12:56 PM, William Herrin wrote: > On Mon, Jul 4, 2011 at 2:37 PM, John Curran wrote: >> On Jul 4, 2011, at 8:14 PM, William Herrin wrote: >>> On Mon, Jul 4, 2011 at 12:20 PM, John Curran wrote: >>>> Bill - RFC2860 indicates that the IETF should establish the criteria >>>> and procedures for a reservation of the type proposed in Draft Policy >>>> 2011-5. >>> >>> Prop 154 indicates the same. That's what makes it different from >>> 2011-5. But 154 also facilitates ARIN constituents' operation for the >>> three years it's going to take the IETF to work through the >>> procedures. >> >> ARIN-prop-154 directs ARIN to perform that allocation, whereas RFC 2860 >> indicates that should be performed by the IANA in accordance with the >> criteria and procedures established by the IETF. >> >> Whether that type of allocation is technically advisable is >> the domain of the IETF, at least according to RFC 2860 and >> the guidance we just received by the IAB. > > Then may I respectfully encourage you to ask a friendly ear to > introduce a policy proposal which would have ARIN defer to the IETF in > the manner your prescribe? And then endeavor to gather consensus for > that proposal? > > By asserting a view which demands that the ARIN Board rule in a > top-down manner on the subject without so much as attempting to gather > consensus for it, you precipitate a scandal. I, for one, want to see > the ARIN President 110% committed to the bottom-up policy development > process. Especially when it's inconvenient. >From what I've seen the IETF is just as bottom-up as ARIN. I would encourage everyone with an interest in this issue to focus your efforts there. If everyone who made the compelling case for 2011-5 showed up on the IETF mailing list and/or participated at the IETF meetings, I don't see why this would need to take all that long to gain consensus there. -Scott From mysidia at gmail.com Mon Jul 4 22:48:05 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 4 Jul 2011 21:48:05 -0500 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> Message-ID: On Mon, Jul 4, 2011 at 1:37 PM, John Curran wrote: > On Jul 4, 2011, at 8:14 PM, William Herrin wrote: > ARIN-prop-154 directs ARIN to perform that allocation, whereas RFC 2860 > indicates that should be performed by the IANA in accordance with the > criteria and procedures established by the IETF. It should probably be noted that RFC 2860 addresses IANA and the IESG. It says nothing about ARIN or other registries; this is not a MOU between ARIN and the IETF. RFC 2860 specifically excludes the IETF from being involved in the policy decision to allocate IP addresses and domain names. "4.3. Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF: the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU. " Until an actual draft is made to assign a block to a certain technical use, the allocation proposed by 2011-05 or PROP 154 is outside the scope of the IETF's responsibilities, because in the absence of a technical specification, the internal reservation of a /10 within the ARIN registry, to ensure its future availability is purely a policy and resource management decision that ARIN can make. -- -JH From jcurran at arin.net Tue Jul 5 09:28:31 2011 From: jcurran at arin.net (John Curran) Date: Tue, 5 Jul 2011 13:28:31 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> Message-ID: <8078F4D8-5703-4A82-A703-F34BF16ADED6@arin.net> On Jul 5, 2011, at 4:48 AM, Jimmy Hess wrote: > > RFC 2860 specifically excludes the IETF from being involved in the policy > decision to allocate IP addresses and domain names. > > "4.3. Two particular assigned spaces present policy issues in addition > to the technical considerations specified by the IETF: the assignment > of domain names, and the assignment of IP address blocks. These > policy issues are outside the scope of this MOU. > " Jimmy - You fail to note that RFC 2860 continues immediately thereafter to say: " Note that (a) assignments of domain names for technical uses (such as domain names for inverse DNS lookup), (b) assignments of specialised address blocks (such as multicast or anycast blocks), and (c) experimental assignments are not considered to be policy issues, and shall remain subject to the provisions of this Section 4. " i.e. not outside the scope of the MOU, and in particular subject to the provisions of section 4 which in particular calls for IANA to assign and register Internet protocol parameters only as directed by the criteria and procedures specified in RFCs. FYI, /John John Curran President and CEO ARIN From bill at herrin.us Tue Jul 5 10:54:34 2011 From: bill at herrin.us (William Herrin) Date: Tue, 5 Jul 2011 10:54:34 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <341369D0-2345-4B58-8889-2F34811D28A8@arin.net> References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> <341369D0-2345-4B58-8889-2F34811D28A8@arin.net> Message-ID: On Mon, Jul 4, 2011 at 4:00 PM, John Curran wrote: > ?Absolutely no policy proposal is necessary [...] the Board has to determine > ?what is most appropriate for the organization, as is its proper > ?role when it comes to ARIN's relation with other Internet bodies. In about four months, 5 AC members and 2 board members need the support of the MSOs behind 2011-5 if they intend to continue determining "what is most appropriate for the organization." A third board member has recent experience with how long it took to move the solution to a critical security flaw in the DNS protocol through the IETF process... and has personal experience with the stop-gaps implemented outside the process in order to tide things over. It is not necessary for the board to seek the community's consensus before taking a proposed policy in a direction the community didn't envision, but it would be wise. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bensons at queuefull.net Tue Jul 5 14:24:00 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 5 Jul 2011 13:24:00 -0500 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <8078F4D8-5703-4A82-A703-F34BF16ADED6@arin.net> References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> <8078F4D8-5703-4A82-A703-F34BF16ADED6@arin.net> Message-ID: Hi, John. (I've already expressed my opinion that ARIN can act independently in this instance, but I view that approach as a less preferable option and will ignore it for the purposes of this discussion below.) On Jul 5, 2011, at 8:28 AM, John Curran wrote: > On Jul 5, 2011, at 4:48 AM, Jimmy Hess wrote: >> "4.3. Two particular assigned spaces present policy issues in addition >> to the technical considerations specified by the IETF: the assignment >> of domain names, and the assignment of IP address blocks. These >> policy issues are outside the scope of this MOU. >> " > .... > You fail to note that RFC 2860 continues immediately thereafter to say: > > " Note that (a) assignments of domain names for technical uses (such as > domain names for inverse DNS lookup), (b) assignments of specialised > address blocks (such as multicast or anycast blocks), and (c) > experimental assignments are not considered to be policy issues, > and shall remain subject to the provisions of this Section 4. " > > i.e. not outside the scope of the MOU, and in particular subject to the > provisions of section 4 which in particular calls for IANA to assign and > register Internet protocol parameters only as directed by the criteria and > procedures specified in RFCs. Given that IANA cannot necessarily comply (with an instruction from the IETF to assign large "specialised address blocks" at this time) it is clear that one of the RIRs must be involved in any such activity. In the case of ARIN, would it be more appropriate for (1) a /10 to be "donated" to the IETF in support of such a reservation, or (2) a /10 to be returned to IANA with the explicit condition that it is applied to the IETF instruction? Option #2 seems like the only way to interact within the unmodified framework of RFC 2860 at this time, but seems to be more complicated by the lack of global policy etc. Thus, would an RFC "updating RFC 2860" be adequate to pursue option #1? Other thoughts and/or advise would be appreciated, as well. Cheers, -Benson From owen at delong.com Tue Jul 5 14:50:00 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jul 2011 11:50:00 -0700 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <93FF1FD8-53BF-4AD8-97D9-5C5E7E732764@delong.com> Message-ID: On Jul 2, 2011, at 6:28 PM, Jimmy Hess wrote: > On Sat, Jul 2, 2011 at 4:43 PM, Owen DeLong wrote: > >> I'm not 100% sure that many existing and perfectly legitimate providers would >> actually meet that test. There are 5 regions. Not wanting to deal with more than >> one of them could lead to a provider having approximately 20% in each region >> without "region shopping". > > Perhaps then, the requirement could be that "20% or more of each > allocation or transfer > requested must be for assignment within the ARIN region. And an > additional special utilization > criterion must be met, considering only hosts in the ARIN region and > resources allocated > for use in the ARIN region, in addition to the global utilization criterion." > I'd be OK with the 20% rule. What special criterion? > It is not as if the new allocation will be contiguous with a previous one. > Unless the new allocation request is split across regions, there is not > a technical network-related reason to meet that request using the same > RIR that allocated other networks. > While there isn't a technical network-related reason, there are MANY business reasons... It complicates the accounting, increases the costs, and is otherwise burdensome from a business perspective to suddenly force organizations that have been dealing with one RIR under existing rules to suddenly change that for a few future IPv4 allocations. I see no real benefit compared to the costs of such a change. > ARIN should not necessarily support global organizations' desire to > deal with only one RIR > in every circumstance, just because they might consider it more expedient. > They have done so for many years and I think changing that for IPv4 only now would be burdensome, arbitrary, and capricious. > If an org needs a new /16, and every single host in that allocation > is going to be in > Europe, then they should be compelled to obtain the allocation from RIPE, > the proper relevant region for that network. > > Regardless of whether they have other networks in a different region (or not) > Why? If an organization is headquartered in the Canada and needs a /16 today for use in Europe and Latin America, they can obtain it from ARIN under current policy and that has been supported and in some cases even encouraged for years. Why should they be forced to add an entire new set of fees, contracts, and additional overhead for this small additional allocation to their existing /12 worth of space in those regions? Why should their staff be suddenly and temporarily forced to learn policies and procedures for two additional RIRs that they never had to deal with before? Owen From owen at delong.com Tue Jul 5 15:03:02 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jul 2011 12:03:02 -0700 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> Message-ID: On Jul 3, 2011, at 3:20 AM, John Curran wrote: > On Jul 2, 2011, at 11:29 PM, Owen DeLong wrote: > >> But 154 requires a set-aside of the space regardless of whether the IAB >> approves using it for that purpose or not. It provides for the public to know >> what block was set aside, though ARIN is instructed to discourage its use >> prior to IAB/IESG/IETF approval. > > Owen - > > ARIN already consulted with the IAB precisely on the point of making such > an allocation as described in Draft Policy 2011-5 and received the response > which I already posted to this list (to the effect that the IAB believes > that the adoption of the policy by ARIN and subsequent allocation would be > in conflict with the provisions in RFC2860) > > That response will be provided to the ARIN Board (which took Draft Policy > 2011-5 under advisement) to determine the best path forward, which could > still have ARIN reserving space for this purpose or even making the /10 > allocation while the matter in still being discussed within the IETF. > That is up to the Board to decide based on their consideration of the > IAB response, as it is not a matter of policy but instead is matter of > ARIN's agreements and relation to other Internet bodies. > > If ARIN-prop-154 were to be recommended for adoption by the Board, it > also would be sent to the Board with note to the effect that that ARIN > staff recommends consulting with the IAB prior implementation of this > draft policy. Since ARIN works are part of the Internet Registry system > in cooperation with the IANA, and there is an MOU between ICANN and IAB > which delineates the appropriate roles, any recommended draft policy > that runs contrary to that agreement will be sent to the Board with > such a recommendation to consult with the IAB prior to implementation. > The IAB advised that allocating the space would be contrary to RFC 2860. They did not address the issue of identifying, reserving it and setting it aside without allocating it which is what proposal 154 specifies. >> Since you bring it up, care to specify which language you consider not >> germane to number resource policy? > > Number reosource policy does not specify ARIN's relationships with > other parties; the specific language in question includes: "ARIN shall > advise the IETF of the /10 reserved and shall request that the IETF > determine issues associated with using the /10 as described, set > appropriate constraints on the use of the block and publish an RFC > documenting the block's recommended use. ARIN shall make manpower > and other resources available to the IETF as necessary to facilitate > such activity." Whether an ARIN policy even should direct the IETF > in such a manner, particularly after receiving differing advice from > the IAB, is not a question of number resource policy. > It does not direct the IETF and it does not specify ARIN's relationship with another party. It directs ARIN to extend particular communications to the IETF based on ARIN's existing relationship with the IETF. It directs ARIN to make a request of the IETF, it does not direct IETF to answer that request or in any way attempt to constrain the behavior of the IETF. It merely specifies the nature of the request that should be sent to the IETF which is, I think, a reasonable request for ARIN to make under the circumstances. IETF will do what IETF does regardless of any ARIN policy and I believe that proposal 154 was written with that in mind. I do not believe that the actions specified in proposal 154 are contrary to, but, rather a reasonable set of actions to take within the bounds of the memorandum from the IAB. >> I believe that proposal 154 addresses some of those issues in a more direct >> and head-on manner and if it receives community consensus (there does >> appear to be strong support so far), that would send a rather clear message >> to the board about the desires of the community. > > I'm certain that the Board is well-aware that the community desires this > reservation. The community also has to realize that the development of > the Internet Protocol, including the Internet Protocol address space, > is subject to the technical oversight of the IETF (that is indeed the > purpose of the RFC 2860 agreement.) If the community doesn't feel that > there is any technical issue with this reservation, then folks should > definitely engage with the IETF to make plain why this is the case. > That is underway in a parallel effort, but, it is not mutually exclusive from working on this policy which represents a reasonable way to make some progress on behalf of the community within the bounds of the memorandum from the IAB in response to AIRN's inquiry around draft policy 2011-5. >> I agree that it is appropriate for the board to deliberate the manner. I also feel >> that it is appropriate for the community to take further action to express their >> desires to the board and to insure that options are not overtaken by events >> while the board engages in said deliberation. > > Please elaborate on this point. Are you concerned that there will not be a > /10 block available for this purpose by the time the ARIN Board considers the > IAB response? > I am concerned that there may or may not be a /10 block available by the time IETF receives sufficient application of a clue-bat from the operational community to finally address the situation in a manner consistent with the continued operation of the internet. There is nothing in what I have seen of IETF behavior on the matter to date to lead me to believe that they will promptly act in a favorable manner until operators become so desperate to resolve the situation as to overwhelm the current IETF entrenched religion with new participants from the operational community. Owen From owen at delong.com Tue Jul 5 15:18:10 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jul 2011 12:18:10 -0700 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: References: <4E0E1E6E.9090905@arin.net> Message-ID: On Jul 3, 2011, at 3:26 PM, William Herrin wrote: >> ARIN shall advise the IETF of the /10 reserved and shall request that >> the IETF determine issues associated with using the /10 as described, >> set appropriate constraints on the use of the block and publish an RFC >> documenting the block's recommended use. ARIN shall make manpower and >> other resources available to the IETF as necessary to facilitate such >> activity. > > Would anyone object if I replaced this paragraph with: > > "The IETF is asked to create an RFC governing the use of the allocated > /10 for the purpose described. ARIN shall make resources, such as > manpower, available to the IETF as necessary to facilitate such > activity." > Yes... In order not to be directing the IETF out of scope of ARIN policy, I would propose "ARIN shall ask the IETF to create an RFC..." Oterwise, I have no objection. > > I think the original version reads a little too much like explaining > to the IETF, step by step, how to do their job. John Curran has called > me out on that, and while I disagree with his general position I do > think the text can be worded so that it is less likely to be > misinterpreted. > Works for me, but, we also need to avoid directing the IETF as John has claimed 154 did and instead, direct ARIN to request something of the IETF (as I believe 154 currently does). Owen From cgrundemann at gmail.com Tue Jul 5 15:57:51 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 5 Jul 2011 13:57:51 -0600 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space Message-ID: Hello, In response to the IAB statement regarding ARIN-2011-5, several of us have compiled an Internet Draft analyzing the need for shared transition space. You can find it online here: http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space. The current -00 version is a very rough draft thrown together over a holiday weekend and there is a -01 version forthcoming. It should however give you a good enough feel for the structure and content of the document to provide feedback. We plan to attempt to incorporate feedback from the ARIN community before the draft deadline; 11, July, so your attention to this early this week is much appreciated. Cheers, ~Chris From owen at delong.com Tue Jul 5 15:55:37 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jul 2011 12:55:37 -0700 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> Message-ID: <3C502FD0-7A75-4A97-8D12-5E70EC1CEDA8@delong.com> On Jul 4, 2011, at 11:37 AM, John Curran wrote: > > On Jul 4, 2011, at 8:14 PM, William Herrin wrote: > >> On Mon, Jul 4, 2011 at 12:20 PM, John Curran wrote: >>> On Jul 4, 2011, at 12:26 PM, William Herrin wrote: >>>> Yes, I understand your interpretation of the matter. You recommend we >>>> punt back to the IETF and let them run with the ball for a while. And >>>> if someone else would like to write a proposal that ARIN play lap dog >>>> to the IETF on prop 2011-5, I'm sure I can find it within myself not >>>> to invent process grounds for objecting. >>> >>> Bill - RFC2860 indicates that the IETF should establish the criteria >>> and procedures for a reservation of the type proposed in Draft Policy >>> 2011-5. >> >> John, >> >> Prop 154 indicates the same. That's what makes it different from >> 2011-5. But 154 also facilitates ARIN constituents' operation for the >> three years it's going to take the IETF to work through the >> procedures. > > ARIN-prop-154 directs ARIN to perform that allocation, whereas RFC 2860 > indicates that should be performed by the IANA in accordance with the > criteria and procedures established by the IETF. > I read 154 differently. To me, 154 directs ARIN to set aside a /10 reservation to be subsequently allocated, but, does not allocate it until the IETF addresses the situation and publishes an appropriate RFC. It specifically discourages ARIN constituents from using the address space until such time as the IETF publishes an RFC and ARIN completes the allocation. Owen From cgrundemann at gmail.com Tue Jul 5 16:40:05 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 5 Jul 2011 14:40:05 -0600 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <93FF1FD8-53BF-4AD8-97D9-5C5E7E732764@delong.com> Message-ID: On Tue, Jul 5, 2011 at 12:50, Owen DeLong wrote: > > On Jul 2, 2011, at 6:28 PM, Jimmy Hess wrote: >> ARIN should not necessarily support global organizations' desire to >> deal with only one RIR >> in every circumstance, just because they might consider it more expedient. >> > > They have done so for many years and I think changing that for IPv4 only now > would be burdensome, arbitrary, and capricious. Perhaps a simple grand-father clause is all that's needed? ~Chris > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From bill at herrin.us Tue Jul 5 17:01:09 2011 From: bill at herrin.us (William Herrin) Date: Tue, 5 Jul 2011 17:01:09 -0400 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: References: Message-ID: On Tue, Jul 5, 2011 at 3:57 PM, Chris Grundemann wrote: > In response to the IAB statement regarding ARIN-2011-5, several of us > have compiled an Internet Draft analyzing the need for shared > transition space. You can find it online here: > http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space. Thanks Chris, and everybody else who worked on this! Some comments: 1. In 2.1.3, SP services is not a good use case. Quasi-multihoming with a NAT box switching traffic between two separately numbered Internet connections is becoming increasingly common. With a /10, there's a very small chance of collision between the address assigned on each connection, but with services hosted on that /10 that the customer wants to reach, the chance of mayhem rises sharply. 2. Router interface numbering is a potential use case. Filtering of RFC1918 is too widespread to overcome, so using it outside the NAT breaks path MTU detection. That's not inherently true of this new space and nonfiltering could be encouraged in a way that renders it usable in a few years. 3. In 2.2.2 there's another conflict risk. Consider: ISP uses: 10.1.0.0/16. Customer directly connects a Windows PC. Assigned 10.1.2.3 by DHCP. Customer connects Cisco VPN client (UDP tunneled IPSec) to work at 192.0.2.1 Work uses 10.0.0.0/8 www.intranet.work is at 10.1.2.3. Uh oh. 4. In 4.1.2, common getaddrinfo() implementations follow RFC 3483 rule 7's requirement to prefer native transports. As a result, the 6to4 destination address is tried last (behind IPv4), further mitigating effects from incorrect 6to4 instantiation behind a firewall that obstructs its function. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Tue Jul 5 17:13:31 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jul 2011 14:13:31 -0700 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: References: Message-ID: <2E1CE3B5-D260-4460-8AC5-F594B7D35BC1@delong.com> On Jul 5, 2011, at 2:01 PM, William Herrin wrote: > On Tue, Jul 5, 2011 at 3:57 PM, Chris Grundemann wrote: >> In response to the IAB statement regarding ARIN-2011-5, several of us >> have compiled an Internet Draft analyzing the need for shared >> transition space. You can find it online here: >> http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space. > > Thanks Chris, and everybody else who worked on this! > > Some comments: > > 1. In 2.1.3, SP services is not a good use case. Quasi-multihoming > with a NAT box switching traffic between two separately numbered > Internet connections is becoming increasingly common. With a /10, > there's a very small chance of collision between the address assigned > on each connection, but with services hosted on that /10 that the > customer wants to reach, the chance of mayhem rises sharply. > > 2. Router interface numbering is a potential use case. Filtering of > RFC1918 is too widespread to overcome, so using it outside the NAT > breaks path MTU detection. That's not inherently true of this new > space and nonfiltering could be encouraged in a way that renders it > usable in a few years. > Not really... How would you know which ISP to route the packet back to? > Owen From farmer at umn.edu Tue Jul 5 17:22:22 2011 From: farmer at umn.edu (David Farmer) Date: Tue, 05 Jul 2011 16:22:22 -0500 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: <2E1CE3B5-D260-4460-8AC5-F594B7D35BC1@delong.com> References: <2E1CE3B5-D260-4460-8AC5-F594B7D35BC1@delong.com> Message-ID: <4E13808E.1010709@umn.edu> On 7/5/11 16:13 CDT, Owen DeLong wrote: > On Jul 5, 2011, at 2:01 PM, William Herrin wrote: >> 2. Router interface numbering is a potential use case. Filtering of >> RFC1918 is too widespread to overcome, so using it outside the NAT >> breaks path MTU detection. That's not inherently true of this new >> space and nonfiltering could be encouraged in a way that renders it >> usable in a few years. > > Not really... How would you know which ISP to route the packet > back to? Path MTU and ICMP TTL exceeds would be scoured from the router. If the router is number with RFC 1918, many people filter inbound packets source from RFC 1918. This possibly wouldn't be the case for the /10. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at herrin.us Tue Jul 5 17:24:21 2011 From: bill at herrin.us (William Herrin) Date: Tue, 5 Jul 2011 17:24:21 -0400 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: <2E1CE3B5-D260-4460-8AC5-F594B7D35BC1@delong.com> References: <2E1CE3B5-D260-4460-8AC5-F594B7D35BC1@delong.com> Message-ID: On Tue, Jul 5, 2011 at 5:13 PM, Owen DeLong wrote: > On Jul 5, 2011, at 2:01 PM, William Herrin wrote: >> 2. Router interface numbering is a potential use case. Filtering of >> RFC1918 is too widespread to overcome, so using it outside the NAT >> breaks path MTU detection. That's not inherently true of this new >> space and nonfiltering could be encouraged in a way that renders it >> usable in a few years. > > Not really... How would you know which ISP to route the packet > back to? Hi Owen, You don't care. The packets you care about receiving from the router are ICMP type 3 (destination unreachable) and ICMP type 11 (time exceeded) . Those flow only one direction -- from the router back towards you. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Tue Jul 5 17:30:31 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jul 2011 14:30:31 -0700 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: References: <2E1CE3B5-D260-4460-8AC5-F594B7D35BC1@delong.com> Message-ID: On Jul 5, 2011, at 2:24 PM, William Herrin wrote: > On Tue, Jul 5, 2011 at 5:13 PM, Owen DeLong wrote: >> On Jul 5, 2011, at 2:01 PM, William Herrin wrote: >>> 2. Router interface numbering is a potential use case. Filtering of >>> RFC1918 is too widespread to overcome, so using it outside the NAT >>> breaks path MTU detection. That's not inherently true of this new >>> space and nonfiltering could be encouraged in a way that renders it >>> usable in a few years. >> >> Not really... How would you know which ISP to route the packet >> back to? > > Hi Owen, > > You don't care. The packets you care about receiving from the router > are ICMP type 3 (destination unreachable) and ICMP type 11 (time > exceeded) . Those flow only one direction -- from the router back > towards you. > Not really... If a packet is inbound towards me and needs fragmentation, for PMTU discovery, then, an ICMP type 3 would be sent back towards the originator of said packet. Owen From bill at herrin.us Tue Jul 5 17:40:22 2011 From: bill at herrin.us (William Herrin) Date: Tue, 5 Jul 2011 17:40:22 -0400 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: References: <2E1CE3B5-D260-4460-8AC5-F594B7D35BC1@delong.com> Message-ID: On Tue, Jul 5, 2011 at 5:30 PM, Owen DeLong wrote: > On Jul 5, 2011, at 2:24 PM, William Herrin wrote: >> On Tue, Jul 5, 2011 at 5:13 PM, Owen DeLong wrote: >>> On Jul 5, 2011, at 2:01 PM, William Herrin wrote: >>>> 2. Router interface numbering is a potential use case. Filtering of >>>> RFC1918 is too widespread to overcome, so using it outside the NAT >>>> breaks path MTU detection. That's not inherently true of this new >>>> space and nonfiltering could be encouraged in a way that renders it >>>> usable in a few years. >>> >>> Not really... How would you know which ISP to route the packet >>> back to? >> >> You don't care. The packets you care about receiving from the router >> are ICMP type 3 (destination unreachable) and ICMP type 11 (time >> exceeded) . Those flow only one direction -- from the router back >> towards you. > > If a packet is inbound towards me and needs fragmentation, for PMTU > discovery, then, an ICMP type 3 would be sent back towards the > originator of said packet. Correct, but the originator doesn't care what address that packet comes from and doesn't attempt to reply to it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmaimon at chl.com Tue Jul 5 18:51:56 2011 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 05 Jul 2011 18:51:56 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> Message-ID: <4E13958C.50309@chl.com> Owen DeLong wrote: > > The IAB advised that allocating the space would be contrary to RFC 2860. > They did not address the issue of identifying, reserving it and setting it > aside without allocating it which is what proposal 154 specifies. Tell me how an identified reservation contrasts positively with an actual allocation. You risk a de-facto allocation with none of the benefits of an actual allocation. > > I am concerned that there may or may not be a /10 block available by the time I believe this should be addressed with an unidentifiable reservation. > Owen Joe From owen at delong.com Tue Jul 5 19:59:44 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jul 2011 16:59:44 -0700 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: References: <2E1CE3B5-D260-4460-8AC5-F594B7D35BC1@delong.com> Message-ID: On Jul 5, 2011, at 2:40 PM, William Herrin wrote: > On Tue, Jul 5, 2011 at 5:30 PM, Owen DeLong wrote: >> On Jul 5, 2011, at 2:24 PM, William Herrin wrote: >>> On Tue, Jul 5, 2011 at 5:13 PM, Owen DeLong wrote: >>>> On Jul 5, 2011, at 2:01 PM, William Herrin wrote: >>>>> 2. Router interface numbering is a potential use case. Filtering of >>>>> RFC1918 is too widespread to overcome, so using it outside the NAT >>>>> breaks path MTU detection. That's not inherently true of this new >>>>> space and nonfiltering could be encouraged in a way that renders it >>>>> usable in a few years. >>>> >>>> Not really... How would you know which ISP to route the packet >>>> back to? >>> >>> You don't care. The packets you care about receiving from the router >>> are ICMP type 3 (destination unreachable) and ICMP type 11 (time >>> exceeded) . Those flow only one direction -- from the router back >>> towards you. >> >> If a packet is inbound towards me and needs fragmentation, for PMTU >> discovery, then, an ICMP type 3 would be sent back towards the >> originator of said packet. > > Correct, but the originator doesn't care what address that packet > comes from and doesn't attempt to reply to it. > I tend to doubt anyone would be any more likely to accept these addresses across their border as source addresses than RFC-1918. Owen From owen at delong.com Tue Jul 5 20:05:30 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Jul 2011 17:05:30 -0700 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <4E13958C.50309@chl.com> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> <4E13958C.50309@chl.com> Message-ID: <0649FABB-3ABF-4702-AECA-0776B493F23B@delong.com> On Jul 5, 2011, at 3:51 PM, Joe Maimon wrote: > > > Owen DeLong wrote: > >> >> The IAB advised that allocating the space would be contrary to RFC 2860. >> They did not address the issue of identifying, reserving it and setting it >> aside without allocating it which is what proposal 154 specifies. > > Tell me how an identified reservation contrasts positively with an actual allocation. You risk a de-facto allocation with none of the benefits of an actual allocation. > The proposal requires ARIN to identify it, but, not to disclose its identity as I read it. An identified reservation that is not published contrasts with an actual allocation in exactly the fact that it is unpublished. I'm not sure where the risk you claim would come from if the reservation is not published. Identify, to me, in the context of proposal 154 distinguishes between "we need to stop allocating when the free pool has only a two /10s in it" vs. "this particular /10 is specifically reserved for this purpose". Nothing says that the identity of the particular /10 needs to be published by ARIN. >> >> I am concerned that there may or may not be a /10 block available by the time > > I believe this should be addressed with an unidentifiable reservation. > I am not sure what the point would be to simply tell ARIN to hold off on allocating space beyond a certain limit vs. asking them to set aside a particular /10. It is the publication of the number range that seems to be your issue, not the identification of it. Since there is benefit to this being a contiguous /10 rather than the other reservation policy (NRPM 4.10) which requires only space which in aggregate represents the equivalent of a /10, I think it is better to reserve a particular /10 for this purpose vs. 4.10 which allows ARIN to leave the determination of which pieces comprise the reservation to a later point. Owen From jmaimon at chl.com Tue Jul 5 20:54:21 2011 From: jmaimon at chl.com (Joe Maimon) Date: Tue, 05 Jul 2011 20:54:21 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <0649FABB-3ABF-4702-AECA-0776B493F23B@delong.com> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> <4E13958C.50309@chl.com> <0649FABB-3ABF-4702-AECA-0776B493F23B@delong.com> Message-ID: <4E13B23D.5020905@chl.com> Owen DeLong wrote: > I'm not sure where the risk you claim would come from if the reservation is > not published. > I simply want to know how you can reserve a /10 specifically for the context of 2011-5/pp-154 without letting the cat out of the bag. Joe From farmer at umn.edu Tue Jul 5 21:13:48 2011 From: farmer at umn.edu (David Farmer) Date: Tue, 05 Jul 2011 20:13:48 -0500 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: References: Message-ID: <4E13B6CC.1090508@umn.edu> On 7/5/11 14:57 CDT, Chris Grundemann wrote: > Hello, > > In response to the IAB statement regarding ARIN-2011-5, several of us > have compiled an Internet Draft analyzing the need for shared > transition space. You can find it online here: > http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space. > The current -00 version is a very rough draft thrown together over a > holiday weekend and there is a -01 version forthcoming. It should > however give you a good enough feel for the structure and content of > the document to provide feedback. We plan to attempt to incorporate > feedback from the ARIN community before the draft deadline; 11, July, > so your attention to this early this week is much appreciated. Some suggestions; Abstract This memo encourages the reservation of a Shared Transition Space, an IPv4 prefix designated for local use within a service provider networks during the period of IPv6 transition. This address space has been proposed at various times in the IETF, and more recently + come to consensus within the ARIN policy development community. ----- Section 1, 3rd paragraph, last sentence; After much discussion by the ARIN community, [ARIN-2011-5] + reached consensus and was recommended by the ARIN Advisory Council for approval by the ARIN Board of Trustees. ---- Please add something along the following lines to section 3.3.2. Return or Transfer A potential target for Prefix Squatting would be dormant or under utilized IPv4 address space; However, the RIRs are targeting this same dormant or under utilized address space for recycling through policies for return and/or transfer of such address space. Prefix Squatting, would significantly degrade the effectiveness of this important policy initiative on behalf of the RIRs. ---- 7. IANA Considerations This memo includes no request to IANA. I believe it is better for IANA to officially make the actual allocation under the direction of the IAB, but since IANA no longer has the inventory necessary for such an action it should coordinate with ARIN as the donor of the space. I suggest something like this; This document recommends the IAB direct IANA to reserve an IPv4 /10 for use as Shared Transition Space. IANA should coordinate with ARIN regarding [ARIN-2011-5] to receive the space from ARIN's inventory. Additionally, I believe it would be a good idea to consider reverse DNS for the /10. As I suspect it will behave much like RFC1918 address space for this consideration, should it be handled similar to RFC 1918 address space? That is, using the AS112 project. see: http://public.as112.net/ There are RFCs in final stages of being published formalizing this; See: http://tools.ietf.org/html/draft-ietf-dnsop-as112-ops See: http://tools.ietf.org/html/draft-ietf-dnsop-default-local-zones Also another draft just getting started defining additional IPv6 reverse zones that should be treated the same way; http://tools.ietf.org/html/draft-michaelson-as112-ipv6 Therefore, I also suggest something like this get added too; Further, IANA will delegate the IN-ADDR.ARPA reverse DNS zones associated this Shared Transition Space to the AS112 project [ID.ietf-dnsop-as112-ops]. ---- Finally, I'm not sure this goes in any specific place, but I have an issue with the overall tone. In my opinion the current draft has more of a tone that an allocation of a /10 for Shared Transition Space is the best and only solution to this problem. Where the really is more that none of the options, including this allocation, are a universally good solution to this problem, many of the other options are valid in some cases. We need to set a more pragmatic tone, there are no universally good solutions here, and what ever the shortcomings of this solution, it is necessary for some operators. So lets make the allocation of a /10 for Shared Transition Space that is a necessary option for a number of operators and allow everyone move on to implementing IPv6. =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at herrin.us Tue Jul 5 21:14:24 2011 From: bill at herrin.us (William Herrin) Date: Tue, 5 Jul 2011 21:14:24 -0400 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <4E13B23D.5020905@chl.com> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> <4E13958C.50309@chl.com> <0649FABB-3ABF-4702-AECA-0776B493F23B@delong.com> <4E13B23D.5020905@chl.com> Message-ID: On Tue, Jul 5, 2011 at 8:54 PM, Joe Maimon wrote: > Owen DeLong wrote: >> I'm not sure where the risk you claim would come from if the reservation >> is not published. > > I simply want to know how you can reserve a /10 specifically for the context > of 2011-5/pp-154 without letting the cat out of the bag. I think you intentionally let the cat out of the bag. I think you let the reasonable and intelligent folks running ISPs weigh the risks of using it prior to standardization against the costs of not doing so and make their own choices. Better that they squat on the pre-standard /10 than squat on, say, one of the DoD /8s. That also allows the folks in the IETF to take their time and do a thorough job evaluating the technical concerns instead of having to rush it out. But that's just me. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gary.buhrmaster at gmail.com Tue Jul 5 22:21:41 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 6 Jul 2011 02:21:41 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: <4E13B23D.5020905@chl.com> References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> <4E13958C.50309@chl.com> <0649FABB-3ABF-4702-AECA-0776B493F23B@delong.com> <4E13B23D.5020905@chl.com> Message-ID: On Wed, Jul 6, 2011 at 00:54, Joe Maimon wrote: .... > I simply want to know how you can reserve a /10 specifically for the context > of 2011-5/pp-154 without letting the cat out of the bag. In practice, I just do not think you can keep that cat bagged over the time frame of IETF deliberations. The real question would be would anyone use that /10, knowing that they could be at some risk should it eventually be used for a real assignment/allocation. Is there any sense of the ARIN board as to whether they could decide to decide at their next meeting whether to direct a reservation of a final /10, based on the communities support of 2011-5, so that when the IETF process completes its work ARIN will be in a position to contribute that /10 (should the IETF result be aligned with 2011-5)? Gary From mysidia at gmail.com Tue Jul 5 23:25:43 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 5 Jul 2011 22:25:43 -0500 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> <4E13958C.50309@chl.com> <0649FABB-3ABF-4702-AECA-0776B493F23B@delong.com> <4E13B23D.5020905@chl.com> Message-ID: On Tue, Jul 5, 2011 at 9:21 PM, Gary Buhrmaster wrote: > On Wed, Jul 6, 2011 at 00:54, Joe Maimon wrote: >> I simply want to know how you can reserve a /10 specifically for the context >> of 2011-5/pp-154 without letting the cat out of the bag. > In practice, I just do not think you can keep that cat > bagged over the time frame of IETF deliberations. I in no way suggest trying to keep a 'cat in the bag'; ARIN should indicate what /10 is chosen, and permit it for Experimental use. Realistically: the notion of waiting on a full IETF deliberation to complete is equivalent to rejecting the idea of official address space being available for use with a shared /10. The time before shared address space would be needed is within 12 months. The duration required for an IETF deliberation is measured in multiples of years, they only even have a meeting once a year, and such.... By the time the IETF deliberation could happen at earliest, within about 3 years, (hopefully), IPv6 would be the predominant protocol, resulting in the draft being moot by that time. -- -JH From jcurran at arin.net Wed Jul 6 01:10:35 2011 From: jcurran at arin.net (John Curran) Date: Wed, 6 Jul 2011 05:10:35 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) In-Reply-To: References: <4E0E1E6E.9090905@arin.net> <88C4FD09-4632-4F30-9962-7E83F887A71F@arin.net> <764D421A-0BBB-46A6-B984-7C9133F600FE@arin.net> <2143E2D2-4B17-468D-9AB6-79F13D3F1505@arin.net> <8078F4D8-5703-4A82-A703-F34BF16ADED6@arin.net> Message-ID: <82951AA6-4C9B-4A53-B0D7-51C150194633@arin.net> On Jul 5, 2011, at 8:24 PM, Benson Schliesser wrote: > > Given that IANA cannot necessarily comply (with an instruction from the IETF to assign large "specialised address blocks" at this time) it is clear that one of the RIRs must be involved in any such activity. In the case of ARIN, would it be more appropriate for (1) a /10 to be "donated" to the IETF in support of such a reservation, or (2) a /10 to be returned to IANA with the explicit condition that it is applied to the IETF instruction? > > Option #2 seems like the only way to interact within the unmodified framework of RFC 2860 at this time, but seems to be more complicated by the lack of global policy etc. Thus, would an RFC "updating RFC 2860" be adequate to pursue option #1? > > Other thoughts and/or advise would be appreciated, as well. Since the ARIN community has already recommended use of address space from our available pool for this purpose, it is reasonable for ARIN to make sure space remains available for as long as possible should the IETF approve such an reservation. If ARIN is informed by the IAB at any point that it is to make the reservation, we can do so immediately. If the IETF directs the IANA to receive space from ARIN so the IANA may make the reservation, then we can release the space to the IANA for that purpose. I would consider either of the above outcomes to be implementation of ARIN 2011-5 (the intent of 2011-5 is quite clear; it has been the implementation that requires consultation to effect.) FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Wed Jul 6 01:18:52 2011 From: jcurran at arin.net (John Curran) Date: Wed, 6 Jul 2011 05:18:52 +0000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> Message-ID: On Jul 5, 2011, at 9:03 PM, Owen DeLong wrote: > > I am concerned that there may or may not be a /10 block available by the time > IETF receives sufficient application of a clue-bat from the operational community > to finally address the situation in a manner consistent with the continued operation > of the internet. There is nothing in what I have seen of IETF behavior on the matter > to date to lead me to believe that they will promptly act in a favorable manner until > operators become so desperate to resolve the situation as to overwhelm the current > IETF entrenched religion with new participants from the operational community. At the point in time where such a /10 block would become no longer available, I will recommend to the ARIN Board that we hold such space in reserve to allow implementation of 2011-5 (which remains under advisement), and I'd expect them to approve that as long as there is ongoing engagement with the IETF on this matter. FYI, /John John Curran President and CEO ARIN From cgrundemann at gmail.com Wed Jul 6 14:55:12 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 6 Jul 2011 12:55:12 -0600 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: <4E13B6CC.1090508@umn.edu> References: <4E13B6CC.1090508@umn.edu> Message-ID: Thanks for the input David, a couple comments below: On Tue, Jul 5, 2011 at 19:13, David Farmer wrote: > ---- > 7. IANA Considerations > > ? This memo includes no request to IANA. > > I believe it is better for IANA to officially make the actual allocation > under the direction of the IAB, but since IANA no longer has the inventory > necessary for such an action it should coordinate with ARIN as the donor of > the space. The actual request for the space is contained in the much more succinct draft-weil-shared-transition-space-request. This draft is meant to provide an analysis of the need, not make the request (since it has already been made in draft-weil). > ---- > Finally, I'm not sure this goes in any specific place, but I have an issue > with the overall tone. In my opinion the current draft has more of a tone > that an allocation of a /10 for Shared Transition Space is the best and only > solution to this problem. > > Where the really is more that none of the options, including this > allocation, are a universally good solution to this problem, many of the > other options are valid in some cases. ? We need to set a more pragmatic > tone, there are no universally good solutions here, and what ever the > shortcomings of this solution, it is necessary for some operators. ?So lets > make the allocation of a /10 for Shared Transition Space that is a necessary > option for a number of operators and allow everyone move on to implementing > IPv6. In general I (and to the best of my knowledge, the other authors) agree. We tried to present all of the options and provide an analysis. IMHO, a full analysis of the available options does result in the conclusion that shared transition space is needed, likely not for all providers / situations but for enough that the reservation makes sense; apparently this shows through in the I-D. Do you have any specific examples of where the text appears biased, or any suggestions on how to improve the overall tone? This is a rough draft and we welcome further input. Thanks! ~Chris > =============================================== > David Farmer ? ? ? ? ? ? ? Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE ? ? ?Phone: 612-626-0815 > Minneapolis, MN 55414-3029 ? Cell: 612-812-9952 > =============================================== > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From cgrundemann at gmail.com Wed Jul 6 14:56:18 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 6 Jul 2011 12:56:18 -0600 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: References: Message-ID: Thanks Bill, we will work to include your input in the next version of the I-D. Cheers, ~Chris On Tue, Jul 5, 2011 at 15:01, William Herrin wrote: > On Tue, Jul 5, 2011 at 3:57 PM, Chris Grundemann wrote: >> In response to the IAB statement regarding ARIN-2011-5, several of us >> have compiled an Internet Draft analyzing the need for shared >> transition space. You can find it online here: >> http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space. > > Thanks Chris, and everybody else who worked on this! > > Some comments: > > 1. In 2.1.3, SP services is not a good use case. Quasi-multihoming > with a NAT box switching traffic between two separately numbered > Internet connections is becoming increasingly common. With a /10, > there's a very small chance of collision between the address assigned > on each connection, but with services hosted on that /10 that the > customer wants to reach, the chance of mayhem rises sharply. > > 2. Router interface numbering is a potential use case. Filtering of > RFC1918 is too widespread to overcome, so using it outside the NAT > breaks path MTU detection. That's not inherently true of this new > space and nonfiltering could be encouraged in a way that renders it > usable in a few years. > > 3. In 2.2.2 there's another conflict risk. Consider: > > ISP uses: 10.1.0.0/16. > Customer directly connects a Windows PC. Assigned 10.1.2.3 by DHCP. > Customer connects Cisco VPN client (UDP tunneled IPSec) to work at 192.0.2.1 > Work uses 10.0.0.0/8 > www.intranet.work is at 10.1.2.3. > > Uh oh. > > > 4. In 4.1.2, common getaddrinfo() implementations follow RFC 3483 rule > 7's requirement to prefer native transports. As a result, the 6to4 > destination address is tried last (behind IPv4), further mitigating > effects from incorrect 6to4 instantiation behind a firewall that > obstructs its function. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From alh-ietf at tndh.net Wed Jul 6 14:52:41 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 6 Jul 2011 11:52:41 -0700 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <86y60g7mea.fsf@seastrom.com> References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> Message-ID: <0b7901cc3c0d$e3e07040$aba150c0$@net> Robert E. Seastrom wrote: > William Herrin writes: > > > On Fri, Jul 1, 2011 at 3:24 PM, ARIN wrote: > >> ARIN-prop-155 IPv4 Number Resources for Use Within Region > > > > Oppose as written. > > I wrote this proposal as a starting point, and expected plenty of > spirited discussion surrounding it. Didn't expect that it would be > quite so overwhelmingly "oppose", but those are the breaks. Were you hoping for something more along the lines of: "this is nothing more than human nature at its worst, hoarding in the face of shortage" If it is not clear, I oppose as written, as well as the basic premise that one 'needs to protect a regional asset'. The RIRs were not created to be islands, they are supposed to be facilitators in distributing the global address pool asset. The stewardship component of that is intended to preclude hoarding, not be the basis for regional isolationism. It is absolutely absurd that 'the richest' (in context) region should even have the discussion about how to prevent 'outsiders' from acquiring resources in the face of famine. Given behavior like this, the appropriate thing to do is change IANA policy to allow sub-/8 allocations, then recall all outstanding space and manage the remaining pool under a common policy of global fulfillment of need. Children fighting over toys in the sandbox are better behaved ... At the end of the day, this policy mindset is unenforceable for future allocations, and does nothing to preclude an organization with existing resources from moving those outside the region to use the new ones locally. Get over it, IPv4 is dead; and being the most obnoxious buzzard that protects the last of the scraps from others is not 'stewardship'. Tony > > Unfortunately there are no easy answers to a lot of the concerns that > folks have raised as reasons for opposing it. It would be extremely > easy to go down the rat-hole of trying to dictate operational > constraints by making the policy statement 4x as large, and what would > happen is that ultimately some creative person would figure out a > loophole and all of our efforts would be for naught until the next > policy cycle, at which point we'd probably be overtaken by events. > The Board doesn't like such policy proposals and will surely remand > them for further discussion, at which point we end up kind of hosed > because of the aforementioned cycle. > > I believe that we ought to have a policy to address the situation you > elucidate below. That's why I wrote this proposal. Sussing out where > the community wants to take this (or even if collectively we want to > ignore the rising tide of opportunities for abuse and just be > fatalistic about v4 exhaustion) is part of the whole point of the PDP. > Discussion and modification encouraged. > > > However, I do think Robert has identified a legitimate problem. > > As much as I would like to take credit for original thought, word on > the street is that others have already "identified" it. :-( > > > It costs less than $5000/year to establish and maintain a US > > corporation. > > It can be done for an order of magnitude less. > > > If I'm a French or Japanese telco, what policy stops me from creating > > a Delaware ISP subsidiary whose sole existence is acquiring ARIN IP > > addresses and assigning them for well documented use in my European > or > > Asian operations? > > You tell me. ;-) > > cheers, > > -r > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mysidia at gmail.com Wed Jul 6 21:17:02 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 6 Jul 2011 20:17:02 -0500 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <0b7901cc3c0d$e3e07040$aba150c0$@net> References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <0b7901cc3c0d$e3e07040$aba150c0$@net> Message-ID: On Wed, Jul 6, 2011 at 1:52 PM, Tony Hain wrote: > Robert E. Seastrom wrote: >> William Herrin writes: >> > Oppose as written. >> I wrote this proposal as a starting point, and expected plenty of >> spirited discussion surrounding it. ?Didn't expect that it would be >> quite so overwhelmingly "oppose", but those are the breaks. Oppose as written... means just that.. I am strongly in favor of the concept, but see overwhelming issues with the current text or criteria of the proposal, and they can be fixed by revising the proposal. Realistically, it is wasteful for a global organization to have to deal with every RIR and prove every single address is being used in the region that allocated it. And this results in inefficient usage of IP address space, since now multiple allocations would be required from multiple RIRs, for such orgs, There must be a way to eliminate the abuse cases without throwing out the common behavior, of multi-nationals having networks that cross national borders and utilize ARIN IPs for some networks outside our region. Instead ARIN should set reasonable restrictions and limits to prevent or minimize RIR shopping, or obtaining resource allocations from ARIN with an intention of using a majority of the resources in networks outside the geographic region the resources are assigned to. With the policy objective of limiting abuse; or "finding an excuse" to apply for resources from ARIN, due to exhaustion of resources in the proper RIR to allocate the resources. > Were you hoping for something more along the lines of: > "this is nothing more than human nature at its worst, hoarding in the face > of shortage" We are not referring to "hoarding". Every RIR has organizations in region that require all the resources of that RIR; every RIR's resources will be allocated at a certain rate and rapidly exhausted. Hoarding implies collecting some resources you don't need -- but mathematically, orgs in ARIN region need all the resources within a specific amount of time, or ARIN would not have been allocated the resources in the first place. It is basically impossible for anything ARIN does to be "hoarding," short of stopping allocations, or applying a rationing criteria such as APNIC's last /8 policy, that could be considered hoarding. The amount of addresses that were applied for and received by each RIR are based on the need of allocating addresses within that region. ARIN resources will be exhausted with no RIR shopping at all. > If it is not clear, I oppose as written, as well as the basic premise that > one 'needs to protect a regional asset'. The RIRs were not created to be > islands, they are supposed to be facilitators in distributing the global > address pool asset. The stewardship component of that is intended to Each RIR is a facilitator in distributing IP addresses to networks and registries WITHIN that RIR's region. A RIR is not designed to be a facilitator in distributing IP addresses or setting addressing policy for networks in other regions. It is entirely appropriate that ARIN adopt a policy similar to 155. With the right modifications, I would support 155. -- -JH From alh-ietf at tndh.net Wed Jul 6 22:36:10 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 6 Jul 2011 19:36:10 -0700 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <0b7901cc3c0d$e3e07040$aba150c0$@net> Message-ID: <0c7e01cc3c4e$a3891f10$ea9b5d30$@net> Jimmy Hess wrote: > On Wed, Jul 6, 2011 at 1:52 PM, Tony Hain wrote: > > Robert E. Seastrom wrote: > >> William Herrin writes: > > >> > Oppose as written. > >> I wrote this proposal as a starting point, and expected plenty of > >> spirited discussion surrounding it. ?Didn't expect that it would be > >> quite so overwhelmingly "oppose", but those are the breaks. > > Oppose as written... means just that.. I am strongly in favor of the > concept, but see overwhelming issues with the current text or criteria > of the proposal, and they can be fixed by revising the proposal. > > Realistically, it is wasteful for a global organization to have to deal > with every RIR and prove every single address is being used in the > region that allocated it. And this results in inefficient usage of IP > address space, since now multiple allocations would be required > from multiple RIRs, for such orgs, > > There must be a way to eliminate the abuse cases without throwing > out the common behavior, of multi-nationals having networks that > cross national borders and utilize ARIN IPs for some networks outside > our region. > > Instead ARIN should set reasonable restrictions and limits to > prevent or minimize RIR shopping, or obtaining resource allocations > from ARIN with an intention of using a majority of the resources in > networks outside the geographic region the resources are assigned to. > > With the policy objective of limiting abuse; or "finding an excuse" to > apply > for resources from ARIN, due to exhaustion of resources in the proper > RIR > to allocate the resources. > > > Were you hoping for something more along the lines of: > > "this is nothing more than human nature at its worst, hoarding in the > face > > of shortage" > > We are not referring to "hoarding". Every RIR has organizations in > region that require all the resources of that RIR; every RIR's > resources > will be allocated at a certain rate and rapidly exhausted. > > Hoarding implies collecting some resources you don't need -- but > mathematically, orgs in ARIN region need all the resources within > a specific amount of time, or ARIN would not have been allocated > the resources in the first place. The hoarding comes from the bogus perspective that historical ARIN members have a priority right to remaining space in the ARIN pool. Realistically, that resource is to be shared amongst all ARIN members, new or old. If any organization joins ARIN and meets all current policy requirements for how the space will be used, there is no valid reason for constraints about what part of the Internet that gets deployed in. It is a global Internet, so the space might be used anywhere. This attempt at artificial restrictions on where it gets used is nothing more than a blatant power grab. > > It is basically impossible for anything ARIN does to be "hoarding," > short of stopping allocations, or applying a rationing criteria such > as APNIC's last /8 policy, that could be considered hoarding. > > > The amount of addresses that were applied for and received by each > RIR are based on the need of allocating addresses within that region. > > ARIN resources will be exhausted with no RIR shopping at all. > > > > > If it is not clear, I oppose as written, as well as the basic premise > that > > one 'needs to protect a regional asset'. The RIRs were not created to > be > > islands, they are supposed to be facilitators in distributing the > global > > address pool asset. The stewardship component of that is intended to > > Each RIR is a facilitator in distributing IP addresses > to networks and registries WITHIN that RIR's region. > > A RIR is not designed to be a facilitator in distributing IP addresses > or setting addressing policy for networks in other regions. Attempting to rewrite history by asserting an exclusionary mantra does not make it so. Organizations have always been free to join any RIR and do whatever that RIRs policy allows with any space allocated or assigned. The BS exclusionary mindset is a direct product of regional hoarding at the end of the free pool. This is an exceptionally bad approach to policy, and completely inconsistent with the notion that industry self-regulation is appropriate for managing the valuable global resources of network addressing. If we really are looking out for the good-of-the-whole, exclusionary tactics are out of scope. If we really believe exclusionary tactics are appropriate, bend over and get ready for the regulatory oversight that WILL arrive shortly ... Tony > > It is entirely appropriate that ARIN adopt a policy similar to 155. > > With the right modifications, I would support 155. > > -- > -JH From farmer at umn.edu Thu Jul 7 00:45:43 2011 From: farmer at umn.edu (David Farmer) Date: Wed, 06 Jul 2011 23:45:43 -0500 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <0c7e01cc3c4e$a3891f10$ea9b5d30$@net> References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <0b7901cc3c0d$e3e07040$aba150c0$@net> <0c7e01cc3c4e$a3891f10$ea9b5d30$@net> Message-ID: <4E1539F7.8030006@umn.edu> On 7/6/11 21:36 CDT, Tony Hain wrote: > Jimmy Hess wrote: .... >> Each RIR is a facilitator in distributing IP addresses >> to networks and registries WITHIN that RIR's region. >> >> A RIR is not designed to be a facilitator in distributing IP addresses >> or setting addressing policy for networks in other regions. > > Attempting to rewrite history by asserting an exclusionary mantra does not > make it so. Organizations have always been free to join any RIR and do > whatever that RIRs policy allows with any space allocated or assigned. The > BS exclusionary mindset is a direct product of regional hoarding at the end > of the free pool. > > This is an exceptionally bad approach to policy, and completely inconsistent > with the notion that industry self-regulation is appropriate for managing > the valuable global resources of network addressing. If we really are > looking out for the good-of-the-whole, exclusionary tactics are out of > scope. If we really believe exclusionary tactics are appropriate, bend over > and get ready for the regulatory oversight that WILL arrive shortly ... > > Tony Tony, More or less, I want to agree with you. But, how do you justify this with ICP-2 and the concept of separate service regions. http://www.icann.org/en/icp/icp-2.htm Also, this come from a Policy Experience Report Question from San Juan; https://www.arin.net/participate/meetings/reports/ARIN_XXVII/PDF/Monday/nobile_policy_experience.pdf Slides 7 and 8; This also plays into the questions of returning of space to IANA, Inter-RIR transfers, needs based transfers in ARIN and non-needs based transfers in APNIC, etc... In some ways if ARIN could service anyone globally using its policies, that might be a good way to deal with a bunch of sticky issues, but at least on the surface that conflicts with ICP-2. On the other hand, if you allow that, you can raises a bunch of sticky issues too. Can someone move all or some of their registrations to another region? I don't want to be exclusionary. But then isn't the whole concept of regional service areas suppose to be at least somewhat exclusionary? Otherwise what is the meaning of regional service areas in ICP-2? When there was an IANA free pool, we could wave our hands mumble something that sounded good, go to the bar and keep getting rounds of drinks until no one could remember what the question was. But something tells me that trick won't work no more.:) -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Thu Jul 7 03:54:23 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jul 2011 00:54:23 -0700 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <4E1539F7.8030006@umn.edu> References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <0b7901cc3c0d$e3e07040$aba150c0$@net> <0c7e01cc3c4e$a3891f10$ea9b5d30$@net> <4E1539F7.8030006@umn.edu> Message-ID: <125491BE-26B1-47D9-8FBF-D9DF3A22F83E@delong.com> > > When there was an IANA free pool, we could wave our hands mumble something that sounded good, go to the bar and keep getting rounds of drinks until no one could remember what the question was. But something tells me that trick won't work no more.:) > The current IANA free pool is huge. It contains more than 500 /12s each of which contains more than 1,000,000 /32s. Owen From jcurran at arin.net Thu Jul 7 09:44:18 2011 From: jcurran at arin.net (John Curran) Date: Thu, 7 Jul 2011 13:44:18 +0000 Subject: [arin-ppml] ARIN Board consideration of IAB consultation response on 2011-5 Message-ID: <9602B601-458E-4DB9-825D-B9FE3D0C9305@arin.net> The ARIN Board believes that it is not within ARIN's authority to unilaterally make specialized allocations of the sort proposed in 2011-5. The ARIN Board recommends that any efforts in support of such an allocation be directed towards the IETF. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From alh-ietf at tndh.net Thu Jul 7 10:11:00 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 7 Jul 2011 07:11:00 -0700 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <4E1539F7.8030006@umn.edu> References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <0b7901cc3c0d$e3e07040$aba150c0$@net> <0c7e01cc3c4e$a3891f10$ea9b5d30$@net> <4E1539F7.8030006@umn.edu> Message-ID: <0d1101cc3caf$b4b0f0e0$1e12d2a0$@net> David Farmer wrote: > On 7/6/11 21:36 CDT, Tony Hain wrote: > > Jimmy Hess wrote: > .... > >> Each RIR is a facilitator in distributing IP addresses > >> to networks and registries WITHIN that RIR's region. > >> > >> A RIR is not designed to be a facilitator in distributing IP > addresses > >> or setting addressing policy for networks in other regions. > > > > Attempting to rewrite history by asserting an exclusionary mantra > does not > > make it so. Organizations have always been free to join any RIR and > do > > whatever that RIRs policy allows with any space allocated or > assigned. The > > BS exclusionary mindset is a direct product of regional hoarding at > the end > > of the free pool. > > > > This is an exceptionally bad approach to policy, and completely > inconsistent > > with the notion that industry self-regulation is appropriate for > managing > > the valuable global resources of network addressing. If we really are > > looking out for the good-of-the-whole, exclusionary tactics are out > of > > scope. If we really believe exclusionary tactics are appropriate, > bend over > > and get ready for the regulatory oversight that WILL arrive shortly > ... > > > > Tony > > Tony, > > More or less, I want to agree with you. But, how do you justify this > with ICP-2 and the concept of separate service regions. > > http://www.icann.org/en/icp/icp-2.htm I don't see anything in there that says 'exclusion', and the most restrictive language is simply a SHOULD. > > Also, this come from a Policy Experience Report Question from San Juan; > > https://www.arin.net/participate/meetings/reports/ARIN_XXVII/PDF/Monday > /nobile_policy_experience.pdf > > Slides 7 and 8; > > This also plays into the questions of returning of space to IANA, > Inter-RIR transfers, needs based transfers in ARIN and non-needs based > transfers in APNIC, etc... The market will ignore arbitrary attempts of oversight and meddling. An assertion that your needs are greater than mine when I am the one putting money on the table will simply drive all transfers underground. ARIN has to remove itself from fantasy land and recognize that in this case stewardship means documenting what is going on, not attempting to drive the resources to those who continue to insist on the past free access to resources. > > In some ways if ARIN could service anyone globally using its policies, > that might be a good way to deal with a bunch of sticky issues, but at > least on the surface that conflicts with ICP-2. On the other hand, if > you allow that, you can raises a bunch of sticky issues too. Can > someone move all or some of their registrations to another region? What in practice stops this today? Once I have the resources there is nothing that prevents moving them around. Getting more might be an issue, but likely not. The only practical thing that currently is precluded is changing which RIR you pay membership to while attempting to retain a resource pool. > > I don't want to be exclusionary. But then isn't the whole concept of > regional service areas suppose to be at least somewhat exclusionary? > Otherwise what is the meaning of regional service areas in ICP-2? That was a half-baked attempt at routing table constraint, but nobody does aggregation based on RIR. If you want a real geo proxy aggregation model you need something like: http://tools.ietf.org/id/draft-hain-ipv6-geo-addr-02.txt Even so, ICP-2 is revisionist since the big 3 predated it, and their original mission was faciliatory, not exclusionary. The regional protectionism language that is in ICP-2 is more about avoiding the dns registrar fiasco than about precluding an organization from acquiring space from another existing RIR. If operational practice was to aggregate by RIR, and ICP-2 said MUST, I could see it being an impediment. As it is, it is nothing more than a speed bump (and a low one at that). > > When there was an IANA free pool, we could wave our hands mumble > something that sounded good, go to the bar and keep getting rounds of > drinks until no one could remember what the question was. But > something > tells me that trick won't work no more.:) I agree, events have overtaken us. The open question is how we break the tendency to hoard in the face of famine. If we don't, the short term gain will result in a long term loss of the self-regulatory model. Tony > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== From alh-ietf at tndh.net Thu Jul 7 10:11:39 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 7 Jul 2011 07:11:39 -0700 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <125491BE-26B1-47D9-8FBF-D9DF3A22F83E@delong.com> References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <0b7901cc3c0d$e3e07040$aba150c0$@net> <0c7e01cc3c4e$a3891f10$ea9b5d30$@net> <4E1539F7.8030006@umn.edu> <125491BE-26B1-47D9-8FBF-D9DF3A22F83E@delong.com> Message-ID: <0d1201cc3caf$cb9ed830$62dc8890$@net> Owen DeLong wrote: > > When there was an IANA free pool, we could wave our hands mumble > something that sounded good, go to the bar and keep getting rounds of > drinks until no one could remember what the question was. But > something tells me that trick won't work no more.:) > > > > The current IANA free pool is huge. It contains more than 500 /12s each > of which contains more than 1,000,000 /32s. ;) > > Owen From farmer at umn.edu Thu Jul 7 10:15:58 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 07 Jul 2011 09:15:58 -0500 Subject: [arin-ppml] ARIN Board consideration of IAB consultation response on 2011-5 In-Reply-To: <9602B601-458E-4DB9-825D-B9FE3D0C9305@arin.net> References: <9602B601-458E-4DB9-825D-B9FE3D0C9305@arin.net> Message-ID: <4E15BF9E.5040406@umn.edu> On 7/7/11 08:44 CDT, John Curran wrote: > The ARIN Board believes that it is not within ARIN's authority to > unilaterally make specialized allocations of the sort proposed in > 2011-5. The ARIN Board recommends that any efforts in support of such > an allocation be directed towards the IETF. John, I want to thank you and the Board. While i still support the intent of 2011-5, I think the Board is correct. However, where does this leave 2011-5? Is it dead? Is it returned to the AC? Is there a /10 on hold waiting for IETF and IAB action? Forever? Until there is no longer an ARIN free pool? In my opinion these are all important questions when considering the proper disposition for ARIN-prop-154. Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jcurran at arin.net Thu Jul 7 10:24:25 2011 From: jcurran at arin.net (John Curran) Date: Thu, 7 Jul 2011 14:24:25 +0000 Subject: [arin-ppml] ARIN Board consideration of IAB consultation response on 2011-5 In-Reply-To: <4E15BF9E.5040406@umn.edu> References: <9602B601-458E-4DB9-825D-B9FE3D0C9305@arin.net>, <4E15BF9E.5040406@umn.edu> Message-ID: <8DF7479C-A46C-4B30-8A56-7495B3ED4D8C@arin.net> While work is ongoing in the IETF, I am recommending that the Board keep 2011-5 under advisement. As noted previously, I will bring the matter of reserving a /10 for this recommended draft policy to the Board as we approach runout, as by that time we may have more insight into the progress within the IETF. /John John Curran President and CEO ARIN On Jul 7, 2011, at 4:16 PM, "David Farmer" wrote: > > On 7/7/11 08:44 CDT, John Curran wrote: >> The ARIN Board believes that it is not within ARIN's authority to >> unilaterally make specialized allocations of the sort proposed in >> 2011-5. The ARIN Board recommends that any efforts in support of such >> an allocation be directed towards the IETF. > > John, > > I want to thank you and the Board. While i still support the intent of 2011-5, I think the Board is correct. > > However, where does this leave 2011-5? Is it dead? Is it returned to the AC? Is there a /10 on hold waiting for IETF and IAB action? Forever? Until there is no longer an ARIN free pool? > > In my opinion these are all important questions when considering the proper disposition for ARIN-prop-154. > > Thanks. > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== From mike at nationwideinc.com Thu Jul 7 10:40:39 2011 From: mike at nationwideinc.com (Mike Burns) Date: Thu, 7 Jul 2011 10:40:39 -0400 Subject: [arin-ppml] ARIN Board consideration of IAB consultationresponse on 2011-5 References: <9602B601-458E-4DB9-825D-B9FE3D0C9305@arin.net> <4E15BF9E.5040406@umn.edu> Message-ID: <6303B959879E449D8C3B54E76C200579@mike> > John, > > I want to thank you and the Board. While i still support the intent of > 2011-5, I think the Board is correct. > =============================================== > David Farmer Email:farmer at umn.edu > +1 I think we are unfortunately bound to this decision by the MoU and should not subject the idea of Internet self-governance to the stress of feuding organizations at the level of IANA and IETF. I'm sure the Board members feel the pressure from the community but made the right decision. I also have doubts about 154 for the same reason. We engender discord with the IETF. We engender discord with APNIC over their transfer policies. We engender discord with all other registries when we consider regional hoarding policies. All under the rubric of stewardship, or our particular views of stewardship. We are stewards not only of addresses and routing tables, but of a unique governance system which requires tolerance and voluntary cooperation to survive. We could be sowing the seeds of escalating problems which could open the door for government to claim the self governance model can not work in lean times. Mike Burns From bill at herrin.us Thu Jul 7 11:50:38 2011 From: bill at herrin.us (William Herrin) Date: Thu, 7 Jul 2011 11:50:38 -0400 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <0d1101cc3caf$b4b0f0e0$1e12d2a0$@net> References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <0b7901cc3c0d$e3e07040$aba150c0$@net> <0c7e01cc3c4e$a3891f10$ea9b5d30$@net> <4E1539F7.8030006@umn.edu> <0d1101cc3caf$b4b0f0e0$1e12d2a0$@net> Message-ID: On Thu, Jul 7, 2011 at 10:11 AM, Tony Hain wrote: >> >> Each RIR is a facilitator in distributing IP addresses >> >> to networks and registries WITHIN that RIR's region. > I agree, events have overtaken us. The open question is how we break the > tendency to hoard in the face of famine. If we don't, the short term gain > will result in a long term loss of the self-regulatory model. A decade and a half ago, the principals behind APNIC made the case that the global address registry (then the InterNIC) should be replaced with a resource management model which follows geographic borders. We're operating on their plan. If there is a GLOBAL desire to return to a global registry model for any of our number resources, that proposal should come in the front door, not the back. ARIN should not permit itself to become a defacto global registry through the expedient of turning a blind eye to outregion use of ARIN region addresses. As well invite the ITU in and join a competitive registry race to the bottom. I don't like Robert's specific proposal, but I completely agree with the concept. If we're going to remain regional in a world where IP addresses now have a significant dollar value, lets make sure we're actually being regional. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cgrundemann at gmail.com Thu Jul 7 12:01:00 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 7 Jul 2011 10:01:00 -0600 Subject: [arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: References: Message-ID: We are putting the finishing touches on version -01 of this draft now. If you have comments or suggestions please let us know (on or off list) asap - we would love to include them! http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space Thanks again for all of the feedback already received! Cheers, ~Chris On Tue, Jul 5, 2011 at 13:57, Chris Grundemann wrote: > Hello, > > In response to the IAB statement regarding ARIN-2011-5, several of us > have compiled an Internet Draft analyzing the need for shared > transition space. You can find it online here: > http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space. > The current -00 version is a very rough draft thrown together over a > holiday weekend and there is a -01 version forthcoming. It should > however give you a good enough feel for the structure and content of > the document to provide feedback. We plan to attempt to incorporate > feedback from the ARIN community before the draft deadline; 11, July, > so your attention to this early this week is much appreciated. -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From joelja at bogus.com Thu Jul 7 15:54:27 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 7 Jul 2011 12:54:27 -0700 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations) - Staff Comments In-Reply-To: References: <4E0E2034.4080309@arin.net> <9F860722-C8C4-4975-B457-AF370D3CF58B@arin.net> <8632D1C8-E565-4BAF-AA18-D06281AC2457@delong.com> <872C3DD3-BFD3-4253-ACFD-6EFEB204ACC0@arin.net> <61641F73-05E2-4CA9-BFE1-11E3243BA5E6@delong.com> <7FF69C84-98D6-4C77-94A5-6DB4296B86A1@arin.net> <4E13958C.50309@chl.com> <0649FABB-3ABF-4702-AECA-0776B493F23B@delong.com> <4E13B23D.5020905@chl.com> Message-ID: <4D23346F-75D1-446F-9C36-C21D7623B9AD@bogus.com> On Jul 5, 2011, at 7:21 PM, Gary Buhrmaster wrote: > On Wed, Jul 6, 2011 at 00:54, Joe Maimon wrote: > .... >> I simply want to know how you can reserve a /10 specifically for the context >> of 2011-5/pp-154 without letting the cat out of the bag. > > In practice, I just do not think you can keep that cat > bagged over the time frame of IETF deliberations. > The real question would be would anyone use that > /10, knowing that they could be at some risk should it > eventually be used for a real assignment/allocation. > > Is there any sense of the ARIN board as to whether they > could decide to decide at their next meeting whether to > direct a reservation of a final /10, based on the communities > support of 2011-5, so that when the IETF process > completes its work ARIN will be in a position to contribute > that /10 (should the IETF result be aligned with 2011-5)? It is not a foregone conclusion that an IETF outcome is aligned with 2011-5. If it was the previous document would already have passed through the IESG in all likely-hood given that it was tabled for discussion at IETF-79. From farmer at umn.edu Thu Jul 7 16:15:21 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 07 Jul 2011 15:15:21 -0500 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <0b7901cc3c0d$e3e07040$aba150c0$@net> <0c7e01cc3c4e$a3891f10$ea9b5d30$@net> <4E1539F7.8030006@umn.edu> <0d1101cc3caf$b4b0f0e0$1e12d2a0$@net> Message-ID: <4E1613D9.3050309@umn.edu> On 7/7/11 10:50 CDT, William Herrin wrote: > On Thu, Jul 7, 2011 at 10:11 AM, Tony Hain wrote: >>>>> Each RIR is a facilitator in distributing IP addresses >>>>> to networks and registries WITHIN that RIR's region. > >> I agree, events have overtaken us. The open question is how we break the >> tendency to hoard in the face of famine. If we don't, the short term gain >> will result in a long term loss of the self-regulatory model. > > A decade and a half ago, the principals behind APNIC made the case > that the global address registry (then the InterNIC) should be > replaced with a resource management model which follows geographic > borders. We're operating on their plan. If there is a GLOBAL desire to > return to a global registry model for any of our number resources, > that proposal should come in the front door, not the back. But, I think Tony makes a good argument, there was more of a facilitatory intent involved than exclusionary intent in the creation of the RIR system. Things like; service desks in time zones close by, speaking languages used in the region, cultural understanding of the region, organizational governance from within the region, with meetings and other events in the region. I believe these issues were far more important than drawing lines on a map. It was about making things better, not about creating territorial monopolies. > ARIN should not permit itself to become a defacto global registry > through the expedient of turning a blind eye to outregion use of ARIN > region addresses. As well invite the ITU in and join a competitive > registry race to the bottom. > > I don't like Robert's specific proposal, but I completely agree with > the concept. If we're going to remain regional in a world where IP > addresses now have a significant dollar value, lets make sure we're > actually being regional. However, while the intent may have been facilitatory, we did draw lines on the map too. We didn't necessarily have to, but we did. However, in ICP-2 there is a clear intent that these lines should be at "large geographical region of approximately continental size" Tony, is right that ICP-2 is an after-the-fact document, but this seems consistent with the vision of RFC1174; 2.a.1.3. Recommendation .... At a later step, we anticipate that it will be desirable to distribute the IR function among multiple centers, e.g., with centers on different continents. This should be straight-forward once the IR function is divorced from policy enforcement. And with the implementation plan in RFC 1366 and RFC 1466; 2.0 Qualifications for Distributed Regional Registries ..... The distributed regional registry is empowered by the IANA and the IR to provide the network number registration function to a geographic area. It is possible for network subscribers to contact the IR directly. Depending on the circumstances the network subscriber may be referred to the regional registry, but the IR will be prepared to service any network subscriber if necessary. And with RFC 2050; Regional IRs Regional IRs operate in large geopolitical regions such as continents. Currently there are three regional IRs established; InterNIC serving North America, RIPE NCC serving Europe, and AP- NIC serving the Asian Pacific region. Since this does not cover all areas, regional IRs also serve areas around its core service areas. It is expected that the number of regional IRs will remain relatively small. Service areas will be of continental dimensions. In reading through all of this, the lines seem more fuzzy or fungible to me, more a matter of what is convenient than an immutable boundary. So I tend to want to go with Tony's interpretation of these line as being of facilitatory in nature, rather than exclusionary in nature. Or, put another way, the creation of the RIR system was about creating choices and option, not about limiting them. So, this boils down to a simple question; What is the meaning of those line on the map? However, I believe that simple question has to be answered by global consensus, not by regional mandate. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From mysidia at gmail.com Thu Jul 7 23:51:25 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 7 Jul 2011 22:51:25 -0500 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <4E1613D9.3050309@umn.edu> References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <0b7901cc3c0d$e3e07040$aba150c0$@net> <0c7e01cc3c4e$a3891f10$ea9b5d30$@net> <4E1539F7.8030006@umn.edu> <0d1101cc3caf$b4b0f0e0$1e12d2a0$@net> <4E1613D9.3050309@umn.edu> Message-ID: On Thu, Jul 7, 2011 at 3:15 PM, David Farmer wrote: > On 7/7/11 10:50 CDT, William Herrin wrote: >> On Thu, Jul 7, 2011 at 10:11 AM, Tony Hain ?wrote: > But, I think Tony makes a good argument, there was more of a facilitatory > intent involved than exclusionary intent in the creation of the RIR system. There is both a facilitatory and an exclusionary intent inherent to the RIR system, for some definition of exclusionary. But more exclusionary; if you don't have a presence in ARIN region, and want an IP address allocation from ARIN's address space -- I say, your option there should be either, setup a network in the ARIN region, or buy services from a Local Internet Registry (ISP) in the region, but not to obtain ARIN resources, become an ARIN member, and vote the board in a region your organization has no network in. You can read up on ICP2, and the RIR system is not an _inclusionary_ system where anyone who feels they can justify an allocation of resources is free to go demand something from any region they like. It's an inclusionary system where anyone who has a network is covered by some RIR's service region, so every org can participate in developing addressing policy within the appropriate region. This allows addressing policy that reflects the needs of members of each region. And protects members of different regions from any policy desired by many members of other regions, that are not in the global interest, but orgs getting addresses and setting policy in the wrong region would be a deformation of the RIR system. Without the RIR system, large regions could have a very large influence, while the needs of smaller regions are ignored. > However, while the intent may have been facilitatory, we did draw lines on > the map too. ?We didn't necessarily have to, but we did. ? However, in ICP-2 > there is a clear intent that these lines should be at "large geographical RIRs are not in the business of guessing the sum of intent . The requirements of proper stewardship are clear; take steps to preserve the region's resources for networks in the region. Don't encourage obtaining resources from ARIN because the policy might be seen as more lax or more susceptible to manipulation by members of other regions, or other reasons that are not sound technical basis for an out-of-region network to require ARIN region resources. Encourage to obtain resources as fully justified PA allocations from ARIN-based ISP/LIRs instead. -- -JH From narten at us.ibm.com Fri Jul 8 00:53:02 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 08 Jul 2011 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201107080453.p684r21s008164@rotala.raleigh.ibm.com> Total of 89 messages in the last 7 days. script run at: Fri Jul 8 00:53:02 EDT 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 17.98% | 16 | 17.19% | 107992 | bill at herrin.us 15.73% | 14 | 17.82% | 111932 | owen at delong.com 14.61% | 13 | 14.54% | 91376 | jcurran at arin.net 10.11% | 9 | 9.06% | 56912 | mysidia at gmail.com 5.62% | 5 | 6.10% | 38302 | farmer at umn.edu 5.62% | 5 | 4.79% | 30085 | cgrundemann at gmail.com 4.49% | 4 | 5.70% | 35782 | info at arin.net 4.49% | 4 | 4.86% | 30535 | alh-ietf at tndh.net 3.37% | 3 | 2.41% | 15145 | gary.buhrmaster at gmail.com 3.37% | 3 | 2.31% | 14483 | jmaimon at chl.com 2.25% | 2 | 2.32% | 14573 | joelja at bogus.com 2.25% | 2 | 1.93% | 12102 | ppml at rs.seastrom.com 2.25% | 2 | 1.35% | 8482 | matthew at matthew.at 1.12% | 1 | 2.08% | 13081 | matthew.wilder at telus.com 1.12% | 1 | 1.93% | 12127 | lsawyer at gci.com 1.12% | 1 | 1.62% | 10161 | jeffrey.lyon at blacklotus.net 1.12% | 1 | 1.07% | 6695 | scottleibrand at gmail.com 1.12% | 1 | 1.06% | 6685 | bensons at queuefull.net 1.12% | 1 | 1.04% | 6547 | narten at us.ibm.com 1.12% | 1 | 0.84% | 5255 | mike at nationwideinc.com --------+------+--------+----------+------------------------ 100.00% | 89 |100.00% | 628252 | Total From hannigan at gmail.com Fri Jul 8 06:20:15 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 8 Jul 2011 06:20:15 -0400 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <0b7901cc3c0d$e3e07040$aba150c0$@net> References: <4E0E1ED3.3090209@arin.net> <86y60g7mea.fsf@seastrom.com> <0b7901cc3c0d$e3e07040$aba150c0$@net> Message-ID: Not much more needs to be said. Not in favor. Best, -M< On Jul 6, 2011 9:01 PM, "Tony Hain" wrote: > Robert E. Seastrom wrote: >> William Herrin writes: >> >> > On Fri, Jul 1, 2011 at 3:24 PM, ARIN wrote: >> >> ARIN-prop-155 IPv4 Number Resources for Use Within Region >> > >> > Oppose as written. >> >> I wrote this proposal as a starting point, and expected plenty of >> spirited discussion surrounding it. Didn't expect that it would be >> quite so overwhelmingly "oppose", but those are the breaks. > > Were you hoping for something more along the lines of: > "this is nothing more than human nature at its worst, hoarding in the face > of shortage" > > If it is not clear, I oppose as written, as well as the basic premise that > one 'needs to protect a regional asset'. The RIRs were not created to be > islands, they are supposed to be facilitators in distributing the global > address pool asset. The stewardship component of that is intended to > preclude hoarding, not be the basis for regional isolationism. > > It is absolutely absurd that 'the richest' (in context) region should even > have the discussion about how to prevent 'outsiders' from acquiring > resources in the face of famine. Given behavior like this, the appropriate > thing to do is change IANA policy to allow sub-/8 allocations, then recall > all outstanding space and manage the remaining pool under a common policy of > global fulfillment of need. Children fighting over toys in the sandbox are > better behaved ... > > At the end of the day, this policy mindset is unenforceable for future > allocations, and does nothing to preclude an organization with existing > resources from moving those outside the region to use the new ones locally. > Get over it, IPv4 is dead; and being the most obnoxious buzzard that > protects the last of the scraps from others is not 'stewardship'. > > Tony > > >> >> Unfortunately there are no easy answers to a lot of the concerns that >> folks have raised as reasons for opposing it. It would be extremely >> easy to go down the rat-hole of trying to dictate operational >> constraints by making the policy statement 4x as large, and what would >> happen is that ultimately some creative person would figure out a >> loophole and all of our efforts would be for naught until the next >> policy cycle, at which point we'd probably be overtaken by events. >> The Board doesn't like such policy proposals and will surely remand >> them for further discussion, at which point we end up kind of hosed >> because of the aforementioned cycle. >> >> I believe that we ought to have a policy to address the situation you >> elucidate below. That's why I wrote this proposal. Sussing out where >> the community wants to take this (or even if collectively we want to >> ignore the rising tide of opportunities for abuse and just be >> fatalistic about v4 exhaustion) is part of the whole point of the PDP. >> Discussion and modification encouraged. >> >> > However, I do think Robert has identified a legitimate problem. >> >> As much as I would like to take credit for original thought, word on >> the street is that others have already "identified" it. :-( >> >> > It costs less than $5000/year to establish and maintain a US >> > corporation. >> >> It can be done for an order of magnitude less. >> >> > If I'm a French or Japanese telco, what policy stops me from creating >> > a Delaware ISP subsidiary whose sole existence is acquiring ARIN IP >> > addresses and assigning them for well documented use in my European >> or >> > Asian operations? >> >> You tell me. ;-) >> >> cheers, >> >> -r >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Jul 8 09:48:48 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Jul 2011 06:48:48 -0700 Subject: [arin-ppml] ARIN Board consideration of IAB consultationresponse on 2011-5 In-Reply-To: <6303B959879E449D8C3B54E76C200579@mike> References: <9602B601-458E-4DB9-825D-B9FE3D0C9305@arin.net> <4E15BF9E.5040406@umn.edu> <6303B959879E449D8C3B54E76C200579@mike> Message-ID: <2E45B3CD-3D9A-4E75-A5DE-A554A4C21977@delong.com> On Jul 7, 2011, at 7:40 AM, Mike Burns wrote: >> John, >> >> I want to thank you and the Board. While i still support the intent of 2011-5, I think the Board is correct. >> =============================================== >> David Farmer Email:farmer at umn.edu >> > > +1 > > I think we are unfortunately bound to this decision by the MoU and should not subject the idea of Internet self-governance to the stress of feuding organizations at the level of IANA and IETF. > I'm sure the Board members feel the pressure from the community but made the right decision. > I also have doubts about 154 for the same reason. > We engender discord with the IETF. 154 should not engender any discord with IETF, it seeks to have ARIN do what can be done within their process and continue to work within their process to achieve the desired result. > We engender discord with APNIC over their transfer policies. Care to explain how 2011-5 or 154 have anything at all to do with APNIC or their transfer policies? If you're talking about other proposals, then, one could argue that APNIC's transfer policy has engendered discord with the other RIRs, since they currently stand alone as the only RIR to abandon needs-basis in their transfer policy. > We engender discord with all other registries when we consider regional hoarding policies. I don't believe that 154 is a regional hoarding policy. Perhaps you are confused with 155? > All under the rubric of stewardship, or our particular views of stewardship. > We are stewards not only of addresses and routing tables, but of a unique governance system which requires tolerance and voluntary cooperation to survive. > True. However, such a system of governance can also break down if we do not stand up to protect fundamental principles. While I realize APNIC has chosen to abandon it, I still believe that needs basis is a fundamental principle underpinning the management of address space for the internet. There is a big difference between tolerance of regional differences and abandonment of fundamental principles simply because one region chose to do so. > We could be sowing the seeds of escalating problems which could open the door for government to claim the self governance model can not work in lean times. > Fortunately, we are not really facing lean times. We are facing a temporary shortage of one particular resource which will over time become largely irrelevant. Owen From Chuong.D.Pham at team.telstra.com Tue Jul 12 02:04:13 2011 From: Chuong.D.Pham at team.telstra.com (Pham, Chuong D) Date: Tue, 12 Jul 2011 16:04:13 +1000 Subject: [arin-ppml] ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF Message-ID: <5602569641FB314FB4D9AD5659D41B9C237A54937C@WSMSG3154V.srv.dir.telstra.com> Hi, The proposed /10 address range could be used as an additional RFC1918 address block for a medium size service provider without resorting to NAT444 (assume such a service provider has suitably customer growth rate and a good IPv6 migration strategy in place). I propose, if feasible, the range is increased to a /8 to make this option of not resorting to NAT444 to be possible to the larger proportion of medium to medium-large service providers who need the extra Private IPv4 addresses, but not large enough to adopt NAT444. Other than that, I fully support ARIN-prop-154 as written. Please disclose the proposed range as early as possible as we have a pressing need to deploy it in our network. Regards, CP -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Tue Jul 12 10:21:46 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 12 Jul 2011 08:21:46 -0600 Subject: [arin-ppml] UPDATE: ARIN Draft Policy 2011-5: Shared Transition Space Message-ID: A new, much more polished, version of I-D, draft-bdgks-arin-shared-transition-space has been submitted and is available for viewing at: http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-01. This draft will be discussed at IETF 81 alongside I-D, draft-weil-shared-transition-space-request on Wednesday (July 27) morning during the opsawg session . I encourage everyone who has an opinion on this topic to attend, either in person or remotely, and make your voice heard. Thanks again to everyone who contributed and helped get this I-D completed on time. Cheers, ~Chris On Tue, Jul 5, 2011 at 13:57, Chris Grundemann wrote: > Hello, > > In response to the IAB statement regarding ARIN-2011-5, several of us > have compiled an Internet Draft analyzing the need for shared > transition space. You can find it online here: > http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space. > The current -00 version is a very rough draft thrown together over a > holiday weekend and there is a -01 version forthcoming. It should > however give you a good enough feel for the structure and content of > the document to provide feedback. We plan to attempt to incorporate > feedback from the ARIN community before the draft deadline; 11, July, > so your attention to this early this week is much appreciated. > > Cheers, > ~Chris > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From jcurran at arin.net Tue Jul 12 10:40:22 2011 From: jcurran at arin.net (John Curran) Date: Tue, 12 Jul 2011 14:40:22 +0000 Subject: [arin-ppml] UPDATE: ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: References: Message-ID: <10F0542E-71E0-4DE8-8F75-FA0F555C0944@arin.net> On Jul 12, 2011, at 10:21 AM, Chris Grundemann wrote: > A new, much more polished, version of I-D, > draft-bdgks-arin-shared-transition-space has been submitted and is > available for viewing at: > http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-01. > > This draft will be discussed at IETF 81 alongside I-D, > draft-weil-shared-transition-space-request on Wednesday (July 27) > morning during the opsawg session > . I encourage everyone who has > an opinion on this topic to attend, either in person or remotely, and > make your voice heard. > > Thanks again to everyone who contributed and helped get this I-D > completed on time. > > Cheers, > ~Chris For avoidance of doubt, I will note that I supplied the following text for the revised draft: > 7. IANA Considerations > > Upon notification by the IAB that that an address reservation should > be made, ARIN is willing to proceed with the implementation of its > Draft Policy 2011-5 which would result in ARIN reserving IPv4 /10 > block for shared transition. The IANA is to record the allocation of > the IPv4 address block for this purpose. Alternatively, the IAB may > direct the IANA to request return of sufficient address space from > ARIN's available IPv4 number resource pool to allow the IANA to > perform this reservation directly. To the best of my knowledge, this text reflects the readily available options for implementation of Draft Policy 2011-5. FYI, /John John Curran President and CEO ARIN From info at arin.net Tue Jul 12 16:53:52 2011 From: info at arin.net (ARIN) Date: Tue, 12 Jul 2011 16:53:52 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - June 2011 In-Reply-To: <4E0A13F6.9020605@arin.net> References: <4E0A13F6.9020605@arin.net> Message-ID: <4E1CB460.7020402@arin.net> > The AC abandoned proposals 148 and 150. Anyone dissatisfied with these > decisions may initiate a petition. The petition to advance these > proposals would be the "Discussion Petition." The deadline to begin a > petition will be five business days after the AC's draft meeting > minutes are published. The deadline for petitions is 19 July 2011. The AC's draft minutes of their 23 June 2011 meeting are available at: https://www.arin.net/about_us/ac/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 6/28/11 1:48 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process the ARIN Advisory > Council (AC) held a meeting in June 2011 and made decisions about > several proposals. > > The following proposals have been added to the AC's docket for > development and evaluation: > > ARIN-prop-149 Improved Transparency for Directed Transfers > ARIN-prop-151 Limiting needs requirements for IPv4 Transfers > ARIN-prop-152 RSA Modification Limits > ARIN-prop-153 Correct erroneous syntax in NRPM 8.3 > > The AC abandoned the following proposals: > > ARIN-prop-148 LRSA resources must not be transferred to LRSA > ARIN-prop-150 Reclamation Hold > > Proposal 148 was abandoned because the majority of the AC members feel > that which legal agreement ARIN uses with a resource requester is a > business matter. It is indeed the case, however, that if the community > feels there should be certain policy requirements for what is in an > RSA, LRSA or similar document that those could be specified in policy. > This would require ARIN to put those items in any agreement where > applicable and allowed by law. The AC felt that ARIN-prop-152 was an > example of such a policy proposal, and voted to accept it onto the > AC's docket for further development. > > The Advisory Council has abandoned Proposal 150 based on the merits of > the proposal and the author's stated desired to have it withdrawn. > > The AC thanks the authors and the community for their continuing effort > and contributions to these and all other policy considerations. > > The AC abandoned proposals 148 and 150. Anyone dissatisfied with these > decisions may initiate a petition. The petition to advance these > proposals would be the "Discussion Petition." The deadline to begin a > petition will be five business days after the AC's draft meeting > minutes are published. For more information on starting and > participating in petitions, see PDP Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > From mysidia at gmail.com Tue Jul 12 22:44:42 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 12 Jul 2011 21:44:42 -0500 Subject: [arin-ppml] UPDATE: ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: <10F0542E-71E0-4DE8-8F75-FA0F555C0944@arin.net> References: <10F0542E-71E0-4DE8-8F75-FA0F555C0944@arin.net> Message-ID: On Tue, Jul 12, 2011 at 9:40 AM, John Curran wrote: >> ? ?Upon notification by the IAB that that an address reservation should >> ? ?be made, ARIN is willing to proceed with the implementation of its >> ? ?Draft Policy 2011-5 which would result in ARIN reserving IPv4 /10 >> ? ?block for shared transition. ?The IANA is to record the allocation of >> ? ?the IPv4 address block for this purpose. ?Alternatively, the IAB may >> ? ?direct the IANA to request return of sufficient address space from >> ? ?ARIN's available IPv4 number resource pool to allow the IANA to >> ? ?perform this reservation directly. > To the best of my knowledge, this text reflects the readily available > options for implementation of Draft Policy 2011-5. Has ARIN considered the possibility of implementing 2011-5 using an experimental activity resource allocation, similar to that provided under section 11 of the NRPM (but without the requirements), or other type of resource allocation? 2011-05 states a "rationale" for allocating a /10, but actually ARIN does not need a "rationale" to reserve addresses; a "reason" for the reservation does not need to be indicated in the policy. In the same way ARIN can choose to reserve a /16 "for critical infrastructure"; ARIN can reserve a /10 for "address extension"; with exact intended purpose to be determined later. 2011-05 could be revised to merely state: "A second contiguous /10 IPv4 block will be reserved to facilitate future IPv4 address extension. This block will not be allocated or assigned to any organization, but will be indicated as reserved." The rest of the paragraph could be crossed out, and then the IAB would have no basis for objecting to ARIN's action of indicating a reserved block, because it will merely show as a permanently reserved /10, for no purpose in particular. Address resource policy does not NEED to explain or indicate an exact intended use for the block. An experimental allocation would also seem to accomplish 2011-05, and not exceed ARIN's authority, as ARIN already has a policy that allows ARIN to issue experimental allocations. "A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 address extension." "This block will not be allocated or assigned to any single organization, " If there are technical issues to be determined, it would seem any use of the suggested allocation would be experimental in nature. Because there is no internet standard that would utilize the shared address space, any use of it for shared purpose, would be inherently "experimental" or "unofficial". -- -JH From jcurran at arin.net Tue Jul 12 23:02:16 2011 From: jcurran at arin.net (John Curran) Date: Wed, 13 Jul 2011 03:02:16 +0000 Subject: [arin-ppml] UPDATE: ARIN Draft Policy 2011-5: Shared Transition Space In-Reply-To: References: <10F0542E-71E0-4DE8-8F75-FA0F555C0944@arin.net> Message-ID: On Jul 12, 2011, at 10:44 PM, Jimmy Hess wrote: > The rest of the paragraph could be crossed out, and then the IAB would > have no basis for objecting to ARIN's action of indicating a reserved > block, because it will merely show as a permanently reserved /10, > for no purpose in particular. Jimmy - I have not looked into this option, as the Board urged that we collaborate with (rather than circumvent) the IETF. /John John Curran President and CEO ARIN From info at arin.net Wed Jul 13 15:46:04 2011 From: info at arin.net (ARIN) Date: Wed, 13 Jul 2011 15:46:04 -0400 Subject: [arin-ppml] Board Adopts Draft Policies Message-ID: <4E1DF5FC.50709@arin.net> On 10 June 2011 the ARIN Board of Trustees adopted the following policies: ARIN-2011-3: Better IPv6 Allocations for ISPs ARIN-2011-4: Reserved Pool for Critical Infrastructure ARIN-2011-6: Returned IPv4 Addresses 2011-3 will be implemented no later than 15 February 2012. This is in accordance with the staff assessment that rated the resource impact of this policy as moderate, requiring six to nine months to implement. 2011-4 and 2011-6 will be implemented no later than 31 July 2011. Board of Trustees Meeting Minutes are available at: https://www.arin.net/about_us/bot/index.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri Jul 15 00:53:02 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 15 Jul 2011 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201107150453.p6F4r2t9032183@rotala.raleigh.ibm.com> Total of 10 messages in the last 7 days. script run at: Fri Jul 15 00:53:02 EDT 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.00% | 2 | 15.65% | 11182 | info at arin.net 20.00% | 2 | 15.17% | 10837 | jcurran at arin.net 10.00% | 1 | 21.53% | 15383 | hannigan at gmail.com 10.00% | 1 | 10.55% | 7539 | mysidia at gmail.com 10.00% | 1 | 10.37% | 7408 | chuong.d.pham at team.telstra.com 10.00% | 1 | 10.01% | 7154 | owen at delong.com 10.00% | 1 | 8.72% | 6227 | narten at us.ibm.com 10.00% | 1 | 7.99% | 5708 | cgrundemann at gmail.com --------+------+--------+----------+------------------------ 100.00% | 10 |100.00% | 71438 | Total From scottleibrand at gmail.com Thu Jul 21 17:00:03 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 21 Jul 2011 14:00:03 -0700 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: <4E0E1ED3.3090209@arin.net> References: <4E0E1ED3.3090209@arin.net> Message-ID: For many of the reasons others have expressed already, I oppose this proposal text. However, I do believe it is important to discuss this issue before it is overtaken by events, so that ARIN knows what the community feels is the right thing to do. Instead of the blanket prohibition against out-of-region use proposed in this text, I would prefer we modify it to a threshold more like 50%, which would read something like this: These IPv4 addresses are issued primarily for use in networks within the ARIN region. Organizations requesting IPv4 addresses from ARIN must provide documentation to demonstrate that the majority of addresses received will be used to number customers/devices within the ARIN region and must agree to use the addresses accordingly. This requirement shall be binding only on number resources requested after its ratification by the ARIN Board of Trustees. -Scott On Fri, Jul 1, 2011 at 12:24 PM, ARIN wrote: > ARIN-prop-155 IPv4 Number Resources for Use Within Region > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > ## * ## > > Policy Proposal Name: IPv4 Number Resources for Use Within Region > > Proposal Originator: Robert Seastrom > > Proposal Version: 1.0 > > Date: 2011-07-01 > > Proposal type: ?NEW > > Policy term: PERMANENT > > Policy statement: > > Insert the following text in the NRPM: > > 4.2.1.7 - Presence within the ARIN region > > These IPv4 addresses are issued solely for use in networks within the > ARIN region. Organizations requesting IPv4 addresses from ARIN must > provide documentation to demonstrate the addresses will be used to > number customers/devices within the ARIN region and must agree to use > the addresses solely for that purpose. ?This requirement shall be > binding only on number resources requested after its ratification by > the ARIN Board of Trustees. > > > 4.3.7 - Presence within the ARIN region > > These IPv4 addresses are issued solely for use in networks within the > ARIN region. Organizations requesting IPv4 addresses from ARIN must > provide documentation to demonstrate the addresses will be used to > number customers/devices within the ARIN region and must agree to use > the addresses solely for that purpose. ?This requirement shall be > binding only on number resources requested after its ratification by > the ARIN Board of Trustees. > > Rationale: > > ICANN's ICP-2 document established a framework for _regional_ > Internet registries, each to serve a well-defined geographically > scoped constituency. > > The various RIRs will exhaust their free-pools at different times. > This creates a situation in which requesting organizations attempt an > end-run on ICP-2 and the RIR framework by coming directly to ARIN for > space to use outside the ARIN region. ?In other cases, subsidiaries, > sister organizations located within the ARIN region, or global > organizations headquartered within the ARIN region have requested > space that is ultimately destined for use outside the ARIN region. > > Failure to address this situation in a timely fashion will grant an > unfair advantage to large multinationals who will be able to "shop > around" ?requests for space and hasten RIR free pool runout in the ARIN > region. > > Leaving this loophole unaddressed is incompatible with ARIN's > principle of stewardship. > > This problem is not unique to ARIN. ?Similar proposals are under > consideration in the LACNIC and AfriNIC regions. > > Timetable for implementation: ?Immediate > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From narten at us.ibm.com Fri Jul 22 00:53:02 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 22 Jul 2011 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201107220453.p6M4r2Jl015631@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Jul 22 00:53:02 EDT 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 62.94% | 9442 | scottleibrand at gmail.com 50.00% | 1 | 37.06% | 5559 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 15001 | Total From JOHN at egh.com Fri Jul 22 18:05:19 2011 From: JOHN at egh.com (John Santos) Date: Fri, 22 Jul 2011 18:05:19 -0400 Subject: [arin-ppml] ARIN Board consideration of IAB consultationresponse on 2011-5 In-Reply-To: <2E45B3CD-3D9A-4E75-A5DE-A554A4C21977@delong.com> Message-ID: <1110722174250.1655A-100000@Ives.egh.com> I've been away for a couple of weeks, but it doesn't appear anyone has responded to this... On Fri, 8 Jul 2011, Owen DeLong wrote: > > On Jul 7, 2011, at 7:40 AM, Mike Burns wrote: > > >> John, > >> > >> I want to thank you and the Board. While i still support the intent > >> of 2011-5, I think the Board is correct. > >> =============================================== > >> David Farmer Email:farmer at umn.edu > >> > > > > +1 > > > > I think we are unfortunately bound to this decision by the MoU and > > should not subject the idea of Internet self-governance to the stress of > > feuding organizations at the level of IANA and IETF. > > I'm sure the Board members feel the pressure from the community but > > made the right decision. > > I also have doubts about 154 for the same reason. > > We engender discord with the IETF. > I think Mike is referring to ARIN stepping on the IETF's toes by reserving space and implicitly threatening to go it alone using it even if the IETF ultimately decides to do nothing. > 154 should not engender any discord with IETF, it seeks to have ARIN do > what can be done > within their process and continue to work within their process to > achieve the desired result. > > > We engender discord with APNIC over their transfer policies. > > Care to explain how 2011-5 or 154 have anything at all to do with APNIC > or their transfer policies? I think Mike was listing other potential activities which might cause discord among the various cooperating entities involved in Internet governance, and advising against such, at least when avoidable. > > If you're talking about other proposals, then, one could argue that > APNIC's transfer policy has > engendered discord with the other RIRs, since they currently stand alone > as the only RIR to > abandon needs-basis in their transfer policy. > Agree. > > We engender discord with all other registries when we consider > > regional hoarding policies. > > I don't believe that 154 is a regional hoarding policy. Perhaps you are > confused with 155? 155 is another example of discord-producing policy. > > > All under the rubric of stewardship, or our particular views of > > stewardship. > > We are stewards not only of addresses and routing tables, but of a > > unique governance system which requires tolerance and voluntary > > cooperation to survive. > > > > True. However, such a system of governance can also break down if we do > not stand up to > protect fundamental principles. While I realize APNIC has chosen to > abandon it, I still believe > that needs basis is a fundamental principle underpinning the management > of address > space for the internet. There is a big difference between tolerance of > regional differences > and abandonment of fundamental principles simply because one region > chose to do so. I think this is exactly what needs to be balanced when deciding when to go along for the sake of harmony versus doing something different because we need to. > > > We could be sowing the seeds of escalating problems which could open > > the door for government to claim the self governance model can not > > work in lean times. > > > > Fortunately, we are not really facing lean times. We are facing a > temporary shortage > of one particular resource which will over time become largely irrelevant. > > Owen If as John Curran recently said, ARIN can reserve a /10 for shared infrastructure use without an explicit policy, pending IETF action, and that this will prevent the ugly scenario of the IETF publishing an enabling RFC and ARIN (or the IANA or another RIR) not being able to supply a /10 to make it usable, then I'm fine. Also agree this all goes away when IPv6 becomes the default. (Now back to breaking our internal SMTP/POP/IMAP server by attempting to enable IPv6 on it...) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From farmer at umn.edu Sun Jul 24 17:58:44 2011 From: farmer at umn.edu (David Farmer) Date: Sun, 24 Jul 2011 16:58:44 -0500 Subject: [arin-ppml] ARIN-prop-155 IPv4 Number Resources for Use Within Region In-Reply-To: References: <4E0E1ED3.3090209@arin.net> Message-ID: <4E2C9594.4020803@umn.edu> On 7/21/11 16:00 CDT, Scott Leibrand wrote: > For many of the reasons others have expressed already, I oppose this > proposal text. However, I do believe it is important to discuss this > issue before it is overtaken by events, so that ARIN knows what the > community feels is the right thing to do. I too cannot support this policy as written, but also believe it is necessary for us to discuss this issue in Philly. > Instead of the blanket prohibition against out-of-region use proposed > in this text, I would prefer we modify it to a threshold more like > 50%, which would read something like this: I would characterize the policy intent I would want to see as "new resources allocated from ARIN should be mostly used within the ARIN region", but I don't interpret that as meaning that 50% should be used within the ARIN region. I think that means the usage within the ARIN region should be larger than any other individual region. Today with globalization, I could see a someone claiming ARIN as their home region and still have more total resources in use outside the region. But for ARIN to be their home region then the ARIN region should be the largest single region where their resources are used. I think this would be especially relevant for multinational corporations getting direct assignments from ARIN, but probably ISP too. So I would suggest wording something like; "IPv4 addresses obtained from ARIN may be used within another RIR's region. However, use within any other individual RIR's region must not exceed the use within the ARIN region." So as an example, I could see a multinational company based in the US or Canada having resources from ARIN and use its resources among the regions as follows; 30% ARIN, 30% APNIC, 25% RIPE, 10% LACNIC, 5% AfriNIC Most of the resources are not used within the ARIN region, but none of the use in the other regions exceeds the use in the ARIN region. To me this seems like a reasonable requirement for use of resources from the ARIN region, without being overly restrictive, this could possibly even work for IPv6 addresses too. Furthermore, it maintains a logical reason to have regions in the first place. Finally, I don't think this should create a problem for any organization that really thinks of itself as primarily an organization from the ARIN region. If that seems to wishy-washy, then I could also go with something like "use must be no less than X% in the ARIN region, and use within any other individual RIR's region must not exceed the use within the ARIN region." Where X equals something like 25, 30, or 35%. But, requiring 50% usage within the ARIN region doesn't seem to take into account the realities of globalization today. > These IPv4 addresses are issued primarily for use in networks within > the ARIN region. Organizations requesting IPv4 addresses from ARIN > must provide documentation to demonstrate that the majority of > addresses received will be used to number customers/devices within the > ARIN region and must agree to use the addresses accordingly. This > requirement shall be binding only on number resources requested after > its ratification by the ARIN Board of Trustees. > > -Scott > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From info at arin.net Tue Jul 26 15:34:49 2011 From: info at arin.net (ARIN) Date: Tue, 26 Jul 2011 15:34:49 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - July 2011 Message-ID: <4E2F16D9.7090601@arin.net> In accordance with the ARIN Policy Development Process, the ARIN Advisory Council (AC) held a meeting on 21 July 2011 and made decisions about several proposals. The AC selected the following proposal as a draft policy for adoption discussion online and at the ARIN XXVIII Public Policy Meeting in Philadelphia in October. The draft policy will be posted shortly to the PPML. ARIN-prop-141 Combined M&A and Specified Transfers The following proposals have been added to the AC's docket for development and evaluation: ARIN-prop-155 IPv4 Number Resources for Use Within Region The AC abandoned the following proposals: ARIN-prop-140 Business Failure Clarification ARIN-prop-154 Shared Space for IPv4 Address Extension (w/ IETF considerations) Regarding proposal 140: Having reviewed the proposal - and underlying policy that is the subject of the proposal - the AC agrees with the staff assessment [included below] that existing policy does not require clarification. Existing policy is well-understood and utilized by the ARIN community. Furthermore, the proposal text is confusing to many and would not have resulted in clearer policy. If there is in fact a problem to be remedied, the AC encourages further conversation to bring it to light, so that the community can address it more directly. The ARIN AC voted to abandon Proposal 154 because it considered the policy to be redundant considering the Board of Trustees has this same recommendation still on its table from policy 2011-5. The AC will continue to monitor events related to this policy concept as they develop from the Board of Trustees, the IAB, and the IETF. The AC thanks the authors and the community for their continuing effort and contributions to these and all other policy considerations. The AC abandoned proposals 140 and 154. Anyone dissatisfied with these decisions may initiate a petition. The petition to advance these proposals would be the "Discussion Petition." The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Staff Assessment Proposal 140 Business Failure Clarification Date of Assessment: 13 July 2011 1. Proposal Summary (Staff Understanding) This proposal changes existing NRPM section 8.1 (Transfer) Principles to state that any business that ceases to exist should notify ARIN as soon as possible so that the number resources can be returned to ARIN. 2. Comments A. ARIN Staff Comments Current implementation of this policy is that when an organization goes out of business or ceases to exist, the registered POC cannot ?sell, transfer, assign, or give the number resource to any other person or organization? and must notify ARIN of the business dissolution. ? Based on staff experience, the existing policy language has been well understood and utilized by the ARIN community since it was first implemented. ? Therefore, this proposal may be unnecessary since it appears to address a non-existent problem. B. ARIN General Counsel Pending 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ? Updated guidelines ? Staff training 4. Proposal Text Policy statement: Modify Section 8.1. Strike "Thus, if a company goes out of business" and replace with "If an organization ceases to exist". Replace "must notify ARIN if a business fails" with "should notify ARIN that the oganization has ceased to exist". the resultant text: "Number resources are issued, based on justified need, to organizations, not to individuals representing those organizations. If an organization ceases to exist, regardless of the reason, the point of contact (POC) listed for the number resource does not have the authority to sell, transfer, assign, or give the number resource to any other person or organization. If a transfer is not promptly requested and justified, the POC should notify ARIN that the organization has ceased to exist so the assigned number resources can be returned to the available pool of number resources." Rationale: Potential confusion exists over the requirement to return address space from a bankrupt entity. This is a needed clarification to the policy manual. This text removes any mention of special treatment of bankrupt entities that was mentioned in version 1 and which may not comply with law. "must notify" is replaced with "should notify" in order to reflect that the POC may not have the authority or permission to make the notification. From info at arin.net Tue Jul 26 15:41:01 2011 From: info at arin.net (ARIN) Date: Tue, 26 Jul 2011 15:41:01 -0400 Subject: [arin-ppml] Draft Policy 2011-8 Combined M&A and Specified Transfers Message-ID: <4E2F184D.6070405@arin.net> Draft Policy ARIN-2011-8 Combined M&A and Specified Transfers On 21 July 2011 the ARIN Advisory Council (AC) selected "Combined M&A and Specified Transfers" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Philadelphia in October. The draft was developed by the AC from policy proposal "ARIN-prop-141 Combined M&A and Specified Transfers." Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Draft Policy ARIN-2011-8 is below and can be found at: https://www.arin.net/policy/proposals/2011_8.html You are encouraged to discuss Draft Policy 2011-8 on the PPML prior to the October Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-8 Combined M&A and Specified Transfers Date/version: 26 July 2011 Policy statement: To section 8.2 change "... ARIN will work with the resource holder(s) to return, aggregate, or reclaim resources as appropriate via the processes outlined in current ARIN policy (for example, sections 4.6, 4.7, or 12 of the NRPM)." to "...ARIN will work with the resource holder(s) to return, aggregate, transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy." Rationale: Given that both M&A transfers and specified transfers are possible, it should be possible to execute a combined transfer in which unneeded resources are transferred via 8.3 (rather than returning unneeded resources to the free pool) and the rest are transferred via 8.2. Doing this in the wrong order (i.e., attempting to execute the 8.2 transfer first) should not penalize the transferring entity... especially as ARIN's opinion as to what is "no longer justified under ARIN policy" is best known by ARIN and may not be completely knowable by the transferring entity. Note that as there is no ARIN policy permitting IPv6 specified transfers, this policy would only affect IPv4 resources at this time. Timetable for implementation: immediate ##### STAFF ASSESSMENT Proposal: ?Combined M&A and Specified Transfers? Date of Assessment: 12 July 2011 1. Proposal Summary (Staff Understanding) This policy offers a second option to 8.2 transfers where the IP addresses being transferred are underutilized. The new text would allow the transferor to request an 8.3 transfer of the unused portions, in lieu of the addresses being reclaimed and put into the free pool. 2. Comments A. ARIN Staff Comments This proposal would fill a gap in the existing policy and would likely benefit the community. B. ARIN General Counsel Pending 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ? Updated guidelines ? Staff training 4. Proposal Text Policy statement: To section 8.2 change "... ARIN will work with the resource holder(s) to return, aggregate, or reclaim resources as appropriate via the processes outlined in current ARIN policy (for example, sections 4.6, 4.7, or 12 of the NRPM)." to "...ARIN will work with the resource holder(s) to return, aggregate, transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy." Rationale: Given that both M&A transfers and specified transfers are possible, it should be possible to execute a combined transfer in which unneeded resources are transferred via 8.3 (rather than returning unneeded resources to the free pool) and the rest are transferred via 8.2. Doing this in the wrong order (i.e., attempting to execute the 8.2 transfer first) should not penalize the transferring entity... especially as ARIN's opinion as to what is "no longer justified under ARIN policy" is best known by ARIN and may not be completely knowable by the transferring entity. Note that as there is no ARIN policy permitting IPv6 specified transfers, this policy would only affect IPv4 resources at this time. New text removes references to other NRPM sections by number, shortens text by inlining the transfer option. From info at arin.net Wed Jul 27 12:02:03 2011 From: info at arin.net (ARIN) Date: Wed, 27 Jul 2011 12:02:03 -0400 Subject: [arin-ppml] =?windows-1252?q?NRPM_2011=2E3_=96_New_Policy_Impleme?= =?windows-1252?q?nted?= Message-ID: <4E30367B.3060706@arin.net> A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2011.3 is effective 27 July 2011 and supersedes the previous version. NRPM 2011.3 contains the implementation of the following policies: ARIN-2011-4: Reserved Pool for Critical Infrastructure ARIN-2011-6: Returned IPv4 Addresses Both of these policies were adopted by the ARIN Board on 10 June 2011. Board minutes are available at: https://www.arin.net/about_us/bot/index.html The NRPM is available at: https://www.arin.net/policy/nrpm.html Draft policies and proposals are available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri Jul 29 00:53:03 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 29 Jul 2011 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201107290453.p6T4r3Mh000705@rotala.raleigh.ibm.com> Total of 6 messages in the last 7 days. script run at: Fri Jul 29 00:53:03 EDT 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 3 | 51.15% | 22143 | info at arin.net 16.67% | 1 | 19.09% | 8265 | farmer at umn.edu 16.67% | 1 | 17.81% | 7711 | john at egh.com 16.67% | 1 | 11.95% | 5171 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 6 |100.00% | 43290 | Total From scottleibrand at gmail.com Fri Jul 29 15:46:54 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 29 Jul 2011 12:46:54 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - July 2011 In-Reply-To: <4E2F16D9.7090601@arin.net> References: <4E2F16D9.7090601@arin.net> Message-ID: As usual, some of my personal opinions about the AC's actions (and some relevant context) are included inline below. This one's pretty short. :-) On Tue, Jul 26, 2011 at 12:34 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process, the ARIN Advisory > Council (AC) held a meeting on 21 July 2011 and made decisions about several > proposals. > > The AC selected the following proposal as a draft policy for adoption > discussion online and at the ARIN XXVIII Public Policy Meeting in > Philadelphia in October. The draft policy will be posted shortly to the > PPML. > > ?ARIN-prop-141 Combined M&A and Specified Transfers Support. > The following proposals have been added to the AC's docket for > development and evaluation: > > ?ARIN-prop-155 IPv4 Number Resources for Use Within Region I already posted my opinion on this one. While I oppose the current text, I think it needs to be discussed in Philly. > The AC abandoned the following proposals: > > ?ARIN-prop-140 Business Failure Clarification > ?ARIN-prop-154 Shared Space for IPv4 Address Extension (w/ IETF > considerations) > > Regarding proposal 140: Having reviewed the proposal - and underlying policy > that is the subject of the proposal - the AC agrees with the staff > assessment [included below] that existing policy does not require > clarification. Existing policy is well-understood and utilized by the ARIN > community. Furthermore, the proposal text is confusing to many and would not > have resulted in clearer policy. If there is in fact a problem to be > remedied, the AC encourages further conversation to bring it to light, so > that the community can address it more directly. > > The ARIN AC voted to abandon Proposal 154 because it considered the policy > to be redundant considering the Board of Trustees has this same > recommendation still on its table from policy 2011-5. The AC will continue > to monitor events related to this policy concept as they develop from the > Board of Trustees, the IAB, and the IETF. > > The AC thanks the authors and the community for their continuing effort > and contributions to these and all other policy considerations. Agreed. In addition, it's worth noting that the IETF draft linked to 2011-5 seems to be moving along well through the IETF's process. -Scott From jcurran at arin.net Sat Jul 30 10:41:20 2011 From: jcurran at arin.net (John Curran) Date: Sat, 30 Jul 2011 14:41:20 +0000 Subject: [arin-ppml] Reminder - It's the last week of the Global IPv6 Survey References: <4E2D6897.4090203@arin.net> Message-ID: <3CF870B7-A5E5-4835-B0F8-34E07FB3DC3D@arin.net> ARIN PPML Community - Apologies for the cross-post, but it's important to get an accurate gauge of the state of IPv6 in the Internet community. If you have not had time to complete the Global IPv6 survey being done by the Regional Internet Registries, it would be good if you could take the time to do so asap. We're going to keep it open a little while longer past the original 31 July date, but I do not yet know how long, so time is of the essence. You can find specific details on how to participate in the attached message. Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-announce] It's the last week of the Global IPv6 Survey Date: July 25, 2011 8:59:03 AM EDT To: > On 1 July 2011, the 2011 IPv6 Deployment Monitoring Survey opened, and so far 161 individuals in the ARIN region have completed the survey. We thank those who have participated to date, but we need a much bigger response if we hope to achieve a comprehensive view of present IPv6 penetration and future plans for IPv6 deployment. Thus far our regional response rate is significantly behind where we were at this point last year, and we are counting on you to get us back on track! If you have not yet participated, we urge you to do so today. The survey is available at http://www.surveymonkey.com/s/GlobalIPv6survey2011. Your feedback is crucial to expanding the understanding of where the Internet community is moving, and what can be done to ensure readiness for the widespread adoption of IPv6. The survey is composed of 23 questions and can be completed in about 15 minutes. For those without IPv6 allocations or assignments, or who have not yet deployed IPv6, the questions will be fewer in number. ARIN will be sharing the results of the 2011 IPv6 Deployment Monitoring Survey, but if you are curious about the results for the 2010 Global IPv6 Deployment Monitoring Survey you can view them at: http://www.ipv6monitoring.eu/reports/Global%20IPv6%20Survey%20Summary%20v2.pdf The survey will close on 31 July 2011. On behalf of ARIN and GNKS Consulting, we thank you for your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to info at gnksconsult.com. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: