oversized, number spaces is preferable to having number spaces
that are "just large enough". Larger spaces afford more
flexibility on the part of network designers and operators and
allow for further experimentation on the part of the scientists,
engineers, and developers. See [7].
Time Frame
A framework showing mechanisms for extending the protocol must be
provided immediately.
5.14 Network Service
CRITERION
The protocol must allow the network (routers, intelligent media,
hosts, and so on) to associate packets with particular service
classes and provide them with the services specified by those
classes.
DISCUSSION
For many reasons, such as accounting, security and multimedia, it
is desirable to treat different packets differently in the
network.
For example, multimedia is now on our desktop and will be an
essential part of future networking. So we have to find ways to
support it; and a failure to support it may mean users choose to
use protocols other than IPng.
The IETF multicasts have shown that we can currently support
multimedia over internetworks with some hitches. If the network
can be guaranteed to provide the necessary service levels for this
traffic, we will dramatically increase its success.
This criterion includes features such as policy-based routing,
flows, resource reservation, network service technologies, type-
of-service and quality-of-service and so on.
In order to properly support commercial provision and use of
Internetwork service, and account for the use of these services
(i.e., support the economic principle of "value paid for value
received") it must be possible to obtain guarantees of service
levels. Similarly, if the network can not support a previously
guaranteed service level, it must report this to those to whom it
guaranteed the service.
Network service provisions must be secure. The network-layer
security must generally prevent one host from surreptitiously
obtaining or disrupting the use of resources which another host
has validly acquired. (Some security failures are acceptable, but
the failure rate must be very low and the rate should be
quantifiable).
One of the parameters of network service that may be requested
must be cost-based.
As far as possible, given the limitations of underlying media and
IP's model of a robust internet datagram service, real-time,
mission-critical applications must be supported by IPng [6].
Users must be able to confirm that they are, in fact, getting the
services that they have requested.
Time Frame
This should be available within 24 months.
5.15 Support for Mobility
CRITERION
The protocol must support mobile hosts, networks and
internetworks.
DISCUSSION
Again, mobility is becoming increasingly important. Look at the
portables that everyone is carrying. Note the strength of the
Apple commercial showing someone automatically connecting up her
Powerbook to her computer back in the office. There have been a
number of pilot projects showing ways to support mobility in IPv4.
All have some drawbacks. But like network service grades, if we
can support mobility, IPng will have features that will encourage
transition.
We use an encompassing definition of "mobility" here. Mobility
typically means one of two things to people: 1) Hosts that
physically move and remain connected (via some wireless datalink)
with sessions and transport-layer connections remaining 'open' or
'active' and 2) Disconnecting a host from one spot in the network,
connecting it back in another arbitrary spot and continuing to
work. Both forms are required.
Reference [6] discusses possible future use of IP-based networks
in the US Navy's ships, planes, and shore installations. Their
basic model is that each ship, plane and shore installation
represents at least one IP network. The ship- and plane-based
networks, obviously, are mobile as these craft move around the
world. Furthermore, most, if not all, Naval surface combatants
carry some aircraft (at a minimum, a helicopter or two). So, not
only must there be mobile networks (the ships that move around),
but there must be mobile internetworks: the ships carrying the
aircraft where each aircraft has its own network, which is
connected to the ship's network and the whole thing is moving.
There is also the requirement for dynamic mobility; a plane might
take off from aircraft carrier A and land on carrier B so it
obviously would want to "connect" to B's network. This situation
might be even more complex since the plane might wish to retain
connectivity to its "home" network; that is, the plane might
remain connected to the ship-borne networks of both aircraft
carriers, A and B.
These requirements are not limited to just the navy. They apply
to the civilian and commercial worlds as well. For example, in
civil airliners, commercial cargo and passenger ships, trains,
cars and so on.
Time Frame
The mobility algorithms are stabilizing and we would hope to see
an IPng mobility framework within a year.
5.16 Control Protocol
CRITERION
The protocol must include elementary support for testing and
debugging networks.
DISCUSSION
An important feature of IPv4 is the ICMP and its debugging,
support, and control features. Specific ICMP messages that have
proven extraordinarily useful within IPv4 are Echo Request/Reply
(a.k.a ping), Destination Unreachable and Redirect. Functions
similar to these should be in IPng.
This criterion explicitly does not concern itself with
configuration related messages of ICMP. We believe that these are
adequately covered by the configuration criterion in this memo.
One limitation of today's ICMP that should be fixed in IPng's
control protocol is that more than just the IPng header plus 64
bits of a failed datagram should be returned in the error message.
In some situations, this is too little to carry all the critical
protocol information that indicates why a datagram failed. At
minimum, any IPng control protocol should return the entire IPng
and transport headers (including options or nested headers).
Time Frame
Support for these functions is required immediately.
5.17 Private Networks
CRITERION
IPng must allow users to build private internetworks on top of the
basic Internet Infrastructure. Both private IP-based
internetworks and private non-IP-based (e.g., CLNP or AppleTalk)
internetworks must be supported.
DISCUSSION
In the current Internet, these capabilities are used by the
research community to develop new IP services and capabilities
(e.g., the MBone) and by users to interconnect non-IP islands over
the Internet (e.g., CLNP and DecNet use in the UK).
The capability of building networks on top of the Internet have
been shown to be useful. Private networks allow the Internet to
be extended and modified in ways that 1) were not foreseen by the
original builders and 2) do not disrupt the day-to-day operations
of other users.
We note that, today in the IPv4 Internet, tunneling is widely used
to provide these capabilities.
Finally, we note that there might not be any features that
specifically need to be added to IPng in order to support the
desired functions (i.e., one might treat a private network protocol
simply as another IP client protocol, just like TCP or UDP). If
this is the case, then IPng must not prevent these functions from
being performed.
Time Frame
Some of these capabilities may be required to support other
criteria (e.g., transition) and as such, the timing of the
specifications is governed by the other criteria (e.g., immediately
in the case of transition). Others may be produced as desired.
6. Things We Chose Not to Require
This section contains items which we felt should not impact the
choice of an IPng. Listing an item here does not mean that a
protocol MUST NOT do something. It means that the authors do not
believe that it matters whether the feature is in the protocol or
not. If a protocol includes one of the items listed here, that's
cool. If it doesn't; that's cool too. A feature might be necessary in
order to meet some other criterion. Our point is merely that the
feature need not be required for its own sake.
6.1 Fragmentation
The technology exists for path MTU discovery. Presumably, IPng will
continue to provide this technology. Therefore, we believe that IPng
Fragmentation and Reassembly, as provided in IPv4, is not necessary.
We note that fragmentation has been shown to be detrimental to
network performance and strongly recommend that it be avoided.
6.2 IP Header Checksum
There has been discussion indicating that the IP Checksum does not
provide enough error protection to warrant its performance impact.
The argument states that there is almost always a stronger datalink
level CRC, and that end-to-end protection is provided by the TCP
checksum. Therefore we believe that an IPng checksum is not required
per-se.
6.3 Firewalls
Some have requested that IPng include support for firewalls. The
authors believe that firewalls are one particular solution to the
problem of security and, as such, do not consider that support for
firewalls is a valid requirement for IPng. (At the same time, we
would hope that no IPng is hostile to firewalls without offering some
equivalent security solution).
6.4 Network Management
Network Management properly is a task to be carried out by additional
protocols and standards, such as SNMP and its MIBs. We believe that
network management, per se, is not an attribute of the IPng protocol.
Furthermore, network management is viewed as a support, or service,
function. Network management should be developed to fit IPng and not
the other way round.
6.5 Accounting
We believe that accounting, like network management, must be designed
to fit the IPng protocol, and not the other way round. Therefore,
accounting, in and of itself, is not a requirement of IPng. However,
there are some facets of the protocol that have been specified to
make accounting easier, such as non-repudiation of origin under
security, and the unique naming requirement for sorting datagrams
into classes. Note that a parameter of network service that IPng
must support is cost.
6.6 Routing
Routing is a very critical part of the Internet. In fact, the
Internet Engineering Task Force has a separate Area which is
chartered to deal only with routing issues. This Area is separate
from the more general Internet Area.
We see that routing is also a critical component of IPng. There are
several criteria, such as Scaling, Addressing, and Network Services,
which are intimately entwined with routing. In order to stress the
critical nature and importance of routing, we have chosen to devote a
separate chapter to specifically enumerating some of the requirements
and issues that IPng routing must address. All of these issues, we
believe, fall out of the general criteria presented in the previous
chapter.
6.6.1 Scale
First and foremost, the routing architecture must scale to support
a very large Internet. Current expectations are for an Internet
of about 10**9 to 10**12 networks. The routing architecture must
be able to deal with networks of this size. Furthermore, the
routing architecture must be able to deal with this size without
requiring massive, global databases and algorithms. Such
databases or algorithms would, in effect, be single points of
failure in the architecture (which is not robust), and because of
the nature of Internet administration (cooperative anarchy), it
would be impossible to maintain the needed consistency.
6.6.2 Policy
Networks (both transit and non-transit) must be able to set their
own policies for the types of traffic that they will admit. The
routing architecture must make these policies available to the
network as a whole. Furthermore, nodes must be able to select
routes for their traffic based on the advertised policies.
6.6.3 QOS
A key element of the network service criteria is that differing
applications wish to acquire differing grades of network service.
It is essential that this service information be propagated around
the network.
6.6.4 Feedback
As users select specific routes over which to send their traffic,
they must be provided feedback from the routing architecture. This
feedback should allow the user to determine whether the desired
routes are actually available or not, whether the desired services
are being provided, and so forth.
This would allow users to modify their service requirements or
even change their routes, as needed.
6.6.5 Stability
With the addition of additional data into the routing system
(i.e., routes are based not only on connectivity, as in IPv4, but
also on policies, service grades, and so on), the stability of the
routes may suffer. We offer as evidence the early ARPANET which
experimented with load-based routing. Routes would remain in flux,
changing from one saturated link, to another, unused, link.
This must not be allowed to happen. If anything, routes should be
even more stable under IPng's routing architecture than under the
current architecture.
6.6.6 Multicast
Multicast will be more important in IPng than it is today in IPv4.
Multicast groups may be very large and very distributed.
Membership in multicast groups will be very dynamic. The routing
architecture must be able to cope with this.
Furthermore, the routing architecture must be able to build
multicast routes dynamically, based on factors such as group
membership, member location, requested and available qualities of
service, and so on.
7. References
[1] Internet Architecture Board, "IP Version 7", Draft 8, Work in
Progress, July, 1992.
[2] Gross, P., and P. Almquist, "IESG Deliberations on Routing and
Addressing", RFC1380, IESG Chair, IESG Internet AD, November
1992.
[3] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby,
"Toward the Future Internet Architecture", RFC1287, MIT, BBN,
CNRI, USC/Information Sciences Institute, UC Davis, December
1991.
[4] Dave Clark's paper at SIGCOMM '88 where he pointed out that the
design of TCP/IP was guided, in large part, by an ordered list of
requirements.
[5] Vecchi, M., "IPng Requirements: A Cable Television Industry
Viewpoint", RFC1686, Time Warner Cable, August 1994.
[6] Green, D., Irey, P., Marlow, D. and K. O'Donoghue, "HPN Working
Group Input to the IPng Requirements Solicitation, RFC1679,
NSWC-DD, August 1994.
[7] Bellovin, S., "On Many Addresses per Host", RFC1681, AT&T Bell
Laboratories, August 1994.
[8] Symington, S., Wood, D., and J. Pullen, "Modelling and Simulation
Requirements for IPng", RFC1667, Mitre Corporation and George
Mason University, August 1994.
[9] Internet Architecture Board, "Report of the IAB Workshop on
Security in the Internet Architecture, RFC1636, IAB, June 1994.
[10] Private EMAIL from Tony Li to IPNG Directorate Mailing List, 18
April 1994 18:42:05.
[11] Saltzer, J., On the Naming and Binding of Network Destinations",
RFC1498, M.I.T. Laboratory for Computer Science, August 1993.
[12] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC793, DARPA, September
1981.
[13] EMAIL from Robert Elz to the Big Internet mailing list,
approximately 4 May 1994.
[14] Chiappa, N., "Nimrod and IPng Technical Requirements", Work in
Progress.
8. Security Considerations
Security is not directly addressed by this memo. However, as this
memo codifies goals for a new generation of network layer protocol,
the security provided by such a protocol is addressed. Security has
been raised as an issue in several of the requirements stated in this
memo. Furthermore, a specific requirement for security has been
made.
9. Acknowledgements
The authors gratefully acknowledge the assistance and input provided
by the many people who have reviewed and commented upon this
document.
10. Authors' Addresses
Craig Partridge
BBN Systems and Technologies
10 Moulton St.
Cambridge, MA 02138
EMail: craig@aland.bbn.com
Frank Kastenholz
FTP Software, Inc.
2 High St.
North Andover, MA, 01845-2620 USA
EMail: kasten@ftp.com