IP and ARP over HIPPI-6400 (GSN)
updated by
- rfc-5494 — IANA Allocation Guidelines for the Address Resolution Protocol (ARP)
Extracted elements (31)
HARP uses a two-phase protocol (registration then operational) because non-broadcast HIPPI-6400 switches require a centralized server for address resolution, while broadcast-capable switches can use direct ARP. The registration phase uses InHARP to detect broadcast capability and register with the server before entering operational mode.
PIBES is co-located with the HARP server because this memo does not define a protocol for exchanging the valid HARP table between separate entities. A broadcast emulation server inherently limits broadcast bandwidth to (total_bandwidth)/(n+1) for n ports; this is adequate for RIP, OSPF, and NIS but cannot support high-bandwidth broadcast.
The HRAL is ordered with broadcast address first so ports can probe for broadcast capability without prior knowledge of the network type. If a port receives its own InHARP_REQUEST, it is on a broadcast network; otherwise it proceeds to contact explicit server addresses in HRAL order.
The MTU of 65280 bytes was chosen to be backward compatible with HIPPI-800 and to allow the IP packet to fit in one 64K byte buffer with up to 256 bytes of overhead. HIPPI-6400 VC1 imposes a ~128KB limit, making 65280 the practical maximum that preserves HIPPI-800 interoperability.
HARP supports both HIPPI-800 (ar$hrd=28, ar$rhl/ar$thl=10) and HIPPI-6400 (ar$hrd=1 or 28, ar$rhl/ar$thl=6) hardware, enabling interoperability. The reply SHALL be in the format of the request.
HIPPI-6400 does not natively support multicast. IP multicast implementations (MBONE, IP tunneling) continue to operate over HIPPI-based LIS if all IP multicast packets are sent using the same algorithm as broadcast to 255.255.255.255.
A HARP client MUST respond to HARP_REQUEST and InHARP_REQUEST messages if it is the target port. For multiple IP addresses (aliases), the client MUST cycle through all IP addresses and generate an InHARP_REPLY for each.
A HARP server SHOULD use PIBES to send HARP_REPLYs to all hardware addresses in its table when mappings change, reducing stale entries in clients. The HARP server MUST update a HARP table entry's timeout for each HARP_REQUEST received.
All IP Datagrams SHALL be carried on HIPPI-6400-PH Virtual Channel 1 (VC1) and MUST be padded to a 32-byte granularity prior to sending. Added padding is transparent to IP and is not reflected in the IP header length field.
All members of a HIPPI-6400 LIS SHALL have the same IP network/subnet address and address mask. The HARP method and classical LIS routing model MUST be available to any IP member client in the LIS.
All solicited and unsolicited HARP_REPLYs from the authoritative HARP server SHALL be used to update and refresh the client's HARP table entries, enabling the server to push updates similar to gratuitous ARP on Ethernet.
An IP station MUST have a mechanism for permanent ARP table entries to allow interoperability with legacy HIPPI adapters using static ARP. The HARP server SHOULD use static entries to resolve incoming HARP_REQUESTs, eliminating the need for static tables on client ports. Permanent entries are not aged.
HARP table aging MUST be supported. A HARP client MUST invalidate table entries after 15 minutes; a HARP server MUST delete table entries after 20 minutes. A client MUST revalidate an invalidated entry before transmitting non-address-resolution traffic to it.
If a HARP client receives a message with an unknown operation code (ar$op), it MUST gracefully discard the message and continue normal operation. The client is NOT REQUIRED to return any message to the sender.
On non-broadcast hardware, a HARP client MUST refresh its HARP server table entry at least once every 15 minutes, via HARP request/reply exchange or by restarting registration. The timeout SHOULD be reset after each HARP_REQUEST/HARP_REPLY exchange to reduce redundant traffic.
PIBES MUST drop invalid messages (source not in target list or destination not an IP broadcast/multicast address). All valid incoming messages SHALL be forwarded to all addresses in the target list. It is RECOMMENDED that PIBES run on the same port as the HARP server.
The HARP_NAK message MUST be implemented. Its format is identical to the received HARP_REQUEST with the operation code changed to 10 (HARP_NAK); message fields are not swapped.
The HARP Request Address List (HRAL) MUST contain at least two HIPPI HW addresses. The first MUST be the broadcast address FF:FF:FF:FF:FF:FF and the second MUST be the standard HARP server address 00:10:3B:FF:FF:E0. All HARP clients MUST be configured identically with the same HRAL.
The HIPPI-6400 HARP SHALL support two packet formats: the generic Ethernet ARP format (ar$hrd=1) and the HIPARP format (ar$hrd=28). The ar$hrd field SHALL differentiate between the two formats, and the reply SHALL be in the format of the request.
To select the authoritative HARP service, a port SHALL send an InHARP_REQUEST to FF:FF:FF:FF:FF:FF first. If the port sees its own request, it is on a broadcast network and that address is authoritative. Otherwise, the port SHALL send to each remaining HRAL address; the first to reply and appearing earliest in the HRAL becomes authoritative.
HARP is a two-phase protocol: a registration phase (using InHARP to detect broadcast capability and register with the server) followed by an operational phase (using HARP_REQUESTs to the authoritative HRAL address to resolve IP-to-ULA mappings).
PIBES (Protocol for IP Broadcast Emulation Server) is required when the LIS does not support hardware broadcast. It uses the HARP server's current table as the target list, validates source addresses against this list, and forwards only packets addressed to IP LIS broadcast, multicast, or 255.255.255.255 to all addresses in the target list.
The HARP server maintains a table of <IP address(es), ULA> mappings with timestamps. It handles five cases of incoming InHARP_REQUEST entries: linked existing, unlinked existing, IP moved to new HW, new IP alias on existing HW, and fresh entry; each case has defined create/delete/link actions.
The MTU for HIPPI-6400 LANs SHALL be 65280 decimal bytes. This value is backward compatible with HIPPI-800 and allows an IP packet to fit in one 64K byte buffer with up to 256 bytes of overhead.
There are known security issues relating to port impersonation via ARP-based address resolution protocols. No special security mechanisms have been added to HARP. The full scope of ARP-over-HIPPI-6400 security issues was not fully understood at time of publication due to the fluid state of HIPPI-6400 specifications.
HARP client table entry states: PENDING (server entry created on interface init) transitions to VALID on receipt of InHARP_REPLY from server or own InHARP_REQUEST echo (broadcast case). VALID entries age to invalidated after 15 minutes client-side; server deletes entries after 20 minutes.
The Generic IEEE 802 ARP (HARP) message format uses ar$hrd=1 (Ethernet), ar$pro=2048, ar$hln=6, ar$pln=4, with ar$op values: 1=HARP_REQUEST, 2=HARP_REPLY, 8=InHARP_REQUEST, 9=InHARP_REPLY, 10=HARP_NAK.
The HIPARP message format uses ar$hrd=28 and a different field layout than generic ARP: fields are ar$hrd (16b), ar$pro (16b), ar$op (16b), ar$pln (8b), ar$rhl (8b, requester HW address length), ar$thl (8b, target HW address length), ar$rpa (32b), ar$tpa (32b), ar$rha (variable), ar$tha (variable). ar$rhl and ar$thl are 6 for HIPPI-6400, 10 for HIPPI-800.
The HIPPI-6400 MAC header consists of D_ULA (48-bit destination ULA), S_ULA (48-bit source ULA), and M_len (32-bit, set to IEEE 802 packet length plus 8 bytes for LLC/SNAP). Total header is 16 bytes; packet length must be a multiple of 32 bytes.
The IEEE 802.2 LLC/SNAP header is fixed at 8 bytes: SSAP=0xAA, DSAP=0xAA, CTL=0x03, OUI=0x000000 (3 bytes), followed by 2-byte Ethertype (0x0800 for IP, 0x0806 for HARP/ARP).
The Universal LAN MAC Address (ULA) is a 48-bit field in IEEE 802.1A canonical bit order. The L/U bit (bit 1 of byte 0) is 1 for locally administered addresses, 0 for universal; the G/I bit is 1 for group addresses, 0 for individual.