On Dec 1, 2011 4:02 PM, "Chris Donley" <C.Donley@xxxxxxxxxxxxx> 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" <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