IEN 170
Danny Cohen
Jon Postel
USC / ISI
January 25th, 1980
ON IP-ADDRESSING
----------------
At some early point we agreed that an IP address is always a 32-bit
address, composed of 8-bit NET-ID, followed by a 24-bit "REST" field.
This implied that:
1. All the networks in our universe must have an 8-bit identifier;
and
2. All intra-net addresses must fit into a 24-bit field, somehow.
It also implies that:
3. Our gateways must know about all of our (up to) 256 networks.
Since it became clear that these assumptions may not reflect the real
world, which is outside of our IN group, we patched the situation by
defining Source Routing (SR) which was expected to be equivalent to the
Extensible-Addressing which should have been used initially.
However, the way our source route option is handled does not really
solve the situation. It appears as if the implementation of this
capability is optional, even though the documentation clearly states
that the implementation of the options is mandatory, only their use of
any given datagram is optional, as stated on p.29 of IEN-128.
We do not know how many gateways actually have implemented the source
routing options, if any. We doubt if any TCP implementation is actually
capable of communicating Source Routing to the IP level below it,
request a Return-Route and know how to handle it once it arrives at the
IP.
However, our definition of Source-Route as a sequence of IP-addresses
does not expand our addressing capabilities at all. Only IP-addresses
(which can be specified directly) may be specified by the Source-Route.
Both the direct addressing and the Source-Route are designed to specify
destinations which are under our control, in networks which agree to be
part of our addressing plan.
2
This a serious deficiency. Hosts on public nets, for example, require 14
digits of address which is beyond our 24-bits capability, likewise PUP
addresses require more than 24 bits.
In order to overcome this deficiency IEN-122 has suggested that
ESCAPE-CODEs be defined in the space of NET-ID's.
The idea of Escape-Codes met no objections, and was added to the (long)
list of wouldn't-it-be-nice's which were never implemented.
The introduction of the Escape-Codes into the NET-ID space requires no
change to the definitions of either IP or TCP which are already casted
in concrete. Therefore, LET'S DO IT, NOW !!!
The numbers-Czar would be willing, rumors say, to assign such Escape-
Code(s).
This still leaves us with the reality of lack of Source-Routing, even
though it is on the books.
Three approaches may be taken:
(A) Enforce implementation of Source Route as described
in the official documents, IEN-128.
(B) Recognize the mistake, apologize and re-do it right:
introduce Extensible- Addresses.
(C) Do nothing.
Obviously (B) is the toughest to implement, and (C) is the easiest.
We recommend that:
1. The implementation of Source-Routing (SR) be "enforced".
This includes both IP code in gateways and hosts, and its
interface to the higher level protocol (e.g., TCP).
2. ESCAPE-CODEs be defined in the space of NET-ID's, to allow
addressing extensions beyond the IP-world (e.g., dialup
lines, PUP and public networks).
mirror server hosted at Truenetwork, Russian Federation.