Re: Consensus Call: draft-weil-shared-transition-space-request

[Cameron Byrne <[e-mail]>]

On Dec 1, 2011 4:02 PM, "Chris Donley" <[e-mail]> 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" <[e-mail]> 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
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ietf
>