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).