Broadcast emulation has an inherent performance upper bound of (total bandwidth)/(n+1) in a LIS with n ports, because each message must enter the broadcast server before being replicated. This is adequate for low-bandwidth protocols like RIP and OSPF but cannot support high-bandwidth broadcast traffic, which requires true hardware broadcast support.

ip

InHARP is used in the HARP registration phase for a purpose not originally intended by the InARP protocol: to accomplish registration of port IP address mappings with a HARP server if one exists, or to detect hardware broadcast capability by checking whether a port receives its own InHARP_REQUEST.

ip

The HRAP server sends HARP_REPLYs to all table entries when its mappings change (via PIBES), reducing stale entries in clients. This mirrors gratuitous ARP on Ethernet. Unsolicited HARP_REPLYs from the authoritative server SHALL be used by clients to update HARP table entries.

ip

The new HARP message format was introduced (changing from RFC-1374) to properly acknowledge the HIPPI hardware address format and to eliminate the requirement for HIPPI-LE ARP for HARP to function, while also adding forward interoperability with HIPPI-6400 whose 6-byte-only ULA hardware address is distinguishable by length.

ip

On broadcast-capable HIPPI networks, the client MAY also support Type 1 and 6 (Ethernet and IEEE 802 ARP) packet formats in addition to HIPARP type 28. HARP messages SHALL always be accepted with hardware type codes 28, 1, or 6 to enable interoperability.

ip

RFC 2834 also applies for resolving addresses used with the Scheduled Transfer Protocol (STP) over HIPPI-800 instead of IP. HARP message types and algorithms can be used for STP since it uses Internet Addresses, provided there is also an IP over HIPPI implementation on all ports.

ip

All members of a HIPPI 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.

ip

An IP station MUST have a mechanism for determining permanent (static) ARP table entries. These permanent entries allow interoperability with legacy HIPPI adapters that do not implement dynamic HARP. Permanent entries are not aged.

ip

During registration on a non-broadcast network, the client SHALL retry each non-broadcast HARP server address in the HRAL at least once every 5 seconds until registration completes. The authoritative server SHOULD be considered non-responsive after failing to reply to any two HARP_REQUESTs in the last 120 seconds.

ip

HARP clients MUST respond to HARP_REQUEST and InHARP_REQUEST messages if the port is the target. For ports with multiple IP addresses (aliases), the client MUST cycle through all IP addresses and generate an InHARP_REPLY for each. All solicited and unsolicited HARP_REPLYs from the authoritative server SHALL be used to update client HARP table entries.

ip

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. The client MUST revalidate an aged entry prior to transmitting any non-address-resolution traffic to that port.

ip

If a HARP client receives a HARP message with an operation code (ar$op) it does not support, it MUST gracefully discard the message and continue normal operation. A client is NOT REQUIRED to return any message to the sender of an undefined message.

ip

In the operational phase, the client SHALL send HARP_REQUESTs to the authoritative address and receive HARP_REPLYs to build its HARP table. A port is the target of an address resolution request if its IP address matches ar$tpa, its non-zero ULA matches the ULA in ar$tha, its switch address matches the Target Switch Address in ar$tha, or it is a HARP server.

ip

IP multicast packets over HIPPI SHALL be sent using the same algorithm as if the packet were sent to 255.255.255.255, since HIPPI does not directly support multicast addressing and there are no mappings from IP multicast addresses to HIPPI multicast services.

ip, multicast

On non-broadcast networks, a HARP client MUST refresh its entry for the HARP server at least once every 15 minutes, either by exchanging a HARP request/reply or by repeating the registration phase. This timeout SHOULD be reset after each HARP_REQUEST/HARP_REPLY exchange.

ip

Should the HIPPI-SC LAN not support broadcast, the HARP server(s) MUST emulate broadcast through a Protocol for Internet Broadcast Emulation Server (PIBES). This memo REQUIRES the PIBES extension to the HARP protocol, guaranteeing broadcast service to upper-layer protocols like IP.

ip, multicast

The HARP Request Address List (HRAL) MUST contain at least two HIPPI hardware addresses identifying HARP services. All HARP clients MUST be configured identically with the same HRAL. The first REQUIRED entry is the broadcast address (0x07000FE1, FF:FF:FF:FF:FF:FF) and the second REQUIRED entry is the official HARP server address (0x07000FE0, 00:00:00:00:00:00).

ip

The HIPPI hardware address of each IP port MUST contain the port's Switch Address. The address SHOULD also contain a non-zero ULA; if there is no ULA then that field MUST be zero.

ip

To select the authoritative HARP service, a port SHALL send an InHARP_REQUEST to the first HRAL address (broadcast). If the port sees its own request, the broadcast entry is authoritative. On non-broadcast networks, the port SHALL send to remaining HRAL entries; the authoritative server is the one appearing first in the HRAL that responds.

ip

ULA use is OPTIONAL but RECOMMENDED. ULA use is REQUIRED if a port wishes to interoperate with a conventional network (Ethernet, FDDI, 802 LAN). It is RECOMMENDED that all HARP servers run on ports with a non-zero ULA.

ip

HARP operation codes: 1 = HARP_REQUEST, 2 = HARP_REPLY, 8 = InHARP_REQUEST, 9 = InHARP_REPLY, 10 = HARP_NAK. HARP messages SHALL be transmitted with hardware type 28 (HIPARP) but SHALL be accepted with hardware type codes 28, 1, or 6.

ip

The HARP_NAK message is structurally identical to the received HARP_REQUEST message, with only the operation code changed from HARP_REQUEST (1) to HARP_NAK (10); the message data is copied byte-for-byte. HARP_NAK MUST be implemented.

ip

The HARP server maintains a table mapping IP addresses to HIPPI hardware addresses (switch address + ULA). When an InHARP_REQUEST arrives, the server performs one of five actions depending on whether the IP entry and HW entry already exist and are linked, including creating new entries, breaking old links, and adding new links.

ip

The PIBES uses the HARP server's current table as its target list. It SHALL validate that all incoming messages have source addresses in the target list and that messages are addressed to the IP LIS broadcast address, multicast address, or 255.255.255.255. Invalid messages MUST be dropped; valid messages are forwarded to all addresses in the target list.

ip, multicast

HARP messages are not authenticated, which is a potential flaw that could allow corrupt information to be introduced into the server system. There are known security issues relating to port impersonation via address resolution protocols as described in Bellovin's 'Security Problems in the TCP/IP Protocol Suite'. No special security mechanisms have been added to HARP.

security, ip

HARP is a two-phase protocol. In the registration phase, the port detects whether it is connected to broadcast-capable hardware by sending an InHARP_REQUEST to the broadcast address and checking if it receives its own message. If broadcast is detected, the port transitions directly to the operational phase; otherwise it registers with a HARP server and then transitions to operational.

ip

For HIPPI-800, the Hardware Address is a 10-byte unit containing a Mode Byte, two zero bytes, a 12-bit HIPPI logical switch address (XXX), and a 6-byte ULA. For HIPPI-6400, the hardware address is ONLY the 6-byte ULA; the length field (ar$rhl/ar$thl) of 10 versus 6 bytes distinguishes HIPPI-800 from HIPPI-6400.

ip

HARP message fields: ar$hrd (16-bit, SHALL be 28 = HIPARP), ar$pro (16-bit, SHALL be 2048 = IP), ar$op (16-bit operation code), ar$pln (8-bit, SHALL be 4), ar$rhl (8-bit requester HW address length, 10 for HIPPI-800 or 6 for HIPPI-6400), ar$thl (8-bit target HW address length), ar$rpa (32-bit requester IP), ar$tpa (32-bit target IP), ar$rha (variable requester HW address), ar$tha (variable target HW address).

ip

The HIPPI-LE header for HARP messages includes FC (3 bits, SHALL be 0), Message_Type (SHALL be 0 for data), Destination_Switch_Address, Destination_IEEE_Address (ULA or zero), Source_Switch_Address, Source_IEEE_Address, Destination_Address_Type (SHALL be 2), and Source_Address_Type (SHALL be 2). The LLC/SNAP header uses SSAP-DSAP-CTL = 0xAA-AA-03 and Ethertype 0x0806 (2054).

ip