Network Working Group Atul Khanna, Andy Malis Request for Comments: 1005 BBN Communications Corp. May 1987 The ARPANET AHIP-E Host Access Protocol (Enhanced AHIP) 1. Status of this Memo This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the ARPANET AHIP Host Access Protocol (AHIP; formerly known as 1822). These enhancements increase the size of the PSN field, allow ARPANET hosts to use logical names to address each other, allow for the communication of type-of-service information from the host to the PSN and enable the PSN to provide congestion feedback to the host on a connection basis. Distribution of this memo is unlimited. Comments on this RFC should be sent to the netmail address "ahipe@bbn.com". Khanna & Malis [Page 1] RFC 1005 May 1987 Table of Contents 1 INTRODUCTION.......................................... 4 2 IP ISSUES............................................. 6 2.1 Current Interpretation of Class A IP Address Fields ................................................... 6 2.2 Requirements and Constraints Affecting New Class A Mapping ................................................... 7 2.3 New Interpretation of IP Address Fields............. 8 2.4 Discussion of the New Mapping.......................10 2.5 Interoperability between Current AHIP and AHIP-E ...................................................11 3 LOGICAL ADDRESSING................................... 13 3.1 Addresses and Names................................ 13 3.2 Name Translations.................................. 14 3.2.1 Authorization and Effectiveness.................. 15 3.2.2 Translation Policies............................. 16 3.2.3 Reporting Destination Host Downs................. 17 3.3 Establishing Host-PSN Communications............... 18 3.4 Name Server........................................ 19 4 OTHER CHANGES........................................ 20 4.1 Type-of-Service Specification...................... 20 4.2 Subnet Congestion Feedback......................... 21 4.3 Precedence Level Information....................... 21 5 FORMATS FOR NEW AHIP-E MESSAGES...................... 23 5.1 Host-to-PSN AHIP-E Leader Format................... 23 5.2 PSN-to-Host AHIP-E Leader Format................... 27 6 AHIP-E VERSIONS...................................... 33 7 REFERENCES........................................... 34 Khanna & Malis [Page 2] RFC 1005 May 1987 FIGURES 2.1 IP Class A Mapping................................... 6 2.2 New Class A IP Address Interpretation................ 8 2.3 AHIP-E Address and Name.............................. 9 3.1 Current AHIP Address Format......................... 13 3.2 AHIP-E Address Format............................... 14 3.3 Logical Name Format................................. 14 5.1 Host-to-PSN AHIP-E Leader Format.................... 23 5.2 NDM Message Format.................................. 25 5.3 PSN-to-Host AHIP-E Leader Format.................... 27 5.4 Name Server Reply Format............................ 30 Khanna & Malis [Page 3] RFC 1005 May 1987 1 INTRODUCTION This RFC is a proposed specification for the encoding of Class A IP addresses for use on ARPANET-style networks such as the Milnet and Arpanet, and for enhancements to the AHIP Protocol (AHIP is the preferred term for what has previously been known as the 1822 protocol). These enhancements and modifications are partially motivated by a need to overcome the current address limitation of 256 PSNs per network and by a desire to allow hosts to take advantage of logical addressing with minimal change to their AHIP software. This enhanced AHIP protocol will be referred to as "AHIP-E". These enhancements will: 1. Increase the size of the PSN field to 10 bits. 2. Allow hosts to use logical names (i.e., host names that are independent of physical location on the network) in addition to physical port addresses to communicate with each other. 3. Enable the host to specify a type-of-service to the PSN. 4. Provide a mechanism for the PSN to communicate subnetwork congestion information to the host on a destination host basis. This will give the host an opportunity to selectively reduce its congesting flows, thus preventing all of its flows from being blocked b y the network. Currently, a host has no way of knowing which of its flows is experiencing congestion; consequently, it is possible that one congesting flow can result in the blocking of all the host's flows . 5. Enable the PSN to inform the host about changes in precedence cutoff levels and about precedence level violations. A host can take advantage of the extended and logical addressing capabilities without making substantial changes to its AHIP implementation. In particular, the specification provides three versions of AHIP-E: version 0 is current AHIP with no changes; version 1 allows use of logical and extended addressing with minimal change to code; version 2 constitutes full-fledged AHIP-E. This is described in further detail in chapter 6. This RFC's terminology is consistent with that used in BBN Report 1822 [1], and any new terms are defined when they are first used. Familiarity with Report 1822 (section 3 in particular) is assumed. As could be expected, the RFC makes many references to Report 1822. As a result, it uses, as a convenient abbreviation, "see 1822(x)" instead of "please refer to Report 1822, section x, for further details". Khanna & Malis [Page 4] RFC 1005 May 1987 The rest of this RFC is organized as follows. Chapter 2 describes the new mapping between IP class A addresses and subnetwork hosts. Chapter 3 discusses logical addressing. Chapter 4 describes the enhancements related to type-of-service and reliability specification and to congestion and precedence feedback. Chapter 5 includes a specification of the new message types and their formats. Finally, chapter 6 describes the AHIP-E version numbering scheme. Khanna & Malis [Page 5] RFC 1005 May 1987 2 IP ISSUES This section discusses the changes to the mapping between Class A IP addresses [5] and subnet addresses. These changes are made necessary by: 1. The introduction of logical names. 2. The expansion of the PSN-number field. Note that this RFC does not affect Class B and C mappings [5]. 2.1 Current Interpretation of Class A IP Address Fields Class A IP addresses are 32 bits in length, with 8 bits devoted to network number and 24 to the local address. In particular, they are of the form n.h.l.i, where n,h,l and i are decimal integers less than 256. AHIP addresses are 24 bits in length. The current ARPANET-style class A mapping is as follows (from RFC 796): 0 7 8 15 16 23 24 31 +--------+--------+-------+---------+ | net # | HOST | LH | PSN | IP Address +--------+--------+-------+---------+ 8 8 8 8 8 8 8 +--------+--------+--------+ | HOST | ZERO | PSN | AHIP Physical Address +--------+--------+--------+ 41 48 49 56 57 64 (bit positions in the AHIP leader) IP Class A Mapping Figure 2.1 The LH (logical host) field is used by the hosts only and is not passed to the network. Khanna & Malis [Page 6] RFC 1005 May 1987 2.2 Requirements and Constraints Affecting New Class A Mapping This section discusses some of the requirements and constraints that were considered significant in determining the new address mapping. 1. Address Mapping Stability Requirement: Any current IP physical address with l (logical host) = 0 should remain unchanged under the new design. For example, the binary string corresponding to 10.0.0.51 should continue to refer to sri-nic.arpa (assuming, of course, that sri-nic continues to reside on psn 51, port 0). This requirement is motivated by a desire to avoid a network-wide address switchover. 2. Existing implementation compatibility: Existing compliant implementations of AHIP should continue to function for destinations with addresses fitting the restrictions in 1. In other words, such addresses should continue to refer to their original destinations, not only with the AHIP-E implementation (which is the condition in 1), but also with current ones. 3. Compatibility between X.25's IP address to subnet host mapping and AHIP's IP address to subnet host mapping: The AHIP-E IP to host mapping should be able to co-exist in some sense with the IP to host mapping specified by the DDN X.25 Specification [6]. In particular, restricted use of the revised IP to DDN host mapping should produce addresses that are consistent with the current X.25 mapping. In other words, there should be a set that includes "sufficiently many" logical names and physical addresses, with the property that each address/name in the set maps onto the same host under both the AHIP and X.25 mappings. 4. Maximum number of PSNs that can be supported: The new design should support a maximum of more than 256 PSNs per network. Khanna & Malis [Page 7] RFC 1005 May 1987 2.3 New Interpretation of IP Address Fields The following is the new interpretation of the IP address field, in the context of ARPANET-style networks: Proposed IP Address Interpretation 8 8 1 5 10 +--------+--------+-+-----+----------+ | net # | HOST |0|XXXXX| PSN | Physical Address +--------+--------+-+-----+----------+ 0 7 8 15 17 21 22 31 8 8 2 6 8 +--------+--------+--+------+--------+ | net # | UPPER |11|XXXXXX| LOWER | Logical Name +--------+--------+--+------+--------+ 0 7 8 15 18 23 24 31 16 2 14 +-----------------+--+---------------+ | |10| | Reserved Format +-----------------+--+---------------+ 0 15 18 31 (X = don't care) New Class A IP Address Interpretation Figure 2.2 The fields have the following meanings: HOST = host-number PSN = 10 bit PSN-number field UPPER = upper 8 bits of the 16-bit logical name LOWER = lower 8 bits of the 16-bit logical name Khanna & Malis [Page 8] RFC 1005 May 1987 AHIP-E physical addresses and logical names have the following formats: 8 1 5 10 +--------+-+-----+----------+ | HOST |0|XXXXX| PSN | Physical Address +--------+-+-----+----------+ 41 48 55 64 (bit positions in the AHIP leader) (X = don't care) 8 2 6 8 +--------+--+------+--------+ | UPPER |11|XXXXXX| LOWER | Logical Name +--------+--+------+--------+ 41 48 57 64 (bit positions in the AHIP leader) +--------+--+---------------+ | |10| | Reserved Address Format +--------+--+---------------+ 41 48 51 64 (bit positions in the AHIP leader) AHIP-E Address and Name Figure 2.3 The reserved address format is currently undefined and will be rejected by the PSN, which will return an error message (message type 6, subtype 3) to the host. ----------------------------------------------------------------- |This design does not require the AHIP-E host to do any processing| |of the address -- the host need only copy bits 8-31 of the IP | |address into bits 41-64 of the AHIP leader. The host no longer | |needs to zero out bits 49-56 of the AHIP leader. The PSN will | |take care of the AHIP to subnet address conversion. In other | |words, bits 8-31 of the IP address field should be passed | |unchanged to the PSN, which interprets them exactly as shown in | |figure 2.3. | ----------------------------------------------------------------- Khanna & Malis [Page 9] RFC 1005 May 1987 2.4 Discussion of the New Mapping This section presents an evaluation of the design in terms of the requirements in section 2.2 1. Address mapping stability requirement: Current physical IP addresses will not have to be changed, as long as they have been following the convention of setting LH = 0. This ensures that bit 16 is set to 0, indicating that the address is physical, and that the PSN number comes out right. 2. Existing implementation compatibility: The design meets this requirement, as the address that gets to the PSN has its second octet = 0, which results in its correct interpretation as a physical address. 3. Compatibility with the current X.25 IP address to DDN host mapping: The current X.25 IP to HOST mapping [6] is as follows: If h < 64, the address is considered physical, i.e., it refers to host h on PSN i. If h >= 64, the address is considered logical, i.e., it refers to the host whose logical name is h concatenated with i. The design is compatible in a limited sense with the current X.25 logical addressing implementation, as long as logical names are assigned such that host-number > 63 (also PSN-number < 256 which is automatic, given the 16-bit size of the logical name field) and physical addresses are in the range host- number < 64 and PSN- number < 256, with the appropriate setting of bits 16 and 17 of the IP address field. This works because the X