Tim, Kurt:

I will add some comments from the end-user-network perspective on behalf
of my client base.  Please see inline.

AEB

On Thu, 13 Feb 2003, Tim Chown wrote:

> On Tue, Feb 11, 2003 at 09:25:24AM +0100, Kurt Erik Lindqvist wrote:
> >
> > 1) Address space shortage
> > 2a) No scalable PI solution
> > 2b) No scalable IDR solution
> >
> > I said it before and I will say it again, without a solution to 2a, no
> > enterprises will go to IPv6, with no enterprises on IPv6 there are no
> > revenues for the ISPs in IPv6, with no revenue from IPv6 the ISPs will
> > not go to IPv6. Just because I can reach a webpage over IPv6 doesn't
> > make the web-page more interesting. If it isn't more interesting I
> > can't charge extra for it. Going to IPv6 will cost the ISPs. Sorry. It
> > doesn't work out. We need to progress on multi6 if this is to take off.
>
Most end-user network managers I deal with require these characteristics
of their public network address allocations:

1) uniqueness (sometimes expressed as "autonomy")
2) portability
3) stability

In many cases, requirement two is driven by a desire to implement
multiple connections to the public networks via more than one service
provider (multihoming).

While PI is not an absolute requirement, the present state of our
technology and standards (for v6 as well as v4) force us to PI as the only
implemented mechanism which satisfies the functional requirements
enumerated above.  If we can develop and write into the standards some
alternate mechanisms which are technically sound and will meet these
functional requirements, we can perhaps avoid the persistent and vocal
demands from the end-user community for PI; until that time, however, PI
will remain a key requirement from end-user network managers.

> Yes, but not for all networks.  I appreciate many people don't view the
> academic research networks as commercial networks, but there is a large
> potential IPv6 user base in that community for whom address stability has
> been available through pre-CIDR allocations.  In the UK example, the 200
> or so universities will go from 160 IPv4 (PI) prefixes to 1 single IPv6
> (PA) prefix, but the provider being the non-commercial "independent" NREN
> makes the address space in effect PI (JANET has a /32 allocation).  Each
> of the 25-30 European NRENs are likely to be in a similar position, so
> you could see 25-30 SubTLA's replacing (well, living alongside :) around
> 3,000 IPv4 prefixes.  Behind those 25-30 SubTLAs are maybe 30 million staff
> and students at the universities.
>

For those end-user-network managers who are aware of the details of the
NREN allocations, this situation provokes pure, incandescent fury: the
academic entities are seen as having been granted special (and grossly
preferential) treatment, while the commercial (as distinguished from
service-provider) networks are subject to callous indifference and
excluded thereby from direct access to stable network address allocations.
We can't even claim "separate but equal" for this state of affairs, and
the universal principle of Brown V. Board of Education still holds, even
for networks. [For those not familiar with recent US history, send me mail
directly for a brief explanation of the above reference.  AEB]

> Well, that's one view.  Many regional networks may seek to multihome.  Some
> universities might seek SubTLA prefixes (many obtained pTLA space, and some
> are LIR's for the benefit of IPv4 multihoming, but multihoming to universities
> isn't common because they're tied in, for better or worse, richer or poorer,
> to the NREN service).
>
> I think multihoming is important in the shorter term for a number of classes
> of networks, including some large enterprises.  IPv6 multihoming for home
> networks is further off, and is the point at which you would be looking at
> the "1 billion multihomers" scenario.  But for some (many?) users/networks,
> multihoming isn't critical to adopt IPv6.
>
> Tim


Most of the end-user-network managers among my clients now multihome, and
will continue to require multihomed service in future.  In every case
where the user's network is multihomed, the multiple independent
connections are seen as crucial for maintenance of high availability of
the client's services to the public networks; and high availability is
considered an absolute requirement for survival of the business.  In some
cases there are regulatory requirements which can result in civil or
administrative sanctions (including, in the worst event, loss of operating
licenses) if the services should be found unavailable for significant
periods of time.  Yes, it is possible, at least in theory, for commercial
service providers to sustain the required level of availability, but most
of my clients have found, much to their distress, that the US ISPs are
almost uniformly incapable of doing so in practice.  In almost every case,
the administrative managers for these user networks are simply and flatly
unwilling to put their businesses at the mercy of a single ISP.

Based on conversations with my clients, I cannot find it within the scope
of my imagination (or, for that matter, of theirs) that these networks
will give up the mutilhoming requirement at any time within the
foreseeable future.

Now granted, many of the networks referred to above provide access to
financial services, so the uptime requirements may be slightly more
rigorous than average;  however, I cannot imagine that any business which
generates substantial portions of its revenue from systems which rely on
network access would fail to impose stringent availability requirements on
network service, particularly since these businesses go to quite
extraordinary lengths to ensure availability of the online systems
themselves.

Home networks may be another matter, but I would give my eyeteeth to get a
stable, portable (and, thereby, multihome-capable) IPv6 allocation for
_my_ home network, as that network also supports supports my office and
business-related systems. (And, before you ask, all the systems - but not
necessarily all the peripherals - in my network _are_ v6-capable.)  I
suspect that we will find increasing use of "home" networks for business
activity, and increasing demand for stability of network locator
information. Granted, DNS provides some stability in network locator
information, but it is still not sufficient to overcome the current ISP
practices of enforced address instability and service restrictions, and I
can see no incentive (short of PI) in the current proposals which augurs
a change in current ISP policy and pricing.  As it is, I pay quite
outrageous fees to secure for my office public-network access which is
sufficiently reliable and stable to sustain the business, and I _still_
can't multihome.  Based on experience with my client base, I cannot agree
with the postulate that many networks will not find lack of multihome
support a barrier to implementation of v6.

The current speculation about "what the users _really_ need" (as
distinguished from what they _say_ they need) smacks to me of "all
networks are equal, but some are more equal than others" (with apologies
to _Animal Farm_).   It seems to me that we have some technical problems
to resolve here, and user education (or arbitrary restrictions on what
services are available to some classes of users) will not resolve the
extant issues, not even temporarily.  These issues will continue to raise
their ugly heads (or nether ends, and a I don't know how to distinguish
one from the other at this point) until we engineer solutions to the
technical problems - we can't "educate" or regulate these problems out of
existence.

That's my $.02 worth.

Alan E. Beard

-- 
Alan E. Beard <[EMAIL PROTECTED]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to