ARP servers at well-known addresses are introduced as an interim measure because current HYPERchannel products lack broadcast capability. Servers respond to unicast ARP requests using the standard ARP protocol (RFC-826), and the expectation is that as HYPERchannel gains broadcast support, ARP servers will fade away in favor of true broadcast ARP.

ip

IP address truncation (using low-order 16 bits of IP address as HYPERchannel address) is discouraged for long-term use because it only works for Class B addresses, is incompatible with Class A, Class C, subnetting, and 32-bit HYPERchannel addresses. Decoupling IP and HYPERchannel addresses via proper ARP allows IP addresses to be 'logical' (portable with a user) while HYPERchannel addresses remain 'physical'.

ip

The 32-bit Outnet bit (high-order bit of the adapter address field) was added for compatibility with existing A-series adapters, which examine only the 8-bit adapter address for delivery and would incorrectly accept transit messages. By setting this bit on messages destined for non-local networks, A-series adapters ignore such messages; the final bridge clears the bit before local delivery.

ip

The Cray-NASA Ames encapsulation (treating IP datagram as a contiguous block spanning Message Proper and Associated Data) was chosen over the Tektronix-Berkeley approach because: multiple vendors already support it; two-part message structure allows protocol decisions before staging large data transfers; and the Tektronix implementation breaks when IP headers exceed 54 bytes (relevant for DoD sites using IP options).

ip

IP drivers that use a logical TO address only (ignoring the message type field) will deliver any HYPERchannel message to a presumed IP destination regardless of message type. Transmitting drivers must generate the full 16-bit TO address to ensure compatibility; many existing 'closed' drivers accept all messages to their adapter regardless of the logical TO field.

ip

The Next Header Offset and Header End Offset fields (bytes 14–15) in the 32-bit header support optional loose source routing by listing additional 32-bit TO addresses. However, IP implementations are explicitly not required to implement this HYPERchannel source routing capability; when unused both fields are set to 16 (decimal).

ip

Two incompatible legacy IP-on-HYPERchannel driver families exist. The 'Cray-NASA Ames' family (widest deployment) is compatible with this standard except that bytes 8–9 are zero. The 'Tektronix-Berkeley' family always zeros bytes 8–11 and splits the IP datagram by placing TCP/UDP headers in the Associated Data separately from the IP header; it is not interoperable with this standard.

ip

A value of 0xFF SHOULD be placed in the Trunks to Try field (byte 0) to assure delivery over any HYPERchannel technology. For messages to destinations outside the immediate network, 0xFF in this byte ensures all possible trunks in intermediate networks are tried. Other values should only be used when specific site hardware requires it.

ip

In 16-bit encapsulation, the IP header offset in byte 11 (relative to byte 12) MUST take precedence over byte 9 on reception. In 32-bit encapsulation, receiving IP drivers MUST assume byte 9 contains a correct offset to the IP header; valid offsets are in the range 16–44 bytes inclusive.

ip

In the ARP protocol, if ARP information arrives that contradicts a static routing table entry (as opposed to previously set dynamic ARP information), the ARP information SHOULD be ignored. Static entries are presumed to provide authentication in broadcast ARP environments.

ip, security

The Access Code field (bytes 2–3) MUST contain 0x0000 in all IP encapsulations, as this field is reserved for future 32-bit addressing extensions. The Burst Mode and Exception bits in Message Flags MUST NOT be used with IP.

ip

The length of the Message Proper transmitted MUST always be 64 bytes, even if the IP datagram and HYPERchannel header do not occupy all 64 bytes. The length of associated data received MUST NOT be used to determine IP datagram length; the IP header's own length field must be used, as channel bus width constraints may cause padding.

ip

The value 6 MUST be placed in byte 8 of a 32-bit HYPERchannel message carrying IP traffic. For interoperability with older drivers, a value of 0 in byte 8 SHOULD be treated as a 16-bit address message. All IP drivers MUST be prepared to send and receive both basic (16-bit) and extended (32-bit) format messages.

ip

Transmitting IP drivers MUST place the value 5 (decimal) in byte 8 of a 16-bit HYPERchannel message to indicate IP traffic. Receiving IP drivers SHOULD presume a delivered message is an IP datagram regardless of the Message Type field contents, as many legacy implementations place zero in this field.

ip

A HYPERchannel network message consists of two parts: a Message Proper of 10–64 bytes (first 10 bytes used for delivery control, remainder available for higher-level protocols) and an optional Associated Data block of effectively unlimited length on HYPERchannel A trunks, or up to 4K bytes on HYPERchannel B or local A400 adapters.

ip

Broadcast messages are only supported with the 32-bit message format. A TO adapter address of 0xFF indicates a local-network broadcast; 0xFF in the Network or Domain fields expands broadcast scope. A Broadcast Channel number (in the low byte of the TO port field) filters which protocol servers receive the broadcast, analogous to an Ethernet multicast address.

ip, multicast

The Age Count field in the 32-bit message header serves the same purpose as the IP Time to Live: each bridge decrements it by one as the message passes through; when the result reaches zero the message is discarded. This prevents datagrams from circulating endlessly in improperly configured networks.

ip

The ARP Source and Destination HYPERchannel Address fields each contain Domain, Network, Adapter address, and Logical address/port (6 bytes total). A value of 0x0000 in Domain and Network fields signals that 16-bit HYPERchannel headers should be used rather than 32-bit headers, enabling mixed-mode networks.

ip

The CRC (End-End Message Integrity) flag in the 32-bit Message Flags causes newer-technology adapters to append a 32-bit CRC over the entire network message to the end of the Associated Data on transmission, and verify and strip it on reception. If a message arrives at the host with this bit still set, the associated data is four bytes longer than expected because the hardware CRC was not removed.

security, ip

The Message Type field (bytes 8–9) is a 16-bit formal protocol type designator. Major protocols are assigned a unique value in byte 8; minor protocols receive full 16-bit values. NSC maintains a network protocol registry for these assignments. The value 0xFF00 causes the receiving adapter to loop back the message without delivering it to the host.

ip, registry

The MTU field in ARP messages allows per-host negotiation of the maximum IP datagram size (IP header + data, not including HYPERchannel header or alignment offset). Transmitting drivers must send the minimum of source and destination MTUs negotiated at ARP time. The maximum representable MTU is 65536 (the largest IP datagram), stored in a 16-bit field by excluding header offset length.

ip, congestion

NSC established a network protocol registry for HYPERchannel message type values (bytes 8 and 9). Interested parties may obtain unique protocol type numbers by application to NSC; assigned values and their owners are periodically published. IP on 16-bit HYPERchannel is assigned type 5; IP on 32-bit HYPERchannel is assigned type 6; ARP is assigned 0x0700.

registry, ip

ARP is acknowledged to be trivially spoofable ('it's easy to lie with ARP'). The specification recommends that static routing table entries override any contradicting dynamic ARP information to provide authentication. ARP servers may optionally issue responses on a need-to-know basis in secure environments, enabled by the Source Correct bit in the ARP request.

security, ip

The SRC (Source From Address Correct) bit in the 32-bit Message Flags field allows intermediate adapters to verify the FROM address. If set by the transmitter, each intermediate adapter may clear this bit if the FROM address is not verifiable from that adapter's perspective. A host receiving a message with this bit still set can trust that reversing TO/FROM fields will reach the true originator.

security, ip

32-bit address recognition uses the following algorithm: accept a message if (Domain IN DomainMask) OR (Domain = MyDomain AND Network IN NetworkMask) OR (Domain = MyDomain AND Network = MyNetwork AND Address IN AddressMask); otherwise ignore. This allows each adapter to accept messages destined for itself, aliased addresses, and messages to be forwarded to configured remote networks or domains.

ip

The basic (16-bit) IP encapsulation places the IP on HYPERchannel type code 0x05 in byte 8, the offset to the IP header start in byte 9, the IP type designator 0x34 in byte 10, and the IP header offset relative to byte 12 in byte 11. The IP datagram begins at the offset indicated in byte 11, flows contiguously from the Message Proper into the Associated Data. The Message Proper is always transmitted as 64 bytes.

ip

The basic (16-bit) Message Proper header occupies bytes 0–9: byte 0 carries Trunks to Try (two 4-bit trunk masks) and Message Flags (A/D, BST, EXC bits); bytes 2–3 carry the Access Code; bytes 4–5 carry the 8-bit physical TO adapter address and port; bytes 6–7 carry the FROM adapter address and port; bytes 8–9 carry the Message Type.

ip

The extended (32-bit) IP encapsulation uses type code 0x06 in byte 8 and the GNA flag set in Message Flags. The IP datagram starts at the offset given in byte 9 (valid range 16–44). The Message Proper is always 64 bytes; if the datagram exceeds (64 - offset) bytes it spills into Associated Data. A receiving driver can read MP at buffer start and Associated Data at buffer+16 with no reshuffling.

ip

The extended (32-bit) Message Proper header extends to 16 bytes minimum: bytes 2–3 add TO Domain and Network numbers; byte 4 adds an Outnet bit to the adapter address; bytes 10–11 carry FROM Domain and Network; byte 12 carries Age Count; bytes 14–15 carry Next Header Offset and Header End Offset (normally 16); user protocol data begins at byte 16.

ip

The HYPERchannel ARP message is carried in a 32-bit message with type code 0x0700. The ARP body (at the Header End Offset) contains: ARP hardware type 8 (2 bytes), HYPERchannel protocol type 0x0600 (2 bytes), hardware address length 6 (1 byte), IP address length 4 (1 byte), opcode (2 bytes), sender's 32-bit HYPERchannel address + MTU (6 bytes), sender's IP address (4 bytes), and corresponding destination fields.

ip, dns