On Dec 1, 2011 4:02 PM, "Chris Donley"
<C(_dot_)Donley(_at_)cablelabs(_dot_)com> 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(_dot_)list6(_at_)gmail(_dot_)com>
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf