Re: IPv7 (CLNP) a mistake

["James B. Van Bokkelen" <[e-mail]>]

A vendor's perspective:

We at FTP have always taken the point of view that if we implement for the
Internet, that will also satisfy our non-connected customer base, since the
Internet is where they're likely to be in a few years.  If we're to continue
to do this, and if the protocol suite we've invested in is to continue to
compete well against the proprietary stacks, the Internet must remain viable.

I see the following problems affecting the Internet's viability:

1. Security of networked hosts.

2. Installation, configuration and maintenance of networked hosts.

3. Routing table size issues.

4. Address space exhaustion.

The IAB proposal to adopt CLNP is aimed at the latter two.  On the
face of it, the 20-byte NSAP solves 4, and the extra room lets us use
space inefficiently doing route aggregation, which solves 3 as well.

Why CLNP, and not something else?  CLNP appears to have three things
going for it: First, it is standardized and implemented in both hosts
and routers, which is a positive compared to other proposals.  Second,
a fairly large fraction of the existing Internet router base either
already can carry CLNP traffic, or can easily be upgraded to do so.
Third, CLNP is viewed as a "step towards ISO" by a number of large
organizations which have major political commitments towards it.  CLNP
also has a number of technical and organizational negatives, but
they've been discussed by others.

The first two major positives for CLNP are eliminated if we don't use it
out of the box, as it is specified in current ISO documents (I expect that
the third would still get a lot of PR play).  Many of CLNP's negatives can
be dealt with by a CLNP+.  But specifying and implementing a CLNP+ will be
an effort of the same scale as doing IPv7 by doubling the size of RFC
791's Src, Dst and Hlen fields.  A rose by any other name...

Also, some thoughts about the practical issues relating to an IPv7 as
they affect the existing code base.

Internetwork layer:

If the Internet isn't to be fragmented, during the transition all
hosts have to remain able to interconnect.  In practical terms, this
means they would have to implement either IPv4 or both IPv4 and IPv7.
I don't think transition by network or region with translating
gateways will fly, simply because of the number of people who're bound
to what's available commercially, off the shelf.  Experience with the
HRRFCs suggests that it will take three or four years before all the
vendors respond, and no region will be able to convert prior to that
unless their equipment is homogeneous, current production, and
supported by a forward-looking vendor.

Having two IP stacks will complicate configuration, and increase the
memory required by the stack (I'd guess that at least 30% of the hosts
in the Internet are DOS PCs, and this will cost in that environment).

Transport layer:

Initially, TCP and UDP continue to work, but they depend on a "magic
glue layer" which figures out whether the IP address they're dealing
with is real, to be handled by the IPv4 side, or only a local token
which needs to be mapped to an NSAP for IPv7.

Later, TCP and IP become NSAP-aware.  For most stacks, the work here
will be new upper and lower APIs which allow opaque addresses of
arbitrary size.  Maybe we don't care about the TCP "pseudo-header"
anymore, and the IP address and ports can become constants.  It's only
saved my bacon a couple of times, when deep in the internals of our
TCP, and it does make things much harder in a multi-homed host.

Applications:

Initially, we should be able to hide the transition from IPv4 to IPv7
beneath the transport layer API.  The name-resolver determines which
to use, and supplies the "local token" if necessary.  This gets you
going in situations where the name resolver isn't actually linked into
the application, but some PC stacks which chose to do otherwise will
make their 3rd parties suffer.  The downside is that anything that
prints an IP address (and most supportable Internet applications do
somewhere in their debugging code) is devalued.

Eventually, all applications have to be re-compiled (and maybe
re-coded if the new API doesn't just change the size of struct
sockaddr or whatever).  This process won't be finished before the turn
of the century.

My conclusions:

First, we need to stop arguing and start work on solving the routing table
size and address space problems now, since it will take years to propagate
into the installed base.  From what I've seen so far, I'd prefer
IP-inside-IP, since it greatly reduces the number of places where things
get complicated (I router vendors, J routers and K regional network NOCs
instead of 1000 times as many application vendors, hosts and LAN
administrators, respectively).  However, if this can't be done for reasons
I'm unaware of, FTP is going to have to do the coding and suffer the
support/upgrade pain whether IPv7 is CLNP or 2x(RFC 791), and we'll live
with it.

Second, departure from "by the book" CLNP might be worthwhile, but we
shouldn't try to hang onto the name if we chose to do so.  Even something
that looks as simple as re-doing the NSAP format and address assignment is
likely to require code changes in both the packet forwarding and routing
protocol sections of most CLNP-capable routers.

James B. VanBokkelen, Exec. V.P.	26 Princess St., Wakefield, MA  01880
FTP Software Inc.			voice: [phone]