Trying to Summarize The Discussion (not addresses)

[Howard C. Berkowitz]

Forgive me a certain amount of duplication of my responses to other posts,
but I am trying to clarify some of the arguments by showing that several
threads actually interrelate.

1.  Procedural Issues
---------------------

Much of the discussion focuses on the actual dollar fees proposed: their
magnitude and their justification.  IMHO, having actual values in the basic
"charter" document is not useful and has contributed to the flame war.

My own feeling is that the discussion/proposal will work better in three steps:
   1.  Consensus on the problem to be solved, the missions and functions of
       ARIN, and recognition of the issues that other bodies need to deal with.
   2.  Description of the work to be performed by ARIN, understanding by
       the community of the relevant guiding documents, etc.
   3.  Determining costs for those functions, and mapping them against
predicted
       workload/market to determine fees.

2.  Technical Issues
--------------------

I believe the key to a technical discussion is being sure that we are not
overcomplicating some issues by miring all of them in issues of IP
allocation.  There are other approaches.

2.1  Reachability -- the Key Issue
----------------------------------

>From a user perspective and what IMHO should be a business perspective, the
issue is whether a given node is reachable or not.  As long as my browser
can find www.foo.com, I have solved my problem.

www.foo.com is not, as people will notice, an IP address.  It is a DNS name.

In the PIER working group and elsewhere, there is a technical consensus
that network endpoints -- certainly servers and to a lesser extent clients
-- should be referred to by DNS name, not IP address.

[Yes, I know DNS is not perfect, and there are cache timeouts, etc., to
consider.  Nevertheless...]  Making extensive use of naming rather than
addressing, in many respects, finesses a very large part of address
portability issue.  DNS has the capability of hiding the actual address
from end users.

DNS is best as a server solution.  For client addressing, schemes such as
DHCP and IPCP dynamic assignment will reduce the workload in renumbering.
Do remember any of these dynamic schemes can give a semi-random address, or
a fixed address based on some identifier such as MAC address.    The key
issue in making renumbering less painful is to minimize the number of
places where renumbering has to be done (e.g., address assignment servers
rather then every PC), not som much reducing the absolute numbers of
addresses assigned.

Yes, I know there are operational problems with fully dynamic addressing,
where it is unpredictable what address one gets at a given time, and thus
ping/traceroute/SNMP gets...interesting.  There are ways of dealing with
this today, ranging from manual procedures to proprietary servers for right
now, the the Dynamic DNS Update work going on in the IETF.  IPv6,
incidentally, has a significant number of capabilities to simplify
renumbering, although IPv6 does not help the routing table size problem.

Yes, in a provider change in a provider-based addressing scheme, some
hard-coded IP addresses will need to change.  But good practices can
minimize that.

2.2   The Routing Problem
-------------------------

(this bullet has both procedural and technical aspects)

Regardless of alternatives, there is an immediate problem that widely
deployed routers cannot keep up with unconstrained growth in the number of
globally advertised routes.  Provider-based aggregation, at least in the
short term, is the only widely demonstrated way to deal with this.
RFC2008, RFC2050, and other policy documents reflect this as Best Current
Practice, and the ARIN policies appear to reflect their view.

I am NOT saying current router architecture is appropriate forever.  I am
NOT saying BGP is the be-all, end-all, of global routing. I am not even
saying routing, as opposed to a hybrid of L3 and L2 forwarding
technologies, is the model we should use forever. I can point to any number
of open mailing lists where implementers and researchers point out the
flaws of all of these.  It's just that there is no clear consensus on the
direction to take NOW.

I am saying the problems are compounded by an overemphasis on end user
address portability as the problem, when the real global issue is end user
reachability.

2.3.  Address Portability, Multihoming, etc.
--------------------------------------------

While there is not universal agreement, I am hoping there is an increasing
consensus that portability for a /24 and portability for a /19 or less are
two different animals.

There are any number of sources, from RFC2050 on, that repeat simply having
provier-independent space doesn't mean it is globally routable.

A significant and changing number of operational and technical issues
govern the feasibility of specific multihomed configurations.  IMHO, one
should not try to do serious multihoming unless one has a large enough
network to support in-house, operationally current BGP expertise.  Until
that point, I believe a sounder policy involves multiple links to a single
provider, and a renumbering-friendly architecture that makes it relatively
easy to change providers.

2.4  The Role of IPv6
---------------------
IPv6 is a solution to some problems, especially in the areas of automating
configuration and making renumbering a fairly trivial issue.  I have seen
no router implementer suggest that going to IPv6, however, in any way
improves the ability of a router to handle additional numbers of routes.

The pure number of available addresses is not the problem we face today
with scalability.  It is the availability of routers, today, that cannot
economically handle routing tables beyond a certain size.

I cannot think of a serious argument that says IPv6 will improve this
problem.  It will be largely neutral for this specific problem.  Yes,
addresses are longer, but they may be a little cleaner to handle in
hardware.

Don't get me wrong, I think IPvt has a role in solving a broader problem of
Internet growth, but it approaches it a different way.  IPv6 and associated
mechanisms such as DHCPv6 and stateless autoconfiguration are intended to
make end user devices close to plug-and-play when the prefix changes.  It's
not that IPv6 would avoid the need to renumber, simply that it would make
this much less difficult.

Some of the arguments against it are that these autoconfiguration
mechanisms can be retrofitted into an IPv4 environment. Another
consideration is increasing use of firewalls that do address translation.

There are additional discussions going on, such as the latest incarnation
of Mike Odell's 8+8 proposal.  IMHO, there is some brilliant thinking going
on here, but aimed at a slightly different problem than increasing the
number of routes that can be handled in a single router.



Howard Berkowitz
PSC International (but speaking as an individual whose boss is a reasonable
human being who has no particular knowledge of, or opinions about, IP
allocation, registries, etc.)