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

[Chris Donley <[e-mail]>]

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" <[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