I too oppose this proposal. Let's be really clear here. The more appropriate venue is/was the IETF and the IETF turned it down. It was also brought up in the APNIC region and that region also turned it down. <div><br>
</div><div>----Cathy</div><div>ps. here is the link to the proposal in the APNIC region</div><div><a href="http://mailman.apnic.net/mailing-lists/sig-policy/archive/2008/01/msg00055.html">http://mailman.apnic.net/mailing-lists/sig-policy/archive/2008/01/msg00055.html</a></div>
<div><br></div><div><div class="gmail_quote">On Tue, Apr 19, 2011 at 2:44 PM, Martin Hannigan <span dir="ltr"><<a href="mailto:hannigan@gmail.com">hannigan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Wes,<br>
<br>
I did not vote to move this proposal forward. I agreed that I thought<br>
that there was need, but I disagreed that this was the best and most<br>
fair way to satisfy that need.<br>
<br>
I felt that it was unfair to the community to come in at the last<br>
moment after a more appropriate venue had opted not to slice out<br>
addresses for this purpose and saddle the region with this<br>
requirement. With regards to your sunset idea, we're effectively<br>
creating private address space adjunct to RFC 1918 which will<br>
permanently scorch this set of addresses whether it is formally part<br>
of any private address RFC or not. It would've been "better" to have<br>
provided it from the IANA pool to create a more even burden, but it is<br>
what it is. Aside from the "proper" channel, I would have much<br>
preferred that they obtained these addresses quietly and in a manner<br>
that might have allowed us to save them later such as privately<br>
acquiring them.<br>
<br>
Using legacy addresses available for sale could have accomplished this<br>
same fulfillment and been better for the overall community and<br>
possibly addressed more of your concerns. Even so, there's still no<br>
guarantee that this is going to be fulfilled if it moves forward. Stay<br>
tuned for consultations with the standards bodies on implementation.<br>
<br>
So, YES on need, NO on methodology.<br>
<br>
Best,<br>
<font color="#888888"><br>
-M<<br>
</font><div class="im"><br>
<br>
<br>
<br>
On Tue, Apr 19, 2011 at 4:14 PM, George, Wes E IV [NTK]<br>
<<a href="mailto:Wesley.E.George@sprint.com">Wesley.E.George@sprint.com</a>> wrote:<br>
</div><div><div></div><div class="h5">> This policy is not ready for adoption in its current form.<br>
> I appear to be in the minority in my opposition to this policy, so my comments below are intended to improve the policy under the<br>
> assumption that it will most likely be adopted in some form. However, I strongly believe that it needs to be put back on the docket<br>
> for discussion in the next meeting, since my concerns would dictate some substantive and potentially controversial changes.<br>
><br>
> First, the current text does not reflect the valid concerns raised in discussion in PR about a lack of enforcement.<br>
> Specifically, it does not include any guidance to ARIN staff eliminating the intended uses for this space (NAT inside pools aka IPv4<br>
> address extension) as valid justifications for standard address space allocations, meaning that there is no guarantee that SPs will<br>
> actually use it for its intended purpose until they are no longer able to obtain address space via normal means.<br>
> I am not advocating that we *require* SPs to use NATs + shared space and prevent them from justifying space in a Business as Usual<br>
> manner for their customer growth. However, I *am* advocating that staff explicitly asks if the space being requested is for use in<br>
> numbering inside NAT pools, or if part of the 80% utilization is allocated to the same, and if so, deny the request and refer them<br>
> to the shared space set aside for that use. If we're going to carve out shared space for a specific purpose, then it needs to not be<br>
> optional for that purpose.<br>
> Supporters have been quick to say that this space is being reserved for a narrow application and not a general application like an<br>
> extension of RFC1918, and so if this is the case, then we should be providing clear guidance to staff on this matter.<br>
><br>
> Also, the text "until connected networks fully support IPv6" is unclear. Does this mean that this block is only reserved until such<br>
> time that the network using the space has completed its IPv6 deployment? How would that be determined? I think that's probably not<br>
> what the author intended, since even once IPv6 is available in a given SP network, that won't eliminate the need to continue<br>
> supporting IPv4-only devices and networks. If the intent is to have this be reserved indefinitely, then just say that, rather than<br>
> tying it to IPv6 deployment. Or alternatively, put a time-based sunset policy in place.<br>
><br>
> Lastly, while it didn't come up in PR, we had also discussed on PPML the idea of a different sort of sunset clause, where unless X<br>
> SPs came forward and notified ARIN that they were using the space, it would be returned to the free pool instead of being stranded<br>
> and unused. Because there are many of us that remain unconvinced that this will actually reduce the burn rate of IPv4 space, this<br>
> would be a show of good faith on the part of the beneficiaries of this policy that wouldn't fundamentally alter its intent. It<br>
> does't have to be public, but at least it would provide a way to ensure that we're not wasting space on this application.<br>
><br>
> Wes George<br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a> [mailto:<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>] On Behalf Of ARIN<br>
> Sent: Monday, April 18, 2011 3:07 PM<br>
> To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
> Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call<br>
><br>
> The ARIN Advisory Council (AC) met on 13 April 2011 and decided to send the following draft policy to last call:<br>
><br>
> ARIN-2011-5: Shared Transition Space for IPv4 Address Extension<br>
><br>
> Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for<br>
> 2011-5 will expire on 2 May 2011. After last call the AC will conduct their last call review.<br>
><br>
> The draft policy text is below and available at:<br>
> <a href="https://www.arin.net/policy/proposals/" target="_blank">https://www.arin.net/policy/proposals/</a><br>
><br>
> The ARIN Policy Development Process is available at:<br>
> <a href="https://www.arin.net/policy/pdp.html" target="_blank">https://www.arin.net/policy/pdp.html</a><br>
><br>
> Regards,<br>
><br>
> Communications and Member Services<br>
> American Registry for Internet Numbers (ARIN)<br>
><br>
><br>
> ## * ##<br>
><br>
><br>
> Draft Policy ARIN-2011-5<br>
> Shared Transition Space for IPv4 Address Extension<br>
><br>
> Date: 20 January 2011<br>
><br>
> Policy statement:<br>
><br>
> Updates 4.10 of the NRPM:<br>
> A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 address extension. This block will not be allocated or<br>
> assigned to any single organization, but is to be shared by Service Providers for internal use for IPv4 address extension<br>
> deployments until connected networks fully support IPv6. Examples of such needs include: IPv4 addresses between home gateways and<br>
> NAT444 translators.<br>
><br>
> Rationale:<br>
><br>
> The Internet community is rapidly consuming the remaining supply of unallocated IPv4 addresses. During the transition period to<br>
> IPv6, it is imperative that Service Providers maintain IPv4 service for devices and networks that are currently incapable of<br>
> upgrading to IPv6.<br>
> Consumers must be able to reach the largely IPv4 Internet after exhaustion. Without a means to share addresses, people or<br>
> organizations who gain Internet access for the first time, or those who switch providers, or move to another area, will be unable to<br>
> reach the IPv4 Internet.<br>
><br>
> Further, many CPE router devices used to provide residential or small-medium business services have been optimized for IPv4<br>
> operation, and typically require replacement in order to fully support the transition to IPv6 (either natively or via one of many<br>
> transition technologies). In addition, various consumer devices including IP-enabled televisions, gaming consoles, medical and<br>
> family monitoring devices, etc. are IPv4-only, and cannot be upgraded. While these will eventually be replaced with dual-stack or<br>
> IPv6 capable devices, this transition will take many years. As these are typically consumer-owned devices, service providers do not<br>
> have control over the speed of their replacement cycle. However, consumers have an expectation that they will continue to receive<br>
> IPv4 service, and that such devices will continue to have IPv4 Internet connectivity after the IPv4 pool is exhausted, even if the<br>
> customer contracts for new service with a new provider.<br>
><br>
> Until such customers replace their Home Gateways and all IPv4-only devices with IPv6-capable devices, Service Providers will be<br>
> required to continue to offer IPv4 services through the use of an IPv4 address sharing technology such as NAT444. A recent study<br>
> showed that there is no part of RFC1918 space which would not overlap with some IPv4 gateways, and therefore to prevent address<br>
> conflicts, new address space is needed.<br>
><br>
> Service providers are currently presented with three options for obtaining sufficient IPv4 address space for NAT444/IPv4 extension<br>
> deployments: (1) Request allocations under the NRPM; (2) share address space with other providers (this proposal); or (3) use<br>
> address space allocated to another entity (i.e. 'squat'). Of the three options, option 2 (this proposal) is preferable, as it will<br>
> minimize the number of addresses used for IPv4 extension deployments while preserving the authority of IANA and RIRs.<br>
><br>
> Timetable for implementation: immediately<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
><br>
><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
><br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br></div>