This is not a new proposal. People have been asking for the same thing for a long time. Draft-bdgks does a good job spelling out the history (below). To say that we're trying to change the rules at the last minute is wrong. People have been asking for such an allocation considering this use case as long ago as 2004, and fairly consistently since 2008. We and the other draft authors have been following IETF process, documenting the need, documenting the tradeoffs, and documenting the challenges with CGN for quite some time. People wouldn't keep coming back to the IETF again and again for seven years or so if we had a better way to satisfy this need (although I am aware that some operators have opted for squat space rather than push for a shared pool of CGN space). Chris >From bdgks: Proposals for additional Private space date back at least to [I-D.hain-1918bis <http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.hain-1918bis>] in April 2004. Some of these proposals and surrounding discussion may have considered similar use-cases as described herein. However, they were fundamentally intended to increase the size of the [RFC1918 <http://tools.ietf.org/html/rfc1918>] pool, whereas a defining characteristic of Shared Transition Space is that it is distinctly not part of the Private [RFC1918 <http://tools.ietf.org/html/rfc1918>] address pool. Rather, the Shared Transition Space is reserved for more narrow deployment scenarios, specifically for use by SPs to meet the needs of ongoing IPv4 connectivity during the period of IPv6 transition. This key feature emerged in more recent proposals such as [I-D.shirasaki-isp-shared-addr <http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.shirasaki-isp-shared-addr>] in June 2008 where a proposal to set aside "ISP Shared Space" was made. During discussion of these more recent proposals, many of the salient points where commented upon, including challenges with RFC1918 <http://tools.ietf.org/html/rfc1918> in the ISP NAT Zone, Avoidance of IP Address Conflicts, and challenges with 240/4. This effort was followed up by [I-D.weil-opsawg-provider-address-space <http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.weil-opsawg-provider-address-space>] in July 2010 which was re- worked in November 2010 as [I-D.weil-shared-transition-space-request <http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.weil-shared-transition-space-request>]. These latter efforts continued to point out the operators' need for Shared Transition Space, with full acknowledgement that challenges may arise with NAT444 as per [I-D.donley-nat444-impacts <http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -I-D.donley-nat444-impacts>] and that such space does not reduce the need for IPv6 deployment. Most recently, following exhaustion of the IANA's /8 pool [NRO-IANA-exhaust <http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -NRO-IANA-exhaust>], this proposal has been discussed by various RIR policy development participants. As described herein, the body of ARIN policy development participants has reached consensus and recommended a Shared Address Space policy for adoption [ARIN-2011-5 <http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03#ref -ARIN-2011-5>]. This history shows that operators and other industry contributors have consistently identified the need for a Shared Transition Space assignment, based on pragmatic operational needs. The previous work has also described the awareness of the challenges of this space, but points to this option as the most manageable and workable solution for IPv6 transition space. Chris On 12/1/11 2:05 PM, "Cameron Byrne" <cb.list6@xxxxxxxxx> wrote: >I will add one more concern with this allocation. > >IPv4 address allocation is a market (supply exceeds demand in this >case), and thus a strategic game (like chess) to gather limited >resources . > >We have known for a long time how IPv4 was not an acceptable long term >solution. > >We have known for a long time that IPv6 is the only path forward for a >growing internet (more people online, more devices connected, up and >to the right...) > >This allocation is changing the rules of the game in the last few >minutes (IANA and APNIC are already out...) and is dubiously blessing >an Internet model based on CGN. > >Changing the rules of the game towards the end to manipulate the >outcome is seldom acceptable, regardless of the context. AFAIK, there >have been no extenuating circumstance that have dictated a need for a >change. IPv4 did not magically run out. My favorite IPv4 risk >artifact should be familiar to the draft authors or other people in >the ARIN region: > >https://www.arin.net/knowledge/about_resources/ceo_letter.pdf > >I understand how this allocations benefits folks in the short run, and >i promise to use this allocation to my benefit (better than squat >space, right?!). But, at the macroscopic level at which the IETF, >IESG, and IAB should be working, this is just changing the rules of >the game at the last minute because some players don't like the >outcome, even though this outcome (ipv4 is out, need to use v6) has >had 10+ years of runway. > >I do not believe this is a positive sum game where this allocation is >made and everyone wins. I do believe IPv6 loses (CGN vs v6 >investment*, urgency, lines on strategy diagrams...) if this >allocation is made, and i do not think it is acceptable to change the >rules of the game in the final moments because the outcome is costly >for some. > >Cameron > >*i already have the link to your press release that your lab is ipv6 >enabled, thanks! >_______________________________________________ >Ietf mailing list >Ietf@xxxxxxxx >https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf