On Dec 1, 2011 4:02 PM, "Chris Donley" <[email protected]> wrote: > > 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). >
I know this is not a new case. And I know efforts to make 240/4 workable are also not new. And, historically the answer is always no to new special ipv4 space. Someone else can expound why. If I had 240/4 in 2008, I would not have ipv6 now, that is a straight strategic business planning fact. Saying yes now, would be changing the rules because 'the rule' was/is 'no' new space. Cb > 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" <[email protected]> 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 > >[email protected] > >https://www.ietf.org/mailman/listinfo/ietf >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
