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.