[arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4 Address Extension
lsawyer at gci.com
Thu Jan 20 15:36:46 EST 2011
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.
> 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
> 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:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML