Important IPv6 Policy Issue -- Your Input Requested

Tue Nov 9 17:29:44 UTC 2004

> Almost more interesting is consider the "financial interchange
> network" where 100 companies come together each with 20 networks.
> I believe even with that relatively small number of networks (2000
> total) the probability of collision is well more than 50%.

My company already does this (financial interchange network) using
registered globally unique IPv4 addresses. When we transition to
IPv6 I see no reason why we would not continue using globally
registered IP addresses. The routability of these addresses
is not relevant to us because our network is disjoint from
the Internet, therefore the addresses only need to be routable
on our network. Other organizations have similar types of
international IP networks that are disjoint from the Internet.
A competitor of ours, SWIFT, operates their own IP network and
probably interconnects many of our customers as well. In the 
automotive industry in Europe there is the ENX http://www.enxo.com
that is a similar disjoint network. When I was last involved with
ENX it used existing IP backbones but traffic was exchanged over
special dedicated peering connections with an enforceable
SLA between the two peers monitored by the ENXO. I suppose
that SITA must also run IP on their network these days.

In all of these cases, companies do not just "come together".
The interconnection is carefully planned and often involves
some sort of partitioning of the companies' internal networks.
For instance, many of our customers connect their trading
floors to our network however those trading floors do not
have direct connectivity with the Internet even though all
of our customers do have Internet connectivity. We are now
getting into a very complex area of enterprise network
architecture which it is pointless to second guess, because
somebody, somewhere will implement any architecture that
you can imagine. The point is that when companies interconnect
networks, they do not simply merge their internal networks
with the internetwork.

With our customers, the interconnect is done for a very specific
defined purpose and engineers on both sides ensure that the 
interconnect does not carry traffic that is out of scope.
In the case of corporate merger, there would likely be a network
audit (due diligence) followed by a decision as to how to
deal with the small number of collisions, either renumber them
or install an IPv6 NAT device. The decision won't be made based
on elegance or RFC compliance, rather it will be made based on the
business case. I suspect that if you do the actual maths for
companies the size of Microsoft and Time Warner, you will find
that the number of collisions will be so low that the business
case will lead to renumbering. If anyone disagrees the I would 
really like to see a worked example of the math.

> Best I can tell renumbering will be NO LESS expensive in IPv6, and
> actually will be more expensive, since the IPv6 proponents seem bent
> on requiring everyone to have 6 addresses to do anything useful, so
> it will be address management effort x6.

Address management and renumbering are so important to today's
enterprises that they all use some toolset involving LDAP directories,
databases and DHCP servers. Multiplying the data content of the
database times 6 does not necessarily change the level of effort.

I'm surprised that no-one has pointed out how easy it is to get
an IPv6 allocation today and set up a registry for globally unique
IPv6 addresses for private networks. The initial allocations are
large enough to not have to ever return to the RIR for more, and
if a company can sell people on the idea of allocating globally
unique IPv6 private addresses in the same way as IPv4 (i.e. /128
per host rather than /64) then it would last a long time.

By the way, there is already the so-called deprecated site-local
address range that folks can use. I assume that "deprecated" just
means that you need to explicitly configure the ACLs at your border
rather than relying on some automatic routing behavior. Perhaps the
draft could be recast as a "best practice" for using site-local
addresses via a hashing algorithm that makes collisions less likely.

--Michael Dillon