Before I begin, I would like to apologize for any incorrectness in this
message. I am very new to IPv6 so I�m still trying to get all the facts
straight.
A few individuals in the IPv6 community, including Steve Deering, have told
me that the IPv6 addressing schema has focused on Internet provider/vendor
needs, as the groups that decide on IPv6 do not have adequate, if any,
representation from the non Internet provider/vendor community. I know this
may be bad timing but I feel it is necessary to write to those it may
concern in order to re-iterate some issues.
I work for a large private information provider. We connect privately to
over 20000 customer networks which constitute over a million computer
systems, of which over 150,000 subscribe to our data. Our private network
has around 250 POPs connecting over 80 countries to our data centers. We
have considered plans to peer several of these POPs to the Internet to
provide �short-cuts� for our customer networks to access various resources
on the Internet. Our network is, however, strictly private. The company
has little or no interest in becoming a network service provider, and even
less interest in becoming an Internet transit service provider. This,
unfortunately for us, means that we would not be eligible to apply for a
[Sub-]TLA, based on RFC 2450.
In the current IPv6 addressing plan a [Sub-]TLA and all contained addressing
is �owned� by an Internet transit service provider. This presents several
problems. This provider may go out of business, adopt unacceptable business
policies, get bought by a business rival (btw, this has happened to us),
etc. If such things should happen to our [Sub-]TLA provider we stand a risk
of having to change our addressing. This would put our business at
considerable risk due to several factors.
Although RFC 2347 describes a way to have �addressing independence from
long-haul transit providers� by connecting to the Internet via an
�exchange�, it says nothing about (1) how an exchange can provide dedicated
addressing to a global company, (2) how and who will administer it (3) will
multihoming via an exchange provide the routing �insulation� provided by
peering independantly? If an exchange is administered by a public body,
would we not be entitled to preferential considerations? Who has the
answers to these questions?
We use the same routers that large providers use. We also happen to have
thousands of distributed servers on our network running several versions of
several operating systems. I have not seen any effort on the part of these
router and systems vendors to simplify the rapid change of addressing. For
us this means not only changing addresses on over 40,000 thousand
interfaces, but also changing over 100,000 lines of distributed policies.
Not to mention all the data storage, thresholding and alarm systems and
databases. Also, in my experience, massive changes have exposed bugs in
vendor software that have caused loss of service to our customers. For
example, when changing policy, if a line of policy does not implement
properly due to some race condition, this can cause loss of service and/or
exposure (btw, we have seen this happen).
Almost all of our 20000 customer networks use firewalls. Our addresses are
configured into these firewalls. It takes over a year of letters and
meetings with 20000 customers to accomplish this. Not to mention tens of
thousands of man-hours.
We not only have �canned� connections to customers, but also over 1000
private connections to our own sources of data, each of which is unique to
that data provider. We need to privately peer with these corporations,
without the ISP in the middle. These peering points are full of policies in
both directions and on both sides.
I am not sure if there is an IPv6 study group on the impact of changing
addresses, or if anyone has published anything regarding this topic. If
anyone knows of where I can find information regarding this I would
appreciate having it.
The current addressing scheme does not solve the problem of multi-homing in
any concrete way either. There is a conflict in the current scheme between
aggregation, multi-homing and address transparency. If I want to make a
[Sub-]TLA provider in the Far East happy, I�d need to use an address
assigned by him. However, this may not make any of the other 99 ISPs I
decide to peer with very happy. I can make every [Sub-]TLA provider happy
if I do IPv6 NAT using that providers assigned address. This, however,
defeats the IPv6 claim to rid the world of NAT and create full address
transparency.
It seems to me that in the current addressing schema, things like route
aggregation and host autoconfiguration has taken precedence over some other
very serious issues. In what balance were these factors measured for route
aggregation to win? Route aggregation solves a single technical problem.
But it doesn't seem to solve any other significant business issue towards
the implementation of IPv6. The industry has proven capable of building
better routers that can handle more route entries. I�m not against route
aggregation. I use it aggressively in our network. But I don�t think it�s
a good idea for a company such as mines to be subjected to having our
address space outside our control.
I see a lot of intelligent dialogue in these working groups. But it seems
to me no one wants to touch the issues that will actually move IPv6 into the
real world.
I hate to say this to everyone who's worked so hard on IPv6. The current
IPv6 addressing schema is unusable by anyone except Internet providers
trying to serve the household and small business market. It needs to be
redone to gain the support of large corporations.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
