[arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call

[Ray Hunter]

nonsupport.

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 
http://tools.ietf.org/html/draft-shirasaki-isp-shared-addr-01 suggested 
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 
internal infrastructure?
Would these /10 addresses be used instead of new globally unique address 
allocations?
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 
alternate use?



Faulty Base Rationale?

The base rationale includes avoiding preventing RFC1918 style address 
conflicts.
Quote "therefore to prevent address conflicts, new address space is 
needed."

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 
merely deferred.

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 
this proposal.



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 
address class?
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.

RayH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110429/78856f89/attachment.htm>