As per Relevance of the word technical, we have this rfc below:
Network Working Group C.
Request for Comments: 1726 BBN Systems and
Category: Informational F.
FTP
December 1994
Technical Criteria for
IP The Next Generation (IPng
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document was submitted to the IPng Area in response to RFC 1550.
Publication of this document does not imply acceptance by the
Area of any ideas expressed within. Comments should be submitted
the big-internet@munnari.oz.au mailing list. This RFC
criteria related to mobility for consideration in design
selection of the Next Generation of IP
Table of
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Note on Terminology . . . . . . . . . . . . . . . . . . . 4
4. General Principles. . . . . . . . . . . . . . . . . . . . 4
4.1 Architectural Simplicity. . . . . . . . . . . . . . . . . 4
4.2 One Protocol to Bind Them All . . . . . . . . . . . . . . 4
4.3 Live Long . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4 Live Long AND Prosper . . . . . . . . . . . . . . . . . . 5
4.5 Co-operative Anarchy. . . . . . . . . . . . . . . . . . . 5
5. Criteria. . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Topological Flexibility . . . . . . . . . . . . . . . . . 8
5.3 Performance . . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Robust Service. . . . . . . . . . . . . . . . . . . . . . 10
5.5 Transition. . . . . . . . . . . . . . . . . . . . . . . . 12
5.6 Media Independence. . . . . . . . . . . . . . . . . . . . 13
5.7 Unreliable Datagram Service . . . . . . . . . . . . . . . 15
5.8 Configuration, Administration, and Operation. . . . . . . 16
5.9 Secure Operation. . . . . . . . . . . . . . . . . . . . . 17
5.10 Unique Naming . . . . . . . . . . . . . . . . . . . . . . 18
5.11 Access. . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.12 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 20
Partridge and Kastenholz [Page 1]
RFC 1726 IPng Technical Criteria December 1994
5.13 Extensibility . . . . . . . . . . . . . . . . . . . . . . 21
5.13.1 Algorithms. . . . . . . . . . . . . . . . . . . . . . . . 22
5.13.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.13.3 Data Structures . . . . . . . . . . . . . . . . . . . . . 22
5.13.4 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.14 Network Service . . . . . . . . . . . . . . . . . . . . . 22
5.15 Support for Mobility. . . . . . . . . . . . . . . . . . . 24
5.16 Control Protocol. . . . . . . . . . . . . . . . . . . . . 25
5.17 Private Networks. . . . . . . . . . . . . . . . . . . . . 25
6. Things We Chose Not to Require. . . . . . . . . . . . . . 26
6.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 26
6.2 IP Header Checksum. . . . . . . . . . . . . . . . . . . . 26
6.3 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4 Network Management. . . . . . . . . . . . . . . . . . . . 27
6.5 Accounting. . . . . . . . . . . . . . . . . . . . . . . . 27
6.6 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.6.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.2 Policy. . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.3 QOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.4 Feedback. . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.5 Stability . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.6 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . 30
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . 30
10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . 31
1.
This version of this memo was commissioned by the IPng area of
IETF in order to define a set of criteria to be used in
the protocols being proposed for adoption as the next generation
IP
The criteria presented here were culled from several sources
including "IP Version 7" [1], "IESG Deliberations on Routing
Addressing" [2], "Towards the Future Internet Architecture" [3],
IPng Requirements BOF held at the Washington D.C. IETF Meeting
December of 1992, the IPng Working Group meeting at the Seattle
meeting in March 1994, the discussions held on the Big-
mailing list (big-internet@munnari.oz.au, send requests to join
big-internet-request@munnari.oz.au), discussions with the IPng
Directors and Directorate, and the mailing lists devoted to
individual IPng efforts
This document presumes that a new IP-layer protocol is
desired. There is some discussion in the community as to whether
can extend the life of IPv4 for a significant amount of time
Partridge and Kastenholz [Page 2]
RFC 1726 IPng Technical Criteria December 1994
better engineering of, e.g., routing protocols, or we should
IPng now. This question is not addressed in this document
We would like to gratefully acknowledge the assistance of
hundreds of people who shared their views and insights with us
However, this memo is solely the personal opinion of the authors
in no way represents, nor should it be construed as representing,
opinion of the ISOC, the IAB, the IRTF, the IESG, the IETF,
Internet community as a whole, nor the authors' respective employers
2.
We believe that by developing a list of criteria for
proposals for IP The Next Generation (IPng), the IETF will make
easier for developers of proposals to prioritize their work
efforts and make reasoned choices as to where they should
relatively more and less time. Furthermore, a list of criteria
help the IETF community determine which proposals are
contenders for a next generation IP, and which proposals
insufficient to the task. Note that these criteria are probably
sufficient to make final decisions about which proposal is best
Questions such as whether to trade a little performance (e.g.,
packets per second routed) for slightly more functionality (e.g.,
more flexible routing) cannot be easily addressed by a simple list
criteria. However, at minimum, we believe that protocols that
these criteria are capable of serving as the future IPng
This set of criteria originally began as an ordered list, with
goal of ranking the importance of various criteria. Eventually,
layout evolved into the current form, where each criterion
presented without weighting, but a time frame,
approximately when a specific criterion, or feature of a criterion
should be available was added to the specification
We have attempted to state the criteria in the form of goals
requirements and not demand specific engineering solutions.
example, there has been talk in the community of making
aggregation a requirement. We believe that route aggregation is not
in and of itself, a requirement but rather one part of a solution
the real problem of scaling to some very large, complex topology
Therefore, route aggregation is NOT listed as a requirement; instead
the more general functional goal of having the routing scale
listed instead of the particular mechanism of route aggregation
In determining the relative timing of the various criteria, we
had two guiding principles. First, IPng must offer an
service akin to that of IPv4, but improved to handle the well-
and widely-understood problems of scaling the Internet
Partridge and Kastenholz [Page 3]
RFC 1726 IPng Technical Criteria December 1994
to more end-points and an ever increasing range of bandwidths
Second, it must be desirable for users and network managers
upgrade their equipment to support IPng. At a minimum, this
point implies that there must be a straightforward way to
systems from IPv4 to IPng. But it also strongly suggests that
should offer features that IPv4 does not; new features provide
motivation to deploy IPng more quickly
3. Note on
The existing proposals tend distinguish between end-
identification of, e.g., individual hosts, and topological
of network attachment points. In this memo we do not make
distinction. We use the term "address" as it is currently used
IPv4; i.e., for both the identification of a particular endpoint
host AND as the topological address of a point on the network.
presume that if the endpoint/ address split remains, the
will make the proper distinctions with respect to the
enumerated below
4. General
4.1 Architectural
In anything at all, perfection is finally attained
when there is no longer anything to add, but when
is no longer anything to take away
Antoine de Saint-
We believe that many communications functions are more
performed at protocol layers other than the IP layer. We
protocol stacks as hourglass-shaped, with IPng in the middle,
waist, of the hourglass. As such, essentially all higher-
protocols make use of and rely upon IPng. Similarly IPng, by
of its position in the "protocol hourglass" encompasses a
variety of lower-layer protocols. When IPng does not perform
particular function or provide a certain service, it should not
in the way of the other elements of the protocol stack which may
wish to perform the function
4.2 One Protocol to Bind Them
One of the most important aspects of The Internet is that it
global IP-layer connectivity. The IP layer provides the point
commonality among all of the nodes on the Internet. In effect,
main goal of the Internet is to provide an IP Connectivity Service
all who wish it
Partridge and Kastenholz [Page 4]
RFC 1726 IPng Technical Criteria December 1994
This does NOT say that the Internet is a One-Protocol Internet.
Internet is today, and shall remain in the future, a Multi-
Internet. Multi-Protocol operations are required to allow
continued testing, experimentation, and development and
service providers' customers clearly want to be able to run
such as CLNP, DECNET, and Novell over their Internet connections
4.3 Live
It is very difficult to change a protocol as central to the
of the Internet as IP. Even more problematic is changing such
protocol frequently. This simply can not be done. We believe that
is impossible to expect the community to make significant, non
backward compatible changes to the IP layer more often than
every 10-15 years. In order to be conservative, we strongly
protocol developers to consider what the Internet will look like
20 years and design their protocols to fit that vision
As a data point, the SNMP community has had great difficulty
from SNMPv1 to SNMPv2. Frequent changes in software are hard
4.4 Live Long AND
We believe that simply allowing for bigger addresses and
efficient routing is not enough of a benefit to encourage vendors
service providers, and users to switch to IPng, with its
disruptions of service, etc. These problems can be solved much
simply with faster routers, balkanization of the Internet
space, and other hacks
We believe that there must be positive functional or
benefits to switching to IPng
In other words, IPng must be able to live for a long time AND it
allow the Internet to prosper and to grow to serve new
and user needs
4.5 Co-operative
A major contributor to the Internet's success is the fact that
is no single, centralized, point of control or promulgator of
for the entire network. This allows individual constituents of
network to tailor their own networks, environments, and policies
suit their own needs. The individual constituents must
only to the degree necessary to ensure that they interoperate
Partridge and Kastenholz [Page 5]
RFC 1726 IPng Technical Criteria December 1994
We believe that this decentralized and decoupled nature of
Internet must be preserved. Only a minimum amount of
or forced cooperation will be tolerated by the community as a whole
We also believe that there are some tangible benefits to
decoupled nature. For example
* It is easier to experiment with new protocols and services and
roll out intermediate and final results in a controlled fashion
* By eliminating a single point of control, a single point of
is also eliminated, making it much less likely that the
network will fail
* It allows the administrative tasks for the network to be
widely distributed
An example of the benefits of this "Cooperative Anarchy" can be
in the benefits derived from using the Domain Naming System over
original HOSTS.TXT system
5.
This section enumerates the criteria against which we suggest the
The Next Generation proposals be evaluated
Each criterion is presented in its own section. The first
of each section is a short, one or two sentence statement of
criterion. Additional paragraphs then explain the criterion in
detail, clarify what it does and does not say and provide
indication of its relative importance
Also, each criterion includes a subsection called "Time Frame".
is intended to give a rough indication of when the authors
that the particular criterion will become "important". We
that if an element of technology is significant enough to include
this document then we probably understand the technology enough
predict how important that technology will be. In general,
time frames indicate that, within the desired time frame, we
be able to get an understanding of how the feature will be added to
protocol, perhaps after discussions with the engineers doing
development. Time Frame is not a deployment schedule
deployment schedules depend on non-technical issues, such as
determining whether a market exists, users fitting new releases
their systems, and so on
Partridge and Kastenholz [Page 6]
RFC 1726 IPng Technical Criteria December 1994
5.1
The IPng Protocol must scale to allow the identification
addressing of at least 10**12 end systems (and preferably
more). The IPng Protocol, and its associated routing
and architecture must allow for at least 10**9 individual
(and preferably more). The routing schemes must scale at a
that is less than the square root of the number of
networks [10].
The initial, motivating, purpose of the IPng effort is to
the Internet to grow beyond the size constraints imposed by
current IPv4 addressing and routing technologies
Both aspects of scaling are important. If we can't route
connecting all these hosts is worthless, but without
hosts, there's no point in routing, so we must scale in
directions
In any proposal, particular attention must be paid to
the routing hierarchy, how the routing and addressing will
organized, how different layers of the routing interact, and
relationship between addressing and routing
Particular attention must be paid to describing what happens
the size of the network approaches these limits. How are network
forwarding, and routing performance affected? Does
fall off or does the network simply stop as the limit is neared
This criterion is the essential problem motivating the
to IPng. If the proposed protocol does not satisfy this criteria
there is no point in considering it
We note that one of the white papers solicited for the
process [5] indicates that 10**12 end nodes is a
estimate based on the expected number of homes in the world
adding two orders of magnitude for "safety". However, this
paper treats each home in the world as an end-node of a world-
Internet. We believe that each home in the world will in fact
a network of the world-wide Internet. Therefore, if we take [5]'
derivation of 10**12 as accurate, and change their assumption
a home will be an end-node to a home being a network, we
expect that there will be the need to support at least 10**12
networks, with the possibility of supporting up to 10**15 end
nodes
Partridge and Kastenholz [Page 7]
RFC 1726 IPng Technical Criteria December 1994
Time
Any IPng proposal should be able to show immediately that it
an architecture for the needed routing protocols,
schemes, abstraction techniques, algorithms, data structures,
so on that can support growth to the required scales
Actual development, specification, and deployment of the
protocols can be deferred until IPng deployment has extended
enough to require such protocols. A proposed IPng should be
to demonstrate ahead of time that it can scale as needed
5.2 Topological
The routing architecture and protocols of IPng must allow for
different network topologies. The routing architecture
protocols must not assume that the network's physical structure
a tree
As the Internet becomes ever more global and ubiquitous, it
develop new and different topologies. We already see cases
the network hierarchy is very "broad" with many subnetworks,
with only a few hosts and where it is very "narrow", with
subnetworks each with many hosts. We can expect these and
topological forms in the future. Furthermore, since we
that IPng will allow for many more levels of hierarchy than
allowed under IPv4, we can expect very "tall" and very "short
topologies as well
Constituent organizations of the Internet should be allowed
structure their internal topologies in any manner they see fit
Within reasonable implementation limits, organizations should
allowed to structure their addressing in any manner.
specifically wish to point out that if the network's topology
addressing is hierarchical, constituent organizations should
able to allocate to themselves as many levels of hierarchy as
wish
It is very possible that the diameter of the Internet will grow
be extremely large; perhaps larger than 256 hops
Neither the current, nor the future, Internet will be
structured as a tree, nor can we assume that connectivity
occur only between certain points in the graph. The routing
addressing architectures must allow for multiply
networks and be able to utilize multiple paths for any reason
including redundancy, load sharing, type- and quality-of-
Partridge and Kastenholz [Page 8]
RFC 1726 IPng Technical Criteria December 1994
differentiation
Time
We believe that Topological Flexibility is an inherent element
a protocol and therefore should be immediately demonstrable in
IPng proposal
5.3
A state of the art, commercial grade router must be able
process and forward IPng traffic at speeds capable of
utilizing common, commercially available, high-speed media at
time. Furthermore, at a minimum, a host must be able to
data transfer rates with IPng comparable to the rates
with IPv4, using similar levels of host resources
Network media speeds are constantly increasing. It is
that the Internet's switching elements (routers) be able to
up with the media speeds
We limit this requirement to commercially available routers
media. If some network site can obtain a particular
technology "off the shelf", then it should also be able to
the needed routing technology "off the shelf." One can always
into some laboratory or research center and find newer, faster
technologies for network media and for routing. We do believe
however, that IPng should be routable at a speed sufficient
fully utilize the fastest available media, though that
require specially built, custom, devices
We expect that more and more services will be available over
Internet. It is not unreasonable, therefore, to expect that
ratio of "local" traffic (i.e., the traffic that stays on one'
local network) to "export" traffic (i.e., traffic destined to
sourced from a network other than one's own local network)
change, and the percent of export traffic will increase
We note that the host performance requirement should not be
to imply that IPng need only be as good as IPv4. If an
candidate can achieve better performance with equivalent
(or equivalent transfer rates with fewer resources) vis-a-vis IPv
then so much the better. We also observe that many
believe that a proper IPng router should be capable of
IPng traffic over links at speeds that are capable of
utilizing an ATM switch on the link
Partridge and Kastenholz [Page 9]
RFC 1726 IPng Technical Criteria December 1994
Some developments indicate that the use of very high speed point
to-point connections may become commonplace. In particular, [5]
indicates that OC-3 speeds may be widely used in the Cable
Industry and there may be many OC-3 speed lines connecting
central switching elements
Processing of the IPng header, and subsequent headers (such as
transport header), can be made more efficient by aligning
on their natural boundaries and making header lengths
multiples of typical word lengths (32, 64, and 128 bits have
suggested) in order to preserve alignment in following headers
We point out that optimizing the header's fields and lengths
to today's processors may not be sufficient for the long term
Processor word and cache-line lengths, and memory widths
constantly increasing. In doing header optimizations,
designer should predict word-widths one or two CPU
into the future and optimize accordingly. If IPv4 and TCP had
optimized for processors common when they were designed,
would be very efficient for 6502s and Z-80s
Time
An IPng proposal must provide a plausible argument of how it
scale up in performance. (Obviously no one can completely
the future, but the idea is to illustrate that if
trends in processor performance and memory performance continue
and perhaps using techniques like parallelism, there is reason
believe the proposed IPng will scale as technology scales).
5.4 Robust
The network service and its associated routing and
protocols must be robust
Murphy's Law applies to networking. Any proposed IPng
must be well-behaved in the face of malformed packets, mis
information, and occasional failures of links, routers and hosts
IPng should perform gracefully in response to willful
and configuration mistakes (i.e., service outages should
minimized).
Putting this requirement another way, IPng must make it
to continue the Internet tradition of being conservative in
is sent, but liberal in what one is willing to receive
Partridge and Kastenholz [Page 10]
RFC 1726 IPng Technical Criteria December 1994
We note that IPv4 is reasonably robust and any proposed IPng
be at least as robust as IPv4.
Hostile attacks on the network layer and Byzantine failure
must be dealt with in a safe and graceful manner
We note that Robust Service is, in some form, a part of
and vice-versa
The detrimental effects of failures, errors,
implementations, and misconfigurations must be localized as
as possible. For example, misconfiguring a workstation's
Address should not break the routing protocols. in the event
misconfigurations, IPng must to be able to detect and at
warn, if not work around, any misconfigurations
Due to its size, complexity, decentralized administration, error
prone users and administrators, and so on, The Internet is a
hostile environment. If a protocol can not be used in such
hostile environment then it is not suitable for use in
Internet
Some predictions have been made that, as the Internet grows and
more and more technically less-sophisticated sites get connected
there will be more failures in the network. These failures may
a combination of simple size; if the size of the network goes
by a factor of n, then the total number of failures in the
can be expected to increase by some function of n. Also, as
network's users become less sophisticated, it can be assumed
they will make more, innocent and well meaning, mistakes,
in configuration or use of their systems
The IPng protocols should be able to continue operating in
environment that suffers more, total, outages than we
currently used to. Similarly, the protocols must protect
general population from errors (either of omission or commission
made by individual users and sites
Time
We believe that the elements of Robust Service should be
immediately in the protocol with two exceptions
The security aspects of Robust Service are, in fact,
elsewhere in this document
Partridge and Kastenholz [Page 11]
RFC 1726 IPng Technical Criteria December 1994
Protection against Byzantine failure modes is not
immediately. A proposed architecture for it should be
immediately. Prototype development should be completed in 12-18
months, with final deployment as needed
5.5
The protocol must have a straightforward transition plan from
current IPv4.
A smooth, orderly, transition from IPv4 to IPng is needed. If
can't transition to the new protocol, then no matter how
it is, we'll never get to it
We believe that it is not possible to have a "flag-day" form
transition in which all hosts and routers must change over
once. The size, complexity, and distributed administration of
Internet make such a cutover impossible
Rather, IPng will need to co-exist with IPv4 for some period
time. There are a number of ways to achieve this co-
such as requiring hosts to support two stacks, converting
protocols, or using backward compatible extensions to IPv4.
scheme has its strengths and weaknesses, which have to be weighed
Furthermore, we note that, in all probability, there will be IPv
hosts on the Internet effectively forever. IPng must
mechanisms to allow these hosts to communicate, even after
has become the dominant network layer protocol in the Internet
The absence of a rational and well-defined transition plan is
acceptable. Indeed, the difficulty of running a network that
transitioning from IPv4 to IPng must be minimized. (A good
is that running a mixed IPv4-IPng network should be no more
preferably less difficult than running IPv4 in parallel
existing non-IP protocols).
Furthermore, a network in transition must still be robust.
schemes which maximize stability and connectivity in mixed IPv4-
IPng networks are preferred
Finally, IPng is expected to evolve over time and therefore,
must be possible to have multiple versions of IPng, some
production use, some in experimental, developmental, or
use, to coexist on the network. Transition plans must
this issue
Partridge and Kastenholz [Page 12]
RFC 1726 IPng Technical Criteria December 1994
The transition plan must address the following general areas
the Internet's infrastructure
Host Protocols and
Router Protocols and
Security and
Domain Name
Network
Operations Tools (e.g., Ping and Traceroute
Operations and Administration
The impact on protocols which use IP addresses as data (e.g., DNS
distributed file systems, SNMP and FTP) must be
addressed
The transition plan should address the issue of cost distribution
That is, it should identify what tasks are required of the
providers, of the end users, of the backbones and so on
Time
A transition plan is required immediately
5.6 Media
The protocol must work across an internetwork of many
LAN, MAN, and WAN media, with individual link speeds ranging
a ones-of-bits per second to hundreds of gigabits per second
Multiple-access and point-to-point media must be supported,
must media supporting both switched and permanent circuits
The joy of IP is that it works over just about anything.
generality must be preserved. The ease of adding
technologies, and ability to continue operating with
technologies must be maintained
We believe this range of speed is right for the next twenty years
though we may wish to require terabit performance at the high-end
We believe that, at a minimum, media running at 500 gigabits
second will be commonly available within 10 years. The low end
the link-speed range is based on the speed of systems like
and ELF (ELF connects to submerged submarines and has a "speed"
the order of <10 characters per second).
By switched circuits we mean both "permanent" connections such
X.25 and Frame Relay services AND "temporary" types of
connections similar to today's SLIP and dialup PPP services,
Partridge and Kastenholz [Page 13]
RFC 1726 IPng Technical Criteria December 1994
perhaps, ATM SVCs. The latter form of connection implies
dynamic network access (i.e., the ability to unplug a machine
move it to a different point on the network topology, and plug
back in, possibly with a changed IPng address) is required.
note that this is an aspect of mobility
By work, we mean we have hopes that a stream of IPng
(whether from one source, or many) can come close to filling
link at high speeds, but also scales gracefully to low speeds
Many network media are multi-protocol. It is essential that
be able to peacefully co-exist on such media with other protocols
Routers and hosts must be able to discriminate among the
that might be present on such a medium. For example, on
Ethernet, a specific, IPng Ethernet Type value might be
for; or the old IPv4 Ethernet type is used and the first
(version number in the old IPv4 header) bits would
between IPv4 and IPng
Different media have different MAC address formats and schemes
It must be possible for a node to dynamically determine the
address of a node given that node's IP address. We
prohibit using static, manually configured mappings as
standard approach
Another aspect of this criterion is that many different MTUs
be found in an IPng internetwork. An IPng must be able to
in such a multi-MTU environment. It must be able to adapt to
MTUs of the physical media over which it operates. Two
techniques for dealing with this are path MTU discovery
fragmentation and reassembly; other techniques might certainly
developed
We note that, as of this writing (mid 1994), ATM seems to be
to become a major network media technology. Any IPng should
designed to operate over ATM. However, IPng still must be able
operate over other, more "traditional" network media
Furthermore, a host on an ATM network must be able to
with a host on another, non-ATM, medium, with no more
or complexity than hosts on different media can interoperate
using IPv4.
IPng must be able to deal both with "dumb" media, such as we
today, and newer, more intelligent, media. In particular,
functions must be able to exist harmoniously with lower-
realizations of the same, or similar, functions. Routing
resource management are two areas where designers should
particular attention. Some subnetwork technologies may
Partridge and Kastenholz [Page 14]
RFC 1726 IPng Technical Criteria December 1994
integral accounting and billing capabilities, and IPng
provide the correct control information to such subnetworks
Time
Specifications for current media encapsulations (i.e.,
encapsulations that are currently Proposed standards, or higher
in the IETF) are required immediately. These specifications
include any auxiliary protocols needed (such as an
resolution mechanism for Ethernet or the link control protocol
PPP). A general 'guide' should also be available immediately
help others develop additional media encapsulations. Other
newer, encapsulations can be developed as the need
apparent
Van Jacobson-like header compression should be shown immediately
as should any other aspects of very-low-speed media. Similarly
any specific aspects of high-speed media should be
immediately
5.7 Unreliable Datagram
The protocol must support an unreliable datagram delivery service
We like IP's datagram service and it seems to work very well.
we must keep it. In particular, the ability, within IPv4, to
an independent datagram, without prearrangement, is
valuable (in fact, may be required for some applications such
SNMP) and must be retained
Furthermore, the design principle that says that we can take
datagram and throw it away with no warning or other action,
take any router and turn it off with no warning, and have
traffic still work, is very powerful. This vastly enhances
robustness of the network and vastly eases administration
maintenance of the network. It also vastly simplifies the
and implementation of software [14].
Furthermore, the Unreliable Datagram Service should support
minimal level of service; something that is
equivalent to IPv4 service. This has two functions; it eases
task of IPv4/IPng translating systems in mapping IPv4 traffic
IPng and vice versa, and it simplifies the task of fitting
into small, limited environments such as boot ROMs
Time
Unreliable Datagram Service must be available immediately
Partridge and Kastenholz [Page 15]
RFC 1726 IPng Technical Criteria December 1994
5.8 Configuration, Administration, and
The protocol must permit easy and largely
configuration and operation. Automatic configuration of hosts
routers is required
People complain that IP is hard to manage. We cannot plug
play. We must fix that problem
We do note that fully automated configuration, especially
large, complex networks, is still a topic of research.
concern is mostly for small and medium sized, less complex
networks; places where the essential knowledge and skills
not be as readily available
In dealing with this criterion, address assignment and
procedures and restrictions should be addressed by the proposal
Furthermore, "ownership" of addresses (e.g., user or
provider) has recently become a concern and the issue should
addressed
We require that a node be able to dynamically obtain all of
operational, IP-level parameters at boot time via a
configuration mechanism
A host must be able to dynamically discover routers on the host'
local network. Ideally, the information which a host learns
this mechanism would also allow the host to make a
selection of which first-hop router to send any given packet to
IPng must not mandate that users or administrators
configure first-hop routers into hosts
Also, a strength of IPv4 has been its ability to be used
isolated subnets. IPng hosts must be able to work on
without routers present
Additional elements of this criterion are
* Ease of address allocation
* Ease of changing the topology of the network within a
routing domain
* Ease of changing network provider
* Ease of (re)configuring host/endpoint parameters such
addressing and identification
* Ease of (re)configuring router parameters such as addressing
identification
Partridge and Kastenholz [Page 16]
RFC 1726 IPng Technical Criteria December 1994
* Address allocation and assignment authority must be delegated
far 'down' the administrative hierarchy as possible
The requirements of this section apply only to IPng and
supporting protocols (such as for routing, address resolution,
network-layer control). Specifically, as far as IPng
concerned, we are concerned only with how routers and hosts
their configuration information
We note that in general, automatic configuration of hosts is
large and complex problem and getting the
information into hosts and routers is only one, small, piece
the problem. A large amount of additional, non-Internet-
work is needed in order to be able to do "plug-and-play
networking. Other aspects of "plug-and-play" networking
things like: Autoregistration of new nodes with DNS,
security service systems (e.g., Kerberos), setting up email
and mail servers, locating network resources, adding entries
NFS export files, and so on. To a large degree,
capabilities do not have any dependence on the IPng
(other than, perhaps, the format of addresses).
We require that any IPng proposal not impede or prevent, in
way, the development of "plug-and-play" network
technologies
Automatic configuration of network nodes must not prevent users
administrators from also being able to manually configure
systems
Time
A method for plug and play on small subnets is
required
We believe that this is an extremely critical area for any IPng
a major complaint of the IP community as a whole is the
in administering large IP networks. Furthermore, ease
installation is likely to speed the deployment of IPng
5.9 Secure
IPng must provide a secure network layer
We need to be sure that we have not created a network that is
cracker's playground
Partridge and Kastenholz [Page 17]
RFC 1726 IPng Technical Criteria December 1994
In order to meet the Robustness criterion, some elements of
is commonly shrugged off as "security" are needed; e.g., to
a villain from injecting bogus routing packets, and destroying
routing system within the network. This criterion covers
aspects of security that are not needed to provide the
criterion
Another aspect of security is non-repudiation of origin. In
to adequately support the expected need for simple accounting,
believe that this is a necessary feature
In order to safely support requirements of the commercial world
IPng-level security must have capabilities to
eavesdroppers from monitoring traffic and deducing
patterns. This is particularly important in multi-access
such as cable TV networks [5].
Aspects of security at the IP level to be considered include
* Denial of service protections [6],
* Continuity of operations [6],
* Precedence and preemption [6],
* Ability to allow rule-based access control technologies [6]
* Protection of routing and control-protocol operations [9],
* Authentication of routing information exchanges, packets, data
and sources (e.g., make sure that the routing packet came from
router) [9],
* QOS security (i.e., protection against improper use of network
layer resources, functions, and capabilities),
* Auto-configuration protocol operations in that the host must
assured that it is getting its information from proper sources
* Traffic pattern confidentiality is strongly desired by
communities [9] and [5].
Time
Security should be an integral component of any IPng from
beginning
5.10 Unique
IPng must assign all IP-Layer objects in the global, ubiquitous
Internet unique names. These names may or may not have
location, topology, or routing significance
We use the term "Name" in this criterion synonymously with
term "End Point Identifier" as used in the NIMROD proposal, or
Partridge and Kastenholz [Page 18]
RFC 1726 IPng Technical Criteria December 1994
IP Addresses uniquely identify interfaces/hosts in IPv4.
names may or may not carry any routing or topology information
See [11] for more discussion on this topic
IPng must provide identifiers which are suitable for use
globally unique, unambiguous, and ubiquitous names for endpoints
nodes, interfaces, and the like. Every datagram must carry
identifier of both its source and its destination (or some
must be available to determine these identifiers, given
datagram). We believe that this is required in order to
certain accounting functions
Other functions and uses of unique names are
* To uniquely identify endpoints (thus if the unique name
address are not the same, the TCP pseudo-header should
the unique name rather than the address
* To allow endpoints to change topological location on the
(e.g., migrate) without changing their unique names
* To give one or more unique names to a node on the network (i.e.,
one node may have multiple unique names
An identifier must refer to one and only one object while
object is in existence. Furthermore, after an object ceases
exist, the identifier should be kept unused long enough to
that any packets containing the identifier have drained out of
Internet system, and that other references to the identifier
probably been lost. We note that the term "existence" is as
an administrative issue as a technical one. For example, if
workstation is reassigned, given a new IP address and node name
and attached to a new subnetwork, is it the same object or not
This does argue for a namespace that is relatively large
relatively stable
Time
We see this as a fundamental element of the IP layer and it
be in the protocol from the beginning
5.11
The protocols that define IPng, its associated protocols (
to ARP and ICMP in IPv4) and the routing protocols (as in OSPF
BGP, and RIP for IPv4) must be published as standards track
and must satisfy the requirements specified in RFC1310.
documents should be as freely available and redistributable as
IPv4 and related RFCs. There must be no specification-
licensing fees for implementing or selling IPng software
Partridge and Kastenholz [Page 19]
RFC 1726 IPng Technical Criteria December 1994
An essential aspect of the development of the Internet and
protocols has been the fact that the protocol specifications
freely available to anyone who wishes a copy. Beyond
minimizing the cost of learning about the technology, the
access to specifications has made it easy for researchers
developers to easily incorporate portions of old
specifications in the revised specifications. This type of
access to the standards documents is required for IPng
Time
An IPng and its related protocols must meet these standards
openness before an IPng can be approved
5.12
The protocol must support both unicast and multicast
transmission. Part of the multicast capability is a
to be able to send to "all IP hosts on a given subnetwork".
Dynamic and automatic routing of multicasts is also required
IPv4 has made heavy use of the ability to multicast requests
all IPv4 hosts on a subnet, especially for autoconfiguration
This ability must be retained in IPng
Unfortunately, IPv4 currently uses the local media
address to multicast to all IP hosts. This behavior is anti
social in mixed-protocol networks and should be fixed in IPng
There's no good reason for IPng to send to all hosts on a
when it only wishes to send to all IPng hosts. The protocol
make allowances for media that do not support true multicasting
In the past few years, we have begun to deploy support for wide
area multicast addressing in the Internet, and it has
valuable. This capability must not be lost in the transition
IPng
The ability to restrict the range of a multicast to
networks is also important. Furthermore, it must be possible
"selectively" multicast packets. That is, it must be possible
send a multicast to a remote, specific portion or area of
Internet (such as a specific network or subnetwork) and then
that multicast limited to just that specific area. Furthermore
any given network or subnetwork should be capable of
2**16 "local" multicast groups, i.e., groups that are
propagated to other networks. See [8].
Partridge and Kastenholz [Page 20]
RFC 1726 IPng Technical Criteria December 1994
It should be noted that addressing -- specifically the syntax
semantics of addresses -- has a great impact on the scalability
the architecture
Currently, large-scale multicasts are routed manually through
Internet. While this is fine for experiments, a "production
system requires that multicast-routing be dynamic and automatic
Multicast groups must be able to be created and destroyed,
must be able to join and leave multicast groups and the
routing infrastructure must be able to locate new multicast
and destinations and route traffic to those destinations
without manual intervention
Large, topologically dispersed, multicast groups (with up to 10**6
participants) must be supported. Some applications are given
[8].
Time
Obviously, address formats, algorithms for processing
interpreting the multicast addresses must be immediately
in IPng. Broadcast and Multicast transmission/reception
packets are required immediately. Dynamic routing of
packets must be available within 18 months
We believe that Multicast Addressing is vital to support
applications such as remote conferencing. It is also used
heavily in the current Internet for things like service
and routing
5.13
The protocol must be extensible; it must be able to evolve to
the future service needs of the Internet. This evolution must
achievable without requiring network-wide software upgrades.
is expected to evolve over time. As it evolves, it must be able
allow different versions to coexist on the same network
We do not today know all of the things that we will want
Internet to be able to do 10 years from now. At the same time,
is not reasonable to ask users to transition to a new
with each passing decade. Thus, we believe that it must
possible to extend IPng to support new services and facilities
Furthermore, it is essential that any extensions can
incrementally deployed to only those systems which desire to
them. Systems upgraded in this fashion must still be able
communicate with systems which have not been so upgraded
Partridge and Kastenholz [Page 21]
RFC 1726 IPng Technical Criteria December 1994
There are several aspects to extensibility
5.13.1
The algorithms used in processing IPng information should
decoupled from the protocol itself. It should be possible
change these algorithms without necessarily requiring protocol
datastructure, or header changes
5.13.2
The content of packet headers should be extensible. As
features and functions are required of IPng, it may
necessary to add more information to the IPng headers. We
that for IPv4, the use of options has proven less than
satisfactory since options have tended to be inefficient
process
5.13.3 Data
The fundamental data structures of IPng should not be
with the other elements of the protocol. E.g., things
address formats should not be intimately tied with the
and forwarding algorithms in the way that the IPv4
class mechanism was tied to IPv4 routing and forwarding
5.13.4
It should be possible to add additional packet-types to IPng
These could be for, _e._g., new control and/or
operations
We note that, everything else being equal, having larger
oversized, number spaces is preferable to having number
that are "just large enough". Larger spaces afford
flexibility on the part of network designers and operators
allow for further experimentation on the part of the scientists
engineers, and developers. See [7].
Time
A framework showing mechanisms for extending the protocol must
provided immediately
5.14 Network
The protocol must allow the network (routers, intelligent media
hosts, and so on) to associate packets with particular
classes and provide them with the services specified by
classes
Partridge and Kastenholz [Page 22]
RFC 1726 IPng Technical Criteria December 1994
For many reasons, such as accounting, security and multimedia,
is desirable to treat different packets differently in
network
For example, multimedia is now on our desktop and will be
essential part of future networking. So we have to find ways
support it; and a failure to support it may mean users choose
use protocols other than IPng
The IETF multicasts have shown that we can currently
multimedia over internetworks with some hitches. If the
can be guaranteed to provide the necessary service levels for
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
Internetwork service, and account for the use of these
(i.e., support the economic principle of "value paid for
received") it must be possible to obtain guarantees of
levels. Similarly, if the network can not support a
guaranteed service level, it must report this to those to whom
guaranteed the service
Network service provisions must be secure. The network-
security must generally prevent one host from
obtaining or disrupting the use of resources which another
has validly acquired. (Some security failures are acceptable,
the failure rate must be very low and the rate should
quantifiable).
One of the parameters of network service that may be
must be cost-based
As far as possible, given the limitations of underlying media
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
services that they have requested
Time
This should be available within 24 months
Partridge and Kastenholz [Page 23]
RFC 1726 IPng Technical Criteria December 1994
5.15 Support for
The protocol must support mobile hosts, networks
internetworks
Again, mobility is becoming increasingly important. Look at
portables that everyone is carrying. Note the strength of
Apple commercial showing someone automatically connecting up
Powerbook to her computer back in the office. There have been
number of pilot projects showing ways to support mobility in IPv4.
All have some drawbacks. But like network service grades, if
can support mobility, IPng will have features that will
transition
We use an encompassing definition of "mobility" here.
typically means one of two things to people: 1) Hosts
physically move and remain connected (via some wireless datalink
with sessions and transport-layer connections remaining 'open'
'active' and 2) Disconnecting a host from one spot in the network
connecting it back in another arbitrary spot and continuing
work. Both forms are required
Reference [6] discusses possible future use of IP-based
in the US Navy's ships, planes, and shore installations.
basic model is that each ship, plane and shore
represents at least one IP network. The ship- and plane-
networks, obviously, are mobile as these craft move around
world. Furthermore, most, if not all, Naval surface
carry some aircraft (at a minimum, a helicopter or two). So,
only must there be mobile networks (the ships that move around),
but there must be mobile internetworks: the ships carrying
aircraft where each aircraft has its own network, which
connected to the ship's network and the whole thing is moving
There is also the requirement for dynamic mobility; a plane
take off from aircraft carrier A and land on carrier B so
obviously would want to "connect" to B's network. This
might be even more complex since the plane might wish to
connectivity to its "home" network; that is, the plane
remain connected to the ship-borne networks of both
carriers, A and B
These requirements are not limited to just the navy. They
to the civilian and commercial worlds as well. For example,
civil airliners, commercial cargo and passenger ships, trains
cars and so on
Partridge and Kastenholz [Page 24]
RFC 1726 IPng Technical Criteria December 1994
Time
The mobility algorithms are stabilizing and we would hope to
an IPng mobility framework within a year
5.16 Control
The protocol must include elementary support for testing
debugging networks
An important feature of IPv4 is the ICMP and its debugging
support, and control features. Specific ICMP messages that
proven extraordinarily useful within IPv4 are Echo Request/
(a.k.a ping), Destination Unreachable and Redirect.
similar to these should be in IPng
This criterion explicitly does not concern itself
configuration related messages of ICMP. We believe that these
adequately covered by the configuration criterion in this memo
One limitation of today's ICMP that should be fixed in IPng'
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
protocol information that indicates why a datagram failed.
minimum, any IPng control protocol should return the entire
and transport headers (including options or nested headers).
Time
Support for these functions is required immediately
5.17 Private
IPng must allow users to build private internetworks on top of
basic Internet Infrastructure. Both private IP-
internetworks and private non-IP-based (e.g., CLNP or AppleTalk
internetworks must be supported
In the current Internet, these capabilities are used by
research community to develop new IP services and
(e.g., the MBone) and by users to interconnect non-IP islands
the Internet (e.g., CLNP and DecNet use in the UK).
The capability of building networks on top of the Internet
been shown to be useful. Private networks allow the Internet
Partridge and Kastenholz [Page 25]
RFC 1726 IPng Technical Criteria December 1994
be extended and modified in ways that 1) were not foreseen by
original builders and 2) do not disrupt the day-to-day
of other users
We note that, today in the IPv4 Internet, tunneling is widely
to provide these capabilities
Finally, we note that there might not be any features
specifically need to be added to IPng in order to support
desired functions (i.e., one might treat a private network
simply as another IP client protocol, just like TCP or UDP).
this is the case, then IPng must not prevent these functions
being performed
Time
Some of these capabilities may be required to support
criteria (e.g., transition) and as such, the timing of
specifications is governed by the other criteria (e.g.,
in the case of transition). Others may be produced as desired
6. Things We Chose Not to
This section contains items which we felt should not impact
choice of an IPng. Listing an item here does not mean that
protocol MUST NOT do something. It means that the authors do
believe that it matters whether the feature is in the protocol
not. If a protocol includes one of the items listed here, that'
cool. If it doesn't; that's cool too. A feature might be necessary
order to meet some other criterion. Our point is merely that
feature need not be required for its own sake
6.1
The technology exists for path MTU discovery. Presumably, IPng
continue to provide this technology. Therefore, we believe that
Fragmentation and Reassembly, as provided in IPv4, is not necessary
We note that fragmentation has been shown to be detrimental
network performance and strongly recommend that it be avoided
6.2 IP Header
There has been discussion indicating that the IP Checksum does
provide enough error protection to warrant its performance impact
The argument states that there is almost always a stronger
level CRC, and that end-to-end protection is provided by the
checksum. Therefore we believe that an IPng checksum is not
per-se
Partridge and Kastenholz [Page 26]
RFC 1726 IPng Technical Criteria December 1994
6.3
Some have requested that IPng include support for firewalls.
authors believe that firewalls are one particular solution to
problem of security and, as such, do not consider that support
firewalls is a valid requirement for IPng. (At the same time,
would hope that no IPng is hostile to firewalls without offering
equivalent security solution).
6.4 Network
Network Management properly is a task to be carried out by
protocols and standards, such as SNMP and its MIBs. We believe
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<