[arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call
v6ops at globis.net
Fri Apr 29 13:48:18 EDT 2011
My view is that this proposal as it stands is a rushed and badly thought
out policy, and I cannot support it in its current form.
Why act now?
The main justification for acting now seems to be that the original
author of the proposal
that a /10 is required to cover the needs of large ISPs, whilst it is
unlikely that it will be possible for ARIN to allocate a /10 in the near
future. The proposal has also been "shopped around" since 2009 to try to
find someone willing to accept it.
Meanwhile new entrants to the ISP market are effectively shut out, due
to the "last /8" allocation policy for IPv4 addresses coming into effect
in the ARIN region.
Allocating a further /10 will probably suit large existing players, but
would deprive a potential new market entrant (who may be more willing to
deploy IPv6) from a significant number of IPv4 addresses.
I therefore think there needs to be some more justification of the need
to allocate this significant number of addresses now, as opposed to
eeking out the existing IPv4 space for as long as possible.
What is the operational experience with RFC1918?
RFC1918 addresses required special treatment in many systems, which had
a large knock on effect on ancillary applications and code e.g. network
provisioning systems, route filters, address filters, network intrusion
detection, traffic counters and classification, WAN acceleration,
application level proxies, network management systems, reverse DNS
resolution, policy based routing, DHCP servers, IP space allocation and
management applications, programmes that parse traceroute output etc.
RFC1918 is even used by some applications, protocols, and transition
mechanisms to detect whether they are connected to the public internet
or not [e.g. Windows Teredo]
The operational experience with RFC1918 showed that it had far more, and
far wider reaching effects, than anyone thought at the time it was adopted.
What Question Remain Unanswered About the new /10?
Adding a new "class" of addresses: the shared inter-ISP address space,
potentially adds a whole new level of complexity.
There is also no clear definition of what constitutes a "service provider."
There is no clear definition of "acceptable use" in the proposed policy.
Would it be acceptable for a hosting provider to deploy such address on
their internal infrastructure, which is then connected to an ISP?
Is an outsourcer/ASP also a "Service Provider"?
What if a customer contracts multiple Service Providers?
Would it be acceptable to allocate these addresses to end hosts that
only connected to other systems within the organisation?
Would it be acceptable for a reseller to employ such addresses on their
Would these /10 addresses be used instead of new globally unique address
Is there any penalty clause/incentive for moving to the new /10 scheme?
Would an ISP be required to renumber ALL existing IPv4 internal links
into this new space to free up existing globally unique addresses for
Faulty Base Rationale?
The base rationale includes avoiding preventing RFC1918 style address
Quote "therefore to prevent address conflicts, new address space is
Why do people believe that this new /10 allocation will solve the issue
of address conflicts?
Allocating this new space as per the proposed policy will NOT on its own
prevent future address conflicts, as there is no global coordination of
the use of the new /10 address space. The problem is not solved, it is
What if service provider 1 and service provider 2 merge?
Are these addresses allowed to be routed into customer networks?
What if the customer connects to multiple Service Providers?
What if the customer changes ISP?
What is the impact of a tier two provider implementing CGN with this new
/10 range, who then connects via a tier one provider who also implements
CGN also with the same /10 range?
If NAT444 is the solution, it should also work in the situation where
there are RFC1918 address conflicts, because the new /10 allocation will
also give rise to those very same address conflicts at some time or
another if ARIN proceeds as per the current policy.
Otherwise I think that you need to seriously rethink how the /10 is
going to be allocated and managed, because it is not well-defined in
Has There Been Sufficient Study on the Likely Knock-on Effects?
The introduction of NAT444 will be the first time that NAT has been
deployed within the Internet cloud, and the first time that NAT has been
deployed that is not under the direct control of the end user. I do not
believe that the operational impact of this and related issues have been
fully investigated yet.
Has there been any impact analysis on the likely knock-on affects of
this new /10 allocation?
It's also very unclear how this allocation, if ever, will be undone,
potentially leaving a nasty legacy.
What modifications would be necessary to existing code to handle the new
What BGP/AS routing policy updates are required?
My gut feeling says that this time and effort would be better spent
deploying native IPv6 protocols.
Best regards and the best of luck in taking the correct policy decision.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML