<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<div class="moz-text-flowed" style="font-size: 13px;" lang="x-western">nonsupport.<br>
<br>
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.<br>
<br>
Why act now?<br>
<br>
The main justification for acting now seems to be that the original
author of the proposal
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-shirasaki-isp-shared-addr-01">http://tools.ietf.org/html/draft-shirasaki-isp-shared-addr-01</a> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
What is the operational experience with RFC1918?<br>
<br>
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.
<br>
<br>
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]
<br>
<br>
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.
<br>
<br>
<br>
What Question Remain Unanswered About the new /10?<br>
<br>
Adding a new "class" of addresses: the shared inter-ISP address space,
potentially adds a whole new level of complexity.
<br>
<br>
There is also no clear definition of what constitutes a "service
provider."
<br>
There is no clear definition of "acceptable use" in the proposed
policy.
<br>
<br>
Would it be acceptable for a hosting provider to deploy such address on
their internal infrastructure, which is then connected to an ISP?
<br>
Is an outsourcer/ASP also a "Service Provider"?<br>
What if a customer contracts multiple Service Providers?<br>
Would it be acceptable to allocate these addresses to end hosts that
only connected to other systems within the organisation?
<br>
Would it be acceptable for a reseller to employ such addresses on their
internal infrastructure?
<br>
Would these /10 addresses be used instead of new globally unique
address allocations?<br>
Is there any penalty clause/incentive for moving to the new /10 scheme?<br>
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?
<br>
<br>
<br>
<br>
Faulty Base Rationale?<br>
<br>
The base rationale includes avoiding preventing RFC1918 style address
conflicts.
<br>
Quote "therefore to prevent address conflicts, new address space is
needed."
<br>
<br>
Why do people believe that this new /10 allocation will solve the issue
of address conflicts?<br>
<br>
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.
<br>
<br>
What if service provider 1 and service provider 2 merge?
<br>
Are these addresses allowed to be routed into customer networks?
<br>
What if the customer connects to multiple Service Providers?
<br>
What if the customer changes ISP?
<br>
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?
<br>
<br>
<br>
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. <br>
<br>
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.
<br>
<br>
<br>
<br>
Has There Been Sufficient Study on the Likely Knock-on Effects?<br>
<br>
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.
<br>
<br>
Has there been any impact analysis on the likely knock-on affects of
this new /10 allocation?
<br>
<br>
It's also very unclear how this allocation, if ever, will be undone,
potentially leaving a nasty legacy.
<br>
<br>
What modifications would be necessary to existing code to handle the
new address class?<br>
What BGP/AS routing policy updates are required?<br>
<br>
<br>
<br>
My gut feeling says that this time and effort would be better spent
deploying native IPv6 protocols.
<br>
<br>
Best regards and the best of luck in taking the correct policy
decision.
<br>
<br>
RayH
<br>
</div>
</body>
</html>