📄 rfc851.txt
字号:
requirements will not be delivered, and will instead result in an error message being sent back into the source host. If the host places its 1822L address in this field, the address is checked to insure that it actually represents the host port where the message originated. If the message is destined for an 1822 host on a non-C/30 IMP, this field MUST contain the source host's 1822L address (see figure 4 in section 2.2.4). Bits 49-64: Destination Host: This field contains the 1822L name or address of the destination host. If it contains a name, the name will be checked for effectiveness, with an error message returned to - 33 - 1822L Host Access Protocol April 1983 RFC 851 the source host if the name is not effective. If the message is destined for an 1822 host on a non-C/30 IMP, this field MUST contain the destination host's 1822L address (see figure 4 in section 2.2.4). Bits 65-76: Message ID: This is a host-specified identification used in all type 0 and type 8 messages, and is also used in type 2 messages. When used in type 0 messages, bits 65-72 are also known as the Link Field, and should contain values specified in Assigned Numbers [4] appropriate for the host-to-host protocol being used. Bits 77-80: Sub-type: This field is used as a modifier by message types 0, 2, 4, and 8. Bits 81-96: Unused, must be zero. - 34 - 1822L Host Access Protocol April 1983 RFC 851 3.2 IMP-to-Host 1822L Leader Format 1 4 5 8 9 16 +--------+--------+----------------+ | | 1822L | | | Unused | I2H | Handling Type | | | Flag | | +--------+--------+----------------+ 17 20 21 22 24 25 32 +--------+-+------+----------------+ | |T|Leader| | | Unused |R|Flags | Message Type | | |C| | | +--------+-+------+----------------+ 33 48 +----------------------------------+ | | | Source Host | | | +----------------------------------+ 49 64 +----------------------------------+ | | | Destination Host | | | +----------------------------------+ 65 76 77 80 +-------------------------+--------+ | | | | Message ID |Sub-type| | | | +-------------------------+--------+ 81 96 +----------------------------------+ | | | Message Length | | | +----------------------------------+ Figure 7. IMP-to-Host 1822L Leader Format - 35 - 1822L Host Access Protocol April 1983 RFC 851 Bits 1-4: Unused and set to zero. Bits 5-8: 1822L IMP-to-Host Flag: This field is set to decimal 14 (1110 in binary). Bits 9-16: Handling Type: This has the value assigned by the source host (see section 3.1). This field is only used in message types 0, 5-9, and 15. Bits 17-20: Unused and set to zero. Bit 21: Trace Bit: If equal to one, the source host designated this message for tracing as it proceeds through the network. See 1822(5.5). Bits 22-24: Leader Flags: Bit 22: Available as a destination host flag. Bits 23-24: Reserved for future use, set to zero. Bits 25-32: Message Type: Type 0: Regular Message - All host-to-host communication occurs via regular messages, which have several sub- types. The sub-type field (bits 77-80) is the same as sent in the host-to-IMP leader (see section 3.1). Type 1: Error in Leader - See 1822(3.4). Type 2: IMP Going Down - See 1822(3.4). - 36 - 1822L Host Access Protocol April 1983 RFC 851 Type 3: NDM Reply - This is a reply to the NDM host-to-IMP message (see section 3.1). It will have the same number of entries as the NDM message that is being replying to, and each listed 1822L name will be accompanied by a zero or a one (see figure 6). A zero signifies that the name is not effective, and a one means that the name is now effective. Type 4: NOP - The host should discard this message. It is used during initialization of the IMP/host communication. The Destination Host field will contain the 1822L Address of the host port over which the NOP is being sent. All other fields are unused. Type 5: Ready for Next Message (RFNM) - See 1822(3.4). Type 6: Dead Host Status - See 1822(3.4). Type 7: Destination Host or IMP Dead (or unknown) - See 1822(3.4). Type 8: Error in Data - See 1822(3.4). Type 9: Incomplete Transmission - See 1822(3.4). Type 10: Interface Reset - See 1822(3.4). Type 11: Name Server Reply - This reply to the Name Server Request host-to-IMP message contains a word with the selection policy and the number of physical addresses to which the destination name maps, followed by two words per physical address: the first word contains an - 37 - 1822L Host Access Protocol April 1983 RFC 851 1822L address, and the second word contains a bit signifying whether or not that particular translation is effective and the routing distance (in 6.4 ms units) to the address's IMP. In figure 8, EFF is 1 for effective and 0 for non-effective, and POL is a two-bit number indicating the selection policy for the name (see section 2.2.2): 0: First reachable. 1: Closest physical address. 2: Load leveling. 3: Unused. - 38 - 1822L Host Access Protocol April 1983 RFC 851 1 16 17 32 33 48 +----------------+----------------+----------------+ | | | | | 0E00 | 000B | 0000 | | | | | +----------------+----------------+----------------+ 49 64 65 80 81 96 +----------------+----------------+----------------+ | | | | | dest. name | 0000 | 0000 | | | | | +----------------+----------------+----------------+ 97 112 113 128 129 144 +-+--------------+----------------+-+--------------+ |P| | |E| | |O| # of addrs | 1822L addr #1 |F| routing dist | |L| | |F| | +-+--------------+----------------+-+--------------+ 145 160 161 176 +----------------+-+--------------+ | |E| | | 1822L addr #2 |F| routine dist | etc. | |F| | +----------------+-+--------------+ Figure 8. Name Server Reply Format Type 12: Port List Reply - This is the reply to the Port List Request host-to-IMP message. It contains the number of names that map to this physical host port, followed by two words per name: the first word contains an 1822L name that maps to this port, and the second contains either a zero or a one, signifying whether or not that particular translation is effective. The format is identical to the type 3 NDM Reply message - 39 - 1822L Host Access Protocol April 1983 RFC 851 (see figure 6). Type 15: 1822L Name or Address Error - This message is sent in response to a type 0 message from a host that contained an erroneous Source Host or Destination Host field. Its sub-types are: 0: The Source Host 1822L name is not authorized or not effective. 1: The Source Host 1822L address does not match the host port used to send the message. 2: The Destination Host 1822L name is not authorized. 3: The physical host to which this singly-homed Destination Host name translated is authorized and up, but not effective. If the host was actually down, a type 7 message would be returned, not a type 15. 4: The Source or Destination Host field contains a 1822L name, but the host being addressed is on a non-C/30 IMP (see figure 4 in section 2.2.4). 5: The multi-homed Destination Host name is authorized, but has no available effective translations. 6: A logically-addressed uncontrolled packet was sent to a dead or non-effective host port. However, if it is resubmitted, there may be another effective host port to which the IMP may be able to attempt - 40 - 1822L Host Access Protocol April 1983 RFC 851 to send the packet. 7: Logical addressing is not in use in this network. 8-15: Unassigned. Types 13-14,16-255: Unassigned. Bits 33-48: Source Host: For type 0 messages, this field contains the 1822L name or address of the host that originated the message. All replies to the message should be sent to the host specified herein. For message types 5-9 and 15, this field contains the source host field used in a previous type 0 message sent by this host. Bits 49-64: Destination Host: For type 0 messages, this field contains the 1822L name or address that the message was sent to. This allows the destination host to detect how it was specified by the source host. For message types 5-9 and 15, this field contains the destination host field used in a previous type 0 message sent by this host. Bits 65-76: Message ID: For message types 0, 5, 7-9, and 15, this is the value assigned by the source host to identify the message (see section 3.1). This field is also used by message types 2 - 41 - 1822L Host Access Protocol April 1983 RFC 851 and 6. Bits 77-80: Sub-type: This field is used as a modifier by message types 0-2, 5-7, 9, and 15. Bits 81-96: Message Length: This field is contained in type 0, 3, 11, and 12 message
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -