[arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4 Address Extension

[Frank Bulk - iName.com]

I support this proposal.

I'd ask those who cannot support this proposal to suggest a pragmatic
alternative to NAT44/LSN/CGN.  Nobody wants NAT444 -- the content providers,
ISPs, nor eyeballs, but it's something that certain operators may be forced
to do.

A few more thoughts:
* I do understand the concern that if NAT444 is not too bad (for certain
categories of customers) that it may slow down the adoption of IPv6 by some
stragglers.  While service providers could use pricing to move those
customers away, if only the stragglers are using it (low levels of usage)
and the equipment is paid for, it would be hard to justify.  Look how long
it took for dial-up pricing to go up after broadband was widely available.
* In regards to the use of this space by others residing in other RIRs: this
policy doesn't need to give explicit permission or have restrictions.  This
policy is not trying to circumvent IANA or the IETF.  No "IP police" will be
sent out if other use this space.
* Yes, while operators could draw from their own allocated space to
accomplish NAT444, their combined efforts would likely result in more than a
/10 of IPv4 space being used and require an extraordinary amount of effort.
Rather than force them to renumber or go through all that work, let's just
allocate a /10 for this and be done with it.
* As others have said, let the ARIN staff choose the /10.

Frank

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Leif Sawyer
Sent: Thursday, January 20, 2011 2:37 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4
Address Extension

As a converged providor (cable, wireless, dsl, leased,  dial, etc)  I
understand
fully the pain that this is trying to prevent.

I support this proposal.


> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> ARIN-prop-127: Shared Transition Space for IPv4 Address Extension
>
> Proposal Originator: Chris Donley, CableLabs
>
> Proposal Version: 1
>
> Date: 20 January 2011
>
> Proposal type: modify
>
> Policy term: permanent
>
> Policy statement:
>
> Updates 4.10 of the NRPM:
> A second contiguous /10 IPv4 block will be reserved to
> facilitate IPv4 address extension. This block will not be
> allocated or assigned to any single organization, but is to
> be shared by Service Providers for internal use for IPv4
> address extension deployments until connected networks fully
> support IPv6. Examples of such needs include: IPv4 addresses
> between home gateways and NAT444 translators.
>
> Rationale:
>
> The Internet community is rapidly consuming the remaining
> supply of unallocated IPv4 addresses.  During the transition
> period to IPv6, it is imperative that Service Providers
> maintain IPv4 service for devices and networks that are
> currently incapable of upgrading to IPv6.
> Consumers must be able to reach the largely IPv4 Internet
> after exhaustion.  Without a means to share addresses, people
> or organizations who gain Internet access for the first time,
> or those who switch providers, or move to another area, will
> be unable to reach the IPv4 Internet.
>
> Further, many CPE router devices used to provide residential
> or small-medium business services have been optimized for
> IPv4 operation, and typically require replacement in order to
> fully support the transition to IPv6 (either natively or via
> one of many transition technologies).  In addition, various
> consumer devices including IP-enabled televisions, gaming
> consoles, medical and family monitoring devices, etc. are
> IPv4-only, and cannot be upgraded.  While these will
> eventually be replaced with dual-stack or IPv6 capable
> devices, this transition will take many years.  As these are
> typically consumer-owned devices, service providers do not
> have control over the speed of their replacement cycle.
> However, consumers have an expectation that they will
> continue to receive IPv4 service, and that such devices will
> continue to have IPv4 Internet connectivity after the IPv4
> pool is exhausted, even if the customer contracts for new
> service with a new provider.
>
> Until such customers replace their Home Gateways and all
> IPv4-only devices with IPv6-capable devices, Service
> Providers will be required to continue to offer IPv4 services
> through the use of an IPv4 address sharing technology such as
> NAT444.  A recent study showed that there is no part of
> RFC1918 space which would not overlap with some IPv4
> gateways, and therefore to prevent address conflicts, new
> address space is needed.
>
> Service providers are currently presented with three options
> for obtaining sufficient IPv4 address space for NAT444/IPv4 extension
> deployments: (1) Request allocations under the NRPM; (2)
> share address space with other providers (this proposal); or
> (3) use address space allocated to another entity (i.e.
> 'squat').  Of the three options, option 2 (this proposal) is
> preferable, as it will minimize the number of addresses used
> for IPv4 extension deployments while preserving the authority
> of IANA and RIRs.
>
> Timetable for implementation: immediately
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.