doc: Add RFC documents

1 files changed, 1907 insertions, 0 deletions

diff --git a/doc/rfc/rfc2834.txt b/doc/rfc/rfc2834.txt
new file mode 100644
index 0000000..40d1894
--- /dev/null
+++ b/doc/rfc/rfc2834.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Network Working Group                                        J.-M. Pittet
+Request for Comments: 2834                          Silicon Graphics Inc.
+Obsoletes: 1374                                                  May 2000
+Category: Standards Track
+
+
+                  ARP and IP Broadcast over HIPPI-800
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document specifies a method for resolving IP addresses to ANSI
+   High-Performance Parallel Interface (HIPPI) hardware addresses and
+   for emulating IP broadcast in a logical IP subnet (LIS) as a direct
+   extension of HARP. This memo defines a HARP that will interoperate
+   between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System
+   Network, GSN). This document (when combined with RFC-2067 "IP over
+   HIPPI") obsoletes RFC-1374.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
+       3.1 Global Concepts . . . . . . . . . . . . . . . . . . .   3
+       3.2 Glossary  . . . . . . . . . . . . . . . . . . . . . .   3
+   4.  IP Subnetwork Configuration . . . . . . . . . . . . . . .   5
+       4.1 Background  . . . . . . . . . . . . . . . . . . . . .   5
+       4.2 HIPPI LIS Requirements  . . . . . . . . . . . . . . .   6
+   5.  HIPPI Address Resolution Protocol - HARP  . . . . . . . .   7
+       5.1 HARP Algorithm  . . . . . . . . . . . . . . . . . . .   8
+           5.1.1 Selecting the authoritative HARP service  . . .   8
+           5.1.2 HARP registration phase . . . . . . . . . . . .   9
+           5.1.3 HARP operational phase  . . . . . . . . . . . .  10
+   5.2 HARP Client Operational Requirements  . . . . . . . . . .  11
+       5.3 Receiving Unknown HARP Messages . . . . . . . . . . .  12
+       5.4 HARP Server Operational Requirements  . . . . . . . .  12
+
+
+
+Pittet                      Standards Track                     [Page 1]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+       5.5 HARP and Permanent ARP Table Entries  . . . . . . . .  14
+       5.6 HARP Table Aging  . . . . . . . . . . . . . . . . . .  14
+   6.  HARP Message Encoding . . . . . . . . . . . . . . . . . .  15
+       6.1 HIPPI-LE Header of HARP Messages  . . . . . . . . . .  15
+           6.1.1 IEEE 802.2 LLC  . . . . . . . . . . . . . . . .  16
+           6.1.2 SNAP  . . . . . . . . . . . . . . . . . . . . .  16
+           6.1.3 Diagram . . . . . . . . . . . . . . . . . . . .  17
+       6.2 HIPPI Hardware Address Formats and Requirements . . .  18
+           6.2.1 48-bit Universal LAN MAC Addresses  . . . . . .  18
+       6.3 HARP and InHARP Message Formats . . . . . . . . . . .  19
+           6.3.1 Example Message encodings . . . . . . . . . . .  22
+           6.3.2 HARP_NAK message format . . . . . . . . . . . .  22
+           6.3.3 Combined HIPPI-LE and HARP message addresses  .  22
+   7.  Broadcast and Multicast . . . . . . . . . . . . . . . . .  23
+       7.1 Protocol for an IP Broadcast Emulation Server - PIBES  23
+       7.2 IP Broadcast Address  . . . . . . . . . . . . . . . .  24
+       7.3 IP Multicast Address  . . . . . . . . . . . . . . . .  24
+       7.4 A Note on Broadcast Emulation Performance . . . . . .  24
+   8.  HARP for Scheduled Transfer Protocol  . . . . . . . . . .  25
+   9.  Discovery of One's Own Switch Address . . . . . . . . . .  25
+   10. Security Considerations . . . . . . . . . . . . . . . . .  26
+   11. Open Issues . . . . . . . . . . . . . . . . . . . . . . .  26
+   12. HARP Examples . . . . . . . . . . . . . . . . . . . . . .  26
+       12.1 Registration Phase of Client Y on Non-broadcast HW .  27
+       12.2 Registration Phase of Client Y on Broadcast Hardware  28
+       12.3 Operational Phase (phase II) . . . . . . . . . . . .  28
+            12.3.1 Standard successful HARP_Resolve example  . .  29
+            12.3.2 Standard non-successful HARP_Resolve example   30
+   13. References  . . . . . . . . . . . . . . . . . . . . . . .  31
+   14. Acknowledgments . . . . . . . . . . . . . . . . . . . . .  32
+   15. Changes from RFC-1374 . . . . . . . . . . . . . . . . . .  32
+   16. Author's Address  . . . . . . . . . . . . . . . . . . . .  33
+   17. Full Copyright Statement  . . . . . . . . . . . . . . . .  34
+
+1. Introduction
+
+   The ANSI High-Performance Parallel Interface (HIPPI) is a dual
+   simplex data channel.   HIPPI can send and receive data
+   simultaneously at 800 or 1600 megabits per second. Between 1987 and
+   1997, the ANSI X3T11.1 HIPPI working group (now known as NCITS T11.1)
+   Standardized five documents that bear on the use of HIPPI as a
+   network interface.  They cover the physical and electrical
+   specification (HIPPI-PH [1]), the framing of a stream of bytes
+   (HIPPI-FP [2]), encapsulation of IEEE 802.2 LLC (HIPPI-LE [3]), the
+   behavior of a physical layer switch (HIPPI-SC [4]) and the physical-
+   level and optical specification (HIPPI-Serial [5]).  HIPPI-LE also
+   implies the encapsulation of Internet Protocol[5].  The reader should
+   be familiar with the ANSI HIPPI documents. Approved ANSI NCITS
+
+
+
+Pittet                      Standards Track                     [Page 2]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   standards are available from ANSI (http://www.ansi.org). The working
+   documents of the T11.1 working group may be obtained from the T11 web
+   page (http://www.t11.org/).
+
+   HIPPI switches can be used to connect a variety of computers and
+   peripheral equipment for many purposes, but the working group stopped
+   short of describing their use as Local Area Networks.  RFC-2067 [15]
+   describes the encapsulation of IP over HIPPI-800. This memo takes up
+   where the working group and RFC-2067 [15] left off and defines
+   address resolution and LIS IP broadcast emulation for HIPPI-800
+   networks.
+
+   While investigating possible solutions for HARP it became evident
+   that IP broadcast could easily be emulated for both HIPPI-800 and
+   HIPPI-6400 hardware types. This is useful since HIPPI switches are
+   not required to implement broadcast but many standard networking
+   protocols rely on broadcast.  This memo therefore further addresses
+   the emulation of LIS IP broadcast as an extension of HARP.
+
+2 Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC-2119 [18].
+
+3. Definitions
+
+3.1 Global concepts used
+
+   In the following discussion, the terms "requester" and "target" are
+   used to identify the port initiating the address resolution request
+   and the port whose address it wishes to discover, respectively.  If
+   not all switches in the LIS support broadcast then there will be a
+   HARP server providing the address resolution service and it will be
+   the source of the reply. If on the other hand all switches support
+   broadcast then the source address of a reply will be the target's
+   target address.
+
+   Values are decimal unless otherwise noted. Formatting follows IEEE
+   802.1A canonical bit order and and HIPPI-FP bit and byte order.
+
+3.2 Glossary
+
+   Broadcast
+
+   A distribution mode which transmits a message to all ports.
+   Particularly also the port sending the message.
+
+
+
+
+Pittet                      Standards Track                     [Page 3]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   Classical/Conventional
+
+   Both terms are used to refer to networks such as Ethernet, FDDI, and
+   other 802 LAN types, as distinct from HIPPI-SC LANs.
+
+   Destination
+
+   The HIPPI port that receives data from a HIPPI Source.
+
+   HARP
+
+   HARP describes the whole set of HIPPI address resolution encodings
+   and algorithms defined in this memo. HARP is a combination and
+   adaptation of the Internet Address Resolution Protocol (ARP) RFC-826
+   [13] and Inverse ARP (InARP) [7] (see section 5). HARP also describes
+   the HIPPI specific version of ARP [10] (i.e. the protocol and the
+   HIPPI specific encoding).
+
+   HARP table
+
+   Each host has a HARP table which contains the IP to hardware address
+   mapping of IP members.
+
+   HIPPI-Serial
+
+   An implementation of HIPPI in serial fashion on coaxial cable or
+   optical fiber. (see [5])
+
+   HRAL
+
+   The HARP Request Address List.  A list of ULAs to which HARP messages
+   are sent when resolving names to addresses (see section 4.2).
+
+   Hardware (HW) address
+
+   The hardware address of a port consisting of an I-Field and an
+   optional ULA (see section 6.2). Note: the term port as used in this
+   document refers to a HIPPI port and is roughly equivalent to the term
+   "interface" as commonly used in other IP documents.
+
+   Host
+
+   An entity, usually a computer system, that may have one or more HIPPI
+   ports and which may serve as a client or a HARP server.
+
+
+
+
+
+
+
+Pittet                      Standards Track                     [Page 4]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   Port
+
+   An entity consisting of one HIPPI Source/Destination dual simplex
+   pair that is connected by parallel or serial HIPPI to a HIPPI-SC
+   switch and that transmits and receives IP datagrams.
+
+   PIBES
+
+   The Protocol for Internet Broadcast Emulation Server (see section 7).
+
+   Switch Address
+
+   A value used as the address of a port on a HIPPI-SC network.  It is
+   transmitted in the I-field.  HIPPI-SC switches map Switch Addresses
+   to physical switch port numbers. The switch address is extended with
+   a mode byte to form an I-Field (see [4] and 6.2.2)
+
+   Source
+
+   The HIPPI port that generates data to send to a HIPPI Destination.
+
+   Universal LAN MAC Address (ULA)
+
+   A 48-bit globally unique address, administered by the IEEE, assigned
+   to each port on an Ethernet, FDDI, 802 network, or HIPPI-SC LAN.
+
+4.  IP Subnetwork Configuration
+
+4.1 Background
+
+   ARP (address resolution protocol) as defined in [12] was meant to
+   work on the 'local' cable. This definition gives the ARP protocol a
+   local logical IP subnet (LIS) scope. In the LIS scenario, each
+   separate administrative entity configures its hosts and routers
+   within the LIS. Each LIS operates and communicates independently of
+   other LIS's on the same HIPPI network.
+
+   HARP has LIS scope only and serves all ports in the LIS.
+   Communication to ports located outside of the local LIS is usually
+   provided via an IP router. This router is a HIPPI port attached to
+   the HIPPI network that is configured as a member of one or more
+   LIS's. This configuration MAY result in a number of disjoint LIS's
+   operating over the same HIPPI network. Using this model, ports of
+   different IP subnets SHOULD communicate via an intermediate IP router
+   even though it may be possible to open a direct HIPPI connection
+   between the two IP members over the HIPPI network. This is a
+   consequence of using IP and choosing to have multiple LIS's on the
+   same HIPPI fabric.
+
+
+
+Pittet                      Standards Track                     [Page 5]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   By default, the HARP method detailed in section 5 and the classical
+   LIS routing model MUST be available to any IP member client in the
+   LIS.
+
+4.2 HIPPI LIS Requirements
+
+   The requirement for IP members (hosts, routers) operating in a HIPPI
+   LIS configuration is:
+
+   o  All members of the LIS SHALL have the same IP network/subnet
+      address and address mask [6].
+
+   The following list identifies the set of HIPPI-specific parameters
+   that MUST be implemented in each IP station connected to the HIPPI
+   network:
+
+   o  HIPPI Hardware Address:
+
+      The HIPPI hardware address of an individual IP port MUST contain
+      the port's Switch Address (see section 9). The address SHOULD also
+      contain a non-zero ULA address. If there is no ULA then that field
+      MUST be zero.
+
+   o  HARP Request Address List (HRAL):
+
+      The HRAL is an ordered list of two or more addresses identifying
+      the address resolution service(s). All HARP clients MUST be
+      configured identically, i.e. all ports MUST have the same
+      addresses(es) in the HRAL.
+
+      The HRAL MUST contain at least two HIPPI HW addresses identifying
+      the individual HARP service(s) that have authoritative
+      responsibility for resolving HARP requests of all IP members
+      located within the LIS.
+
+      By default the first address MUST be the reserved address for
+      broadcast, i.e. the address for "IP traffic conventionally
+      directed to the IEEE 802.1 broadcast address: 0xFE1" [4]. The ULA
+      for this HARP service entry SHALL be FF:FF:FF:FF:FF:FF.
+
+      It is REQUIRED that the second address be the address for
+      "Messages pertaining to (the) ... address  resolution requests:
+      0xFE0" [4]. The ULA for this HARP server entry is
+      00:00:00:00:00:00.
+
+
+
+
+
+
+
+Pittet                      Standards Track                     [Page 6]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+Therefore, the HRAL entries are sorted in the following order:
+  1st **  : broadcast address            (0x07000FE1 FF:FF:FF:FF:FF:FF),
+  2nd **  : official HARP server address (0x07000FE0 00:00:00:00:00:00),
+  3rd & on: any additional HARP server addresses will be sorted in
+            decreasing order of the 12bit destination switch
+            address portion of their I-Field (see section 6.2).
+  ** REQUIRED
+
+   Within the restrictions mentioned above and in Section 6.2.2, local
+   administration choose address(es) for the additional HARP services
+   which they will put into the HRAL.
+
+   An example of such a list:
+      1st entry: 0x07000FE1 FF:FF:FF:FF:FF:FF
+      2nd entry: 0x07000FE0 00:00:00:00:00:00
+      3rd entry: 0x07000001 <Alternate-HARP-server-ula>
+      ...
+
+   Manual configuration of the addresses and address lists presented in
+   this section is implementation dependent and beyond the scope of this
+   memo.
+
+5. HIPPI Address Resolution Protocol - HARP
+
+   Address resolution within the HIPPI LIS SHALL make use of the HIPPI
+   Address Resolution Protocol (HARP) and the Inverse HIPPI Address
+   Resolution Protocol (InHARP). HARP provides the same functionality as
+   the Internet Address Resolution Protocol (ARP). HARP is based on ARP
+   which is defined in RFC-826 [13]. Knowing the Internet address,
+   conventional networks use ARP to discover another port's hardware
+   address. HARP presented in this section further specifies the
+   combination of the original protocol definitions to form a coherent
+   address resolution service that is independent of the hardware's
+   broadcast capability.
+
+   InHARP is based on the original Inverse ARP (InARP) protocol
+   presented in [7].  Knowing its hardware address, InARP is used to
+   discover the other party's Internet address.
+
+   This memo further REQUIRES the PIBES (see section 7 below) extension
+   to the HARP protocol, guaranteeing broadcast service to upper layer
+   protocols like IP.
+
+   Internet addresses are assigned independent of ULAs and switch
+   addresses.  Before using HARP, each port MUST know its IP and its
+   hardware addresses. The ULA is optional but is RECOMMENDED if
+   bridging to conventional networks is desired.
+
+
+
+
+Pittet                      Standards Track                     [Page 7]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+5.1 HARP Algorithm
+
+   This section defines the behavior and requirements for HARP
+   implementations on both broadcast and non-broadcast capable HIPPI-SC
+   networks. HARP creates a table in each port which maps the IP address
+   of each port to a hardware address, so that when an application
+   requests a connection to a remote port by its IP address, the
+   hardware address can be determined, a correct HIPPI-LE header can be
+   built, and a connection to the port can be established using the
+   correct Switch Address in the I-field.
+
+   HARP is a two phase protocol. The first phase is the registration
+   phase and the second phase is the operational phase. In the
+   registration phase the port detects if it is connected to broadcast
+   hardware or not.  The InHARP protocol is used in the registration
+   phase.  In case of non-broadcast capable hardware, the InHARP
+   Protocol will register and establish a table entry with the server.
+   The operational phase works much like conventional ARP with the
+   exception of the message format.
+
+5.1.1 Selecting the authoritative HARP service
+
+   Within the HIPPI LIS, there SHALL be an authoritative HARP service.
+   At each point in time there is only one authoritative HARP service.
+
+   To select the authoritative HARP service, each port needs to
+   determine if it is connected to a broadcast network.
+
+   The port SHALL send an InHARP_REQUEST to the first address in its
+   HRAL (0x07000FE1 FF:FF:FF:FF:FF:FF). If the port sees its own
+   InHARP_REQUEST, then it is connected to a broadcast capable network.
+   In this case, the rest of the HRAL is ignored and the authoritative
+   HARP service is the broadcast entry.
+
+   If the port is connected to a non-broadcast capable network, then the
+   port SHALL send the InHARP_REQUEST to all of the remaining entries in
+   the HRAL. Every address which sends an InHARP_REPLY is considered to
+   be a responsive HARP server. The authoritative HARP service SHALL be
+   the HARP server which appears first in the HRAL.
+
+   The sequence of the HRAL is only important for deciding which address
+   will be the authoritative one. On a non-broadcast network, the port
+   is REQUIRED to keep "registered" with all HARP server addresses in
+   the HRAL (NOTE: not the broadcast address since it is not a HARP
+   server address). If for instance the authoritative HARP service is
+   non-responsive,  then the port will consider the next address in the
+   HRAL as a candidate for the authoritative address and send an
+   InHARP_REQUEST.
+
+
+
+Pittet                      Standards Track                     [Page 8]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   The authoritative HARP server SHOULD be considered non-responsive
+   when it has failed to reply to: (1) one or more registration requests
+   by the client (see section 5.1.2 and 5.2), (2) any two HARP_REQUESTs
+   in the last 120 seconds or (3) if an external agent has detected
+   failure of the authoritative HARP server. The details of such an
+   external agent and its interaction with the HARP client are beyond
+   the scope of this document. Should an authoritative HARP server
+   become non-responsive, then the registration process SHOULD be
+   restarted. Alternative methods for choosing an authoritative HARP
+   service are not prohibited.
+
+5.1.2 HARP registration phase
+
+   HARP clients SHALL initiate the registration phase by sending an
+   InHARP_REQUEST message using the addresses in the HRAL in order. The
+   client SHALL terminate the registration phase and transition into the
+   operational phase, either when it receives its own InHARP_REQUEST or
+   when it receives an InHARP_REPLY from at least one of the HARP
+   servers and when it has determined the authoritative HARP service as
+   described in section 5.1.1.
+
+   When ports are initiated they send an InHARP_REQUEST to the
+   authoritative address as described in section 5.1.2. The first
+   address to be tried will be the broadcast address "0x07000FE1
+   FF:FF:FF:FF:FF:FF". There are two outcomes:
+
+   1. The port sees its own InHARP_REQUEST: then the port is connected
+      to a broadcast capable network. The first address becomes and
+      remains the authoritative address for the HARP service.
+
+   2. The port does not receive its InHARP_REQUEST: then the port is
+      connected to a non-broadcast capable network.
+
+   In the second case, the port SHALL choose the next address in the
+   HRAL as a candidate for a authoritative address and send an
+   InHARP_REQUEST to that address: (0x07000FE0 00:00:00:00:00:00).
+
+   o  If the port receives its own message, then the port itself is the
+      HARP server and the port is REQUIRED to provide broadcast services
+      using the PIBES (see section 7).
+
+   o  If the port receives an InHARP_REPLY, then it is a HARP client and
+      not a HARP server.
+
+   In both cases, the current candidate address becomes the
+   authoritative HARP service address.
+
+
+
+
+
+Pittet                      Standards Track                     [Page 9]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   If the client determines it is connected to a non-broadcast capable
+   network then the client SHALL continue to retry each non-broadcast
+   HARP server address in the HRAL at least once every 5 seconds until
+   one of these two termination criteria are met for each address.
+
+   InHARP is an application of the InARP protocol for a purpose not
+   originally intended.  The purpose is to accomplish registration of
+   port IP address mappings with a HARP server if one exists or detect
+   hardware broadcast capability.
+
+   If the HIPPI-SC LAN supports broadcast, then the client will see its
+   own InHARP_REQUEST message and SHALL complete the registration phase.
+   The client SHOULD further note that it is connected to a broadcast
+   capable network and use this information for aging the HARP server
+   entry and for IP broadcast emulation as specified in sections 5.4 and
+   5.6 respectively.
+
+   If the client doesn't see its own InHARP_REQUEST, then it SHALL await
+   an InHARP_REPLY before completing the registration phase. This will
+   also provide the client with the protocol address by which the HARP
+   server is addressable.  This will be the case when the client happens
+   to be  connected to a non-broadcast capable HIPPI-SC network.
+
+5.1.3 HARP operational phase
+
+   Once a HARP client has completed its registration phase it enters the
+   operational phase. In this phase of the protocol, the HARP client
+   SHALL gain and refresh its own HARP table which contains the IP to HW
+   address mapping of IP members by sending HARP_REQUESTS to the
+   authoritative address in the HRAL and receiving HARP_REPLYs. The
+   client is fully operational during the operational phase.
+
+   In the operational phase, the client's behavior for requesting HARP
+   resolution is the same for broadcast or non-broadcast networks.
+
+   The target of an address resolution request updates its address
+   mapping tables with any new information it can find in the request.
+   If it is the target port it SHALL formulate and send a reply message.
+   A port is the target of an address resolution request if at least ONE
+   of the following statements is true of the request:
+
+   1. The port's IP address is in the target protocol address field
+      (ar$tpa) of the HARP message.
+
+   2. The port's ULA (if non-zero), is in the ULA part of the Target
+      Hardware Address field (ar$tha) of the message.
+
+
+
+
+
+Pittet                      Standards Track                    [Page 10]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   3. The port's switch address is in the Target Switch Address field of
+      Target Hardware Address field (ar$tha) of the message (see section
+      6.2.2).
+
+   4. The port is a HARP server.
+
+   NOTE: It is RECOMMENDED that all HARP servers run on a ports which
+   each have a non-zero ULA.
+
+5.2 HARP Client Operational Requirements
+
+   The HARP client is responsible for contacting the HARP server(s) to
+   have its own HARP information registered and to gain and refresh its
+   own HARP entry/information about other IP members. This means, as
+   noted above, that HARP clients MUST be configured with the hardware
+   address of the HARP server(s) in the HRAL.
+
+   HARP clients MUST:
+
+   1. When an interface is enabled (e.g. "ifconfig <interface> up" with
+      an IP address) or assigned the first or an additional IP address
+      (i.e. an IP alias), the client SHALL initiate the registration
+      phase.
+
+   2. In the operational phase the client MUST respond to HARP_REQUEST
+      and InHARP_REQUEST messages if it is the target port.  If an
+      interface has multiple IP addresses (e.g., IP aliases) then the
+      client MUST cycle through all the IP addresses and generate an
+      InHARP_REPLY for each such address. In that case an InHARP_REQUEST
+      will have multiple replies. (Refer to Section 7, "Protocol
+      Operation" in RFC-1293  [7].)
+
+   3. React to address resolution reply messages appropriately to build
+      or refresh its own client HARP table entries. All solicited and
+      unsolicited HARP_REPLYs from the authoritative HARP server SHALL
+      be used to update and refresh its own client HARP table entries.
+
+      Explanation: This allows the HARP server to update the clients
+      when one of server's mappings change, similar to what is
+      accomplished on Ethernet with gratuitous ARP.
+
+   4. Generate and transmit InHARP_REQUEST messages as needed  and
+      process InHARP_REPLY messages appropriately (see section 5.1.2 and
+      5.6). All InHARP_REPLY messages SHALL be used by the client to
+      build or refresh its HARP table entries.  (Refer to Section 7,
+      "Protocol Operation" in [7].)
+
+
+
+
+
+Pittet                      Standards Track                    [Page 11]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   If the registration phase showed that the hardware does not support
+   broadcast, then the client MUST refresh its own entry for the HARP
+   server, created during the registration phase, at least once every 15
+   minutes. This can be accomplished either through the exchange of a
+   HARP request/reply with the HARP server or by repeating step 1. To
+   decrease the redundant network traffic, this timeout SHOULD be reset
+   after each HARP_REQUEST/HARP_REPLY exchange.
+
+   Explanation: The HARP_REQUEST shows the HARP server that the client
+   is still alive. Receiving a HARP_REPLY indicates to the client that
+   the server must have seen the HARP_REQUEST.
+
+   If the registration phase shows that the underlying network supports
+   broadcast, then periodic InHARP_REQUEST/InHARP_REPLY operations of
+   step 4 are NOT REQUIRED.
+
+5.3 Receiving Unknown HARP Messages
+
+   If a HARP client receives a HARP message with an operation code
+   (ar$op) that it does not support, it MUST gracefully discard the
+   message and continue normal operation.  A HARP client is NOT REQUIRED
+   to return any message to the sender of the undefined message.
+
+5.4 HARP Server Operational Requirements
+
+   A HARP server MUST accept HIPPI connections from other HIPPI ports.
+   The HARP server expects an InHARP_REQUEST as the first message from
+   the client. A server examines the IP source address, the hardware
+   source address of the InHARP_REQUEST and adds or updates its HARP
+   table entry <IP address(es), switch address, ULA>  as well as the
+   time stamp.
+
+   A HARP server SHALL reply to HARP_REQUESTs and InHARP_REQUESTs based
+   on the information which it has in its HARP table.  The HARP server
+   SHALL reply with a HARP_REPLY or a InHARP_REPLY, if it has the
+   requested information in its tables; otherwise it SHALL reply with a
+   HARP_NAK. The HARP server replies SHALL contain the hardware type and
+   corresponding format of the request (see also section 6).
+
+   The following table shows all possible source address combinations on
+   an incoming message and the actions to be taken. "linked" indicates
+   that an existing "IP entry" is linked to a "hardware entry". It is
+   possible to have an existing "IP entry" and to have an existing
+   "hardware entry" but neither is linked to the other.
+
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 12]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+      +---+----------+----------+------------+---------------------+
+      | # | IP entry | HW entry |  misc      |      Action         |
+      +---+----------+----------+------------+---------------------+
+      | 1 |  exists  |  exists  |     linked | *                   |
+      | 2 |  exists  |  exists  | not linked | *, a, b,       e, f |
+      | 3 |  exists  |    new   | not linked | *, a, b,    d, e, f |
+      | 4 |   new    |  exists  | not linked | *,       c,    e, f |
+      | 5 |   new    |    new   | not linked | *,       c, d, e, f |
+      +---+----------+----------+------------+---------------------+
+      Actions:
+      *: update timeout value
+      a: break the existing IP -> hardware (HW) - old link
+      b: delete HW(old) -> IP link and decrement HW(old) refcount, if
+         refcount = 0, delete HW(old)
+      c: create new IP entry
+      d: create new HW entry
+      e: add new IP -> HW link to IP entry
+      f: add new HW -> IP link to HW entry
+
+   Examples of when this could happen (Numbers match lines in above
+   table):
+
+   1: supplemental message
+
+      Just update timer.
+
+   2: move an IP alias to an existing interface
+
+      If the IP source address of the InHARP_REQUEST duplicates a table
+      entry IP address (e.g. IPa <-> HWa) and the InHARP_REQUEST
+      hardware source address matches a hardware address entry (e.g. HWb
+      <-> IPb), but they are not linked together, then:
+      -  HWa entry needs to have its reference to the current IPa
+         address removed.
+      -  HWb needs to have a new reference to IPa added
+      -  IPa needs to be linked to HWb
+
+   3: move IP address to a new interface
+
+      If the InHARP_REQUEST requester's IP source address duplicates a
+      table entry IP address and the InHARP_REQUEST hardware source
+      address does not match the table entry hardware address, then a
+      new HW entry SHALL be created. The requestor's IP address SHALL be
+      moved from the original HW entry to the new one (see above).
+
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 13]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   4: add  IP alias to table
+
+      If the InHARP_REQUEST requester's hardware source address
+      duplicates a hardware source address entry, but there is no IP
+      entry matching the received IP address, then the IP address SHALL
+      be added to the hardware entries previous IP address(es). (E.g.
+      adding an IP alias).
+
+   5: fresh entry, add it
+
+      Standard case, create both entries and link them.
+
+   A server MUST update the HARP table entry's timeout for each
+   HARP_REQUEST. Explanation: if the client is sending HARP requests to
+   the server, then the server SHOULD note that the client is still
+   "alive" by updating the timeout on the client's HARP table entry.
+
+   A HARP server SHOULD use the PIBES (see section 7) to send out
+   HARP_REPLYs to all hardware addresses in its table when the HARP
+   server table changes mappings. This feature decreases the time of
+   stale entries in the clients.
+
+   If there are multiple addresses in the HRAL, then a server needs to
+   act as a client to the other servers.
+
+5.5 HARP and Permanent ARP Table Entries
+
+   An IP station MUST have a mechanism (e.g. manual configuration) for
+   determining what permanent entries it has. The details of the
+   mechanism are beyond the scope of this memo.  The permanent entries
+   allow interoperability with legacy HIPPI adapters which do not yet
+   implement dynamic HARP and use a table-based static ARP. Permanent
+   entries are not aged.
+
+   The HARP server SHOULD use the static entries to resolve incoming
+   HARP_REQUESTs from the clients. This feature eliminates the need for
+   maintaining a static HARP table on the client ports.
+
+5.6 HARP Table Aging
+
+   HARP table aging MUST be supported since IP addresses, especially IP
+   aliases and also interfaces (with their ULA), are likely to move.
+   When so doing the mapping in the clients own HARP table/cache becomes
+   invalid and stale.
+
+   o  When a client's HARP table entry ages beyond 15 minutes, a HARP
+      client MUST invalidate the table entry.
+
+
+
+
+Pittet                      Standards Track                    [Page 14]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   o  When a server's HARP table entry ages beyond 20 minutes, the HARP
+      server MUST delete the table entry.
+
+   NOTE: the client SHOULD revalidate a HARP table entry before it ages,
+   thus restarting the aging time when the table entry is successfully
+   revalidated.  The client MAY continue sending traffic to the port
+   referred to by this entry while revalidation is in progress, as long
+   as the table entry has not aged. The client MUST revalidate an aged
+   entry prior to transmitting any non-address-resolution traffic to the
+   port referred to by this entry.
+
+   The client revalidates the entry by querying the HARP server with a
+   HARP_REQUEST.  If a valid reply is received (e.g. HARP_REPLY), the
+   entry is updated.  If the address resolution service cannot resolve
+   the entry (e.g. HARP_NAK, "host not found"), the associated table
+   entry is removed.  If the address resolution service is not available
+   (i.e. "server failure") the client MUST attempt to revalidate the
+   entry by transmitting an InHARP_REQUEST to the hardware address of
+   the entry in question and updating the  entry on receipt of an
+   InHARP_REPLY. If the InHARP_REQUEST attempt fails to return an
+   InHARP_REPLY, the associated table entry is removed.
+
+6. HARP Message Encoding
+
+   The HARP Message is encapsulated over HIPPI-FP and HIPPI-LE headers.
+   The HARP FP header values are to be set as defined in RFC-2067 "IP
+   over HIPPI" [15]. The following sections detail the HIPPI-LE field
+   contents and HARP message structure and contents. In a broadcast
+   capable network the client MAY also support Type 1 and 6, Ethernet
+   and IEEE 802 ARP packet formats.
+
+6.1 HIPPI-LE Header of HARP Messages
+
+   The HIPPI message format for Internet datagrams shall conform to the
+   HIPPI-FP [2] and HIPPI-LE [3] standards.  The length of a HIPPI
+   message, including trailing fill, shall be a multiple of eight bytes
+   as required by HIPPI-LE.  The HIPPI-LE header fields of HARP and
+   InHARP requests and replies SHALL be:
+
+   FC (3 bits) SHALL contain zero.
+
+   Double-wide SHOULD be set according to HIPPI-LE [3]. This memo does
+   NOT address the implications on HARP when this bit is set to 1
+   indicating the possibility of a port being able to accept 64-bit
+   HIPPI connections.
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 15]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   Message_Type SHALL contain 0 to indicate a data message. HARP
+   messages are identified using the Ethertype and the message type in
+   the ar$op field of the HARP message.
+
+   Destination_Switch_Address, SHALL be the Switch Address of the
+   destination port.
+
+   Destination_IEEE_Address SHALL be the ULA of the destination port, if
+   known, otherwise zero.
+
+   Destination_Address_Type SHALL be 2, a 12-bit logical address.  The
+   behavior with type = 1, source routing, is NOT defined in this
+   specification.
+
+   Source_Switch_Address in requests SHALL be the sender's Switch
+   Address.
+
+   Source_IEEE_Address SHALL be the sender's ULA if known, otherwise
+   zero.
+
+   Source_Address_Type SHALL be 2, a 12-bit logical address. The
+   behavior with type = 1, source routing, is NOT defined in this
+   specification.
+
+6.1.1 IEEE 802.2 LLC
+
+   The IEEE 802.2 LLC Header SHALL begin in the first byte of the
+   HIPPI-FP D2_Area.
+
+   The LLC value for SSAP-DSAP-CTL SHALL be 0xAA-AA-03 (3 bytes)
+   indicating the presence of a SNAP header.
+
+6.1.2 SNAP
+
+   The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes)
+   indicating that the following two-bytes is an Ethertype.
+
+   The Ethertype value SHALL be set as defined in Assigned Numbers [16]:
+   InHARP = InARP = HARP = ARP = 2054 = 0x0806.
+
+   The total size of the LLC/SNAP header is fixed at 8-bytes.
+
+
+
+
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 16]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+6.1.3 HIPPI-LE header Diagram
+
+                   HIPPI-LE header for HARP/InHARP PDUs:
+
+      31    28        23  21          15        10     7         2   0
+      +-----+---------+-+-+-----------+---------+-----+---------+-----+
+    0 | 04 = IP ULP   |1|0|         000         |      03       |  0  |
+      +---------------+-+-+---------------------+---------------+-----+
+    1 |                            n + 8                              |
+      +-----+-+-------+-----------------------+-----------------------+
+    2 |[LA] |W|M_Type |          000          |  Dest. Switch Addr    |
+      +-----+-+-------+-----------------------+-----------------------+
+    3 | D_A_T | S_A_T |          000          | Source Switch Addr    |
+      +-------+-------+---------------+-------+-----------------------+
+    4 |             00 00             |                               |
+      +-------------------------------+                               |
+    5 |                         Destination ULA                       |
+      +-------------------------------+-------------------------------+
+    6 |             [LA]              |                               |
+      +-------------------------------+                               |
+    7 |                           Source ULA                          |
+      +===============+===============+===============+===============+
+    8 |       AA      |      AA       |       03      |       00      |
+      +---------------+---------------+---------------+---------------+
+    9 |       00      |      00       |        Ethertype (2054)       |
+      +---------------+---------------+-------------------------------+
+   10 |Message byte 0 |Message byte 1 |Message byte 2 | . . .         |
+      +---------------+---------------+---------------+---            |
+      |                            .  .  .                            |
+      +   ------------+---------------+---------------+---------------+
+      |         . . . |   byte (n-2)  |   byte (n-1)  |     FILL      |
+      +---------------+---------------+---------------+---------------+
+   N-1|      FILL     |     FILL      |     FILL      |     FILL      |
+      +---------------+---------------+---------------+---------------+
+                            HIPPI Message Format
+
+      Words 0-1:  HIPPI-FP Header
+      Words 2-7:  D1_Area (HIPPI-LE Header)
+      Words 8-9:  D2_Area (IEEE 802.2 LLC/SNAP)
+      Words 10-(N-1):  D2_Area           (HARP message)
+      (n+8) is the nb of bytes in the  HARP message, incl. LLC/SNAP.
+      +====+ denotes the boundary between D1_Area and D2_Area.
+      [LA] fields are zero unless used otherwise locally.
+      Abbreviations:
+       "W"      = Double_Wide field        SHALL be 0
+       "M_Type" = Message_Type field       SHALL be set according to
+                                                    HIPPI-LE
+       "D_A_T"  = Destination_Address_Type SHALL be 2
+
+
+
+Pittet                      Standards Track                    [Page 17]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+       "S_A_T"  = Source_Address_Type      SHALL be 2
+      [FILL] bytes complete the HIPPI message to an even
+      number of 32 bit words.  The number of fill bytes
+      is not counted in the data length.
+
+6.2 HIPPI Hardware Address Formats and Requirements
+
+   For HIPPI-800, the Hardware Address is a 10-byte unit that SHALL
+   contain the Switch Address AND the ULA. The format of a hardware
+   address is:
+
+   31              23              15               7              0
+   +---------------+---------------+-------+-------+---------------+
+   |   Mode Byte   |      00       |   0   |  X    |      XX       |
+   +---------------+---------------+-------+-------+---------------+
+   |   ULA byte 0  |   ULA byte 1  |   ULA byte 2  |   ULA byte 3  |
+   +---------------+---------------+---------------+---------------+
+   |   ULA byte 4  |   ULA byte 5  |
+   +---------------+---------------+
+
+   Where "XXX" is the 12 bit HIPPI logical address defined in HIPPI-SC
+   [4]. Details on ULA see next section.
+
+   Two switch addresses are considered to be the same when they have the
+   same 12 bit destination HIPPI logical address.
+
+   NOTE: In the case of HIPPI-6400, the hardware address is ONLY the 6-
+   byte ULA. Therefore the length of the hardware address clearly
+   defines which version of HIPPI is being used.
+
+6.2.1 48-bit Universal LAN MAC Addresses
+
+   IEEE Standard 802.1A [11] specifies the Universal LAN MAC Address
+   format. The globally unique part of the 48-bit space is administered
+   by the IEEE.  Each port on a HIPPI-SC LAN SHOULD be assigned a ULA.
+   Multiple ULAs may be used if a port contains more than one IEEE 802.2
+   LLC protocol entity.
+
+   The format of the HIPPI hardware address within its HARP message
+   follows IEEE 802.1A canonical bit order and HIPPI-FP bit and byte
+   order. For example the requester's ULA part of the HIPPI hardware
+   address would decompose to:
+
+
+
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 18]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   31              23              15               7              0
+   +---------------+---------------+---------------+---------------+
+   |ULA byte 0 |L|G|   ULA byte 1  |   ULA byte 2  |   ULA byte 3  |
+   +---------------+---------------+---------------+---------------+
+   |   ULA byte 4  |   ULA byte 5  |
+   +---------------+---------------+
+
+                     Universal LAN MAC Address Format
+
+      L (U/L bit) = 1 for Locally administered addresses,
+                    0 for Universal.
+      G (I/G bit) = 1 for Group addresses,
+                    0 for Individual.
+
+   The use of ULAs is OPTIONAL, but RECOMMENDED. The use of ULAs is
+   REQUIRED if a port wishes to interoperate with a conventional
+   network.
+
+   ULAs may also be used by bridging devices that replace HIPPI hardware
+   headers with the MAC headers of other LANs.
+
+6.3 HARP and InHARP Message Formats
+
+   The HARP protocols use the HIPARP hardware type (ar$hrd) [16],
+   protocol type (ar$pro), and operation code (ar$op) data formats as
+   the ARP, and InARP protocols [15,7]. In addition, HARP makes use of
+   an additional operation code for ARP_NAK introduced with [12]. The
+   remainder of the HARP/InHARP message format is different than the
+   ARP/InARP message format defined in [15,7,10] and it is also
+   different from the format defined in the first "IP and ARP on HIPPI"
+   RFC-1374 [14].
+
+   HARP messages SHALL be transmitted with the HIPARP hardware type code
+   of 28 (decimal). Furthermore, HARP messages SHALL  be accepted if
+   received with hardware type codes of either 28, 1 or 6 (decimal).
+
+   The HARP message has several fields that have the following format
+   and values:
+
+   Data sizes and field meaning:
+     ar$hrd  16 bits  Hardware type
+     ar$pro  16 bits  Protocol type of the protocol fields below
+     ar$op   16 bits  Operation code (request, reply, or NAK)
+     ar$pln   8 bits  byte length of each protocol address
+     ar$rhl   8 bits  requester's HIPPI hardware address length (q)
+     ar$thl   8 bits  target's HIPPI hardware address length (x)
+     ar$rpa  32 bits  requester's protocol address
+     ar$tpa  32 bits  target's protocol address
+
+
+
+Pittet                      Standards Track                    [Page 19]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+     ar$rha  qbytes   requester's HIPPI Hardware address
+     ar$tha  xbytes   target's HIPPI Hardware address
+
+   Where :
+     ar$hrd  - SHALL contain 28. (HIPARP)
+
+     ar$pro  - SHALL contain the IP protocol code 2048 (decimal).
+
+     ar$op   - SHALL contain the operational value (decimal):
+               1  for   HARP_REQUESTs
+               2  for   HARP_REPLYs
+               8  for InHARP_REQUESTs
+               9  for InHARP_REPLYs
+               10 for   HARP_NAK
+
+     ar$pln  - SHALL contain 4.
+
+     ar$rln  - SHALL contain 10 IF this is a HIPPI-800 HW address
+               ELSE, for HIPPI-6400, it SHALL contain 6.
+
+     ar$thl  - SHALL contain 10 IF this is a HIPPI-800 HW address
+               ELSE, for HIPPI-6400, it SHALL contain 6.
+
+     ar$rha  - in requests and NAKs it SHALL contain the requester's
+               HW address. In replies it SHALL contain the target
+               port's HW address.
+
+     ar$rpa  - in requests and NAKs it SHALL contain the requester's IP
+               address if known, otherwise zero.
+               In other replies it SHALL contain the target
+               port's IP address.
+
+     ar$tha  - in requests and NAKs it SHALL contain the target's
+               HW address if known, otherwise zero.
+               In other replies it SHALL contain the requester's
+               HW addressA.
+
+     ar$tpa  - in requests and NAKs it SHALL contain the
+               target's IP address if known, otherwise zero.
+               In other replies it SHALL contain the requester's
+               IP address.
+
+   The format of the six bytes of the ULA SHALL be the same as required
+   in the HIPPI-LE header (see section 6.2), except for the alignment of
+   the ULAs with respect to the 32-bit HIPPI word, which is different
+   between ARP and HIPPI-LE.  No bit reversal is necessary as is
+   required with FDDI.
+
+
+
+
+Pittet                      Standards Track                    [Page 20]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+      31    28        23  21          15        10     7         2   0
+      +-----+---------+-+-+-----------+---------+-----+---------+-----+
+    0 |      04       |1|0|         000         |      03       |  0  |
+      +---------------+-+-+---------------------+---------------+-----+
+    1 |                              45                               |
+      +-----+-+-------+-----------------------+-----------------------+
+    2 |[LA] |W|MsgT= 0|          000          |   Dest. Switch Addr   |
+      +-----+-+-------+-----------------------+-----------------------+
+    3 |   2   |   2   |          000          |  Source Switch Addr   |
+      +---------------+---------------+-------+-----------------------+
+    4 |             00 00             |                               |
+      +-------------------------------+                               |
+    5 |                      Destination ULA                          |
+      +-------------------------------+-------------------------------+
+    6 |             [LA]              |                               |
+      +-------------------------------+                               |
+    7 |                         Source ULA                            |
+      +===============+===============+===============+===============+
+    8 |       AA      |      AA       |       03      |       00      |
+      +---------------+---------------+---------------+---------------+
+    9 |       00      |      00       |        Ethertype (2054)       |
+      +---------------+---------------+-------------------------------+
+   10 |              hrd (28)         |           pro (2048)          |
+      +---------------+---------------+---------------+---------------+
+   11 |             op (ar$op)        |     pln (6)   |   rhl (q)     |
+      +---------------+---------------+---------------+---------------+
+   12 |    thl = (x)  |   Requester IP Address upper  (24 bits)       |
+      +---------------------------------------------------------------+
+   13 | Req. IP lower |      Target IP Address upper  (24 bits)       |
+      +---------------+-----------------------------------------------+
+   14 | Tgt. IP lower | Requester HIPPI Hardware Address bytes 0 - 2  |
+      +---------------+-----------------------------------------------+
+   15 |         Requester HIPPI Hardware Address bytes 3 - 6          |
+      +-----------------------------------------------+---------------+
+   16 |         Requester HW Address bytes 7 - q      | Tgt HW byte 0 |
+      +---------------+---------------+---------------+---------------+
+   17 |          Target  HIPPI Hardware Address bytes 1 - 4           |
+      +---------------------------------------------------------------+
+   18 |          Target  HIPPI Hardware Address bytes 5 - 8           |
+      +---------------+---------------+---------------+---------------+
+   19 |Tgt HW byte 9-x|     FILL      |     FILL      |     FILL      |
+      +---------------+---------------+---------------+---------------+
+                           HARP - InHARP Message
+
+
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 21]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+6.3.1 Example Message encodings:
+
+   HARP_REQUEST message
+         HARP ar$op   = 1 (HARP_REQUEST)
+         HARP ar$rpa  = IPy                HARP ar$tpa  = IPa
+         HARP ar$rha  = SWy ULAy           HARP ar$tha  = 0 **
+         ** is what we would like to find out
+
+   HARP_REPLY message format
+         HARP ar$op   = 2 (HARP_REPLY)
+         HARP ar$rpa  = IPa                HARP ar$tpa  = IPy
+         HARP ar$rha  = SWa ULAa *         HARP ar$tha  = SWy ULAy
+         * answer we were looking for
+
+   InHARP_REQUEST message format
+         HARP ar$op    = 8 (InHARP_REQUEST)
+         HARP ar$rpa   = IPy               HARP ar$tpa   = 0 **
+         HARP ar$rha   = SWy ULAy          HARP ar$tha   = SWa ULAa
+         ** is what we would like to find out
+
+   InHARP_REPLY message format
+         HARP ar$op    = 9 (InHARP_REPLY)
+         HARP ar$rpa   = IPs *             HARP ar$tpa   = IPy
+         HARP ar$rha   = SWa ULAa          HARP ar$tha   = SWy ULAy
+         * answer we were looking for
+
+6.3.2 HARP_NAK message format
+
+   The HARP_NAK message format is the same as the received HARP_REQUEST
+   message format with the operation code set to HARP_NAK; i.e. the
+   HARP_REQUEST message data is copied byte for byte for transmission
+   with the HARP_REQUEST operation code changed to the HARP_NAK value.
+   HARP makes use of an additional operation code for HARP_NAK. Hence,
+   HARP_NAK MUST be implemented.
+
+6.3.3 Combined HIPPI-LE and HARP message addresses
+
+   The combined HIPPI-LE/HARP message contains ten addresses, two for
+   the destination and two for the source of the message, three for the
+   requester and three for the target:
+
+      Destination Switch Address  (HIPPI-LE)
+      Destination ULA             (HIPPI_LE)
+
+      Source Switch Address       (HIPPI-LE)
+      Source ULA                  (HIPPI-LE)
+
+
+
+
+
+Pittet                      Standards Track                    [Page 22]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+      Requester IP Address        (HARP)
+      Requester ULA               (HARP)
+      Requester Switch Address    (HARP)
+
+      Target IP Address           (HARP)
+      Target ULA                  (HARP)
+      Target Switch Address       (HARP)
+
+   Examples:
+
+   The following relations are true for a HARP_REQUEST and
+   InHARP_REQUESTs.
+
+      LIS without broadcast -  Dest SW Addr   = HARP server SW Addr
+      (with HARP server)       Dest ULA       = HARP server ULA
+                               Source SW Addr = Requester's SW Addr
+                               Source ULA     = Requester's ULA
+
+7  Broadcast and Multicast
+
+   HIPPI-SC does not require switches to support broadcast. Broadcast
+   support has therefore been absent from many HIPPI networks.
+
+   During its registration phase, every port, including HARP server(s),
+   discover if the underlying medium is capable of broadcast (see
+   section 5.1.2). Should this not be the case, then the HARP server(s)
+   MUST emulate broadcast through an IP broadcast emulation server.
+
+   A HIPPI IP broadcast server (PIBES) is an extension to the HARP
+   server and only makes sense when the LIS does not inherently support
+   broadcast. The PIBES allows common upper layer networking protocols
+   (RIP, TCP, UDP, etc.) to access IP LIS broadcast.
+
+7.1 Protocol for an IP Broadcast Emulation Server - PIBES
+
+   To emulate broadcast within an LIS, a PIBES SHALL use the currently
+   valid HARP table of the HARP server as a list of addresses called the
+   target list. The broadcast server SHALL validate that all incoming
+   messages have a source address which corresponds to an address in the
+   target list. Only messages addressed to the IP LIS broadcast
+   addresses, multicast address or 255.255.255.255 are considered valid
+   messages for broadcasting. Invalid messages MUST be dropped.  All
+   valid incoming messages shall be forwarded to all addresses in the
+   target list.
+
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 23]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   It is RECOMMENDED that the broadcast server run on the same port as
+   the HARP server since this memo does not define the protocol for
+   exchanging the valid HARP table. The default address to use for the
+   broadcast address is the operational HARP server address.
+
+7.2 IP Broadcast Address
+
+   This memo only defines IP broadcast. It is independent of the
+   underlying hardware addressing and broadcast capabilities. Any port
+   can differentiate between IP traffic directed to itself and a
+   broadcast message sent to it by looking at the IP address. All IP
+   broadcast messages SHALL use the IP LIS broadcast address or.
+
+   It is RECOMMENDED that the PIBES run on the same port as the HARP
+   server. In that case, the PIBES SHALL use the same address as the
+   HARP server.
+
+7.3 IP Multicast Address
+
+   HIPPI does not directly support multicast address, therefore there
+   are no mappings available from IP multicast addresses to HIPPI
+   multicast services.  Current IP multicast implementations (i.e. MBONE
+   and IP tunneling, see [9]) will continue to operate over HIPPI-based
+   logical IP subnets if all IP multicast packets are sent using the
+   same algorithm as if the packet were being sent to 255.255.255.255.
+
+7.4 A Note on Broadcast Emulation Performance
+
+   It is obvious that a broadcast emulation service (as defined in
+   section 7.1) has an inherent performance limit. In an LIS with n
+   ports, the upper bound on the bandwidth that such a service can
+   broadcast is:
+                          (total bandwidth)/(n+1)
+
+   since each message must first enter the broadcast server, accounting
+   for the additional 1, and then be sent to all n ports. The broadcast
+   server could forward the message destined to the port on which it
+   runs internally, thus reducing (n+1) to (n) in a first optimization.
+
+   This service is adequate for the standard networking protocols such
+   as RIP, OSPF, NIS, etc. since they usually use a small fraction of
+   the network bandwidth for broadcast. For these purposes, the
+   broadcast emulation server as defined in this memo allows the HIPPI
+   network to look similar to an Ethernet network to the higher layers.
+
+   It is further obvious that such an emulation cannot be used to
+   broadcast high bandwidth traffic. For such a solution, hardware
+   support for true broadcast is required.
+
+
+
+Pittet                      Standards Track                    [Page 24]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+8 HARP for Scheduled Transfer Protocol[17]
+
+   This RFC also applies for resolving addresses used with Scheduled
+   Transfer (STP) over  HIPPI-800 instead of IP. This RFC's message
+   types and algorithms can  be used for STP (since STP uses Internet
+   Addresses) as long as there is also an IP over HIPPI implementation
+   on all of the ports.
+
+9 Discovery of One's Own Switch Address
+
+   This HARP specification assumes that each port has prior knowledge of
+   its own hardware address.  This address may be manually configured,
+   by means outside the scope of this memo or a port may discover its
+   own logical address through the algorithm described below.
+
+   Ports are NOT REQUIRED to implement this switch address discovery
+   protocol but are encouraged to do so since it reduces the
+   administrative overhead.  The algorithm presented in this section is
+   based on John Renwick's work as detailed in RFC-1374 [14]. The
+   concept of the discovery process is to scan all possible switch
+   addresses. The messages that are received will be the ones containing
+   one of our switch addresses.
+
+   If a port implements this algorithm it SHALL form a HIPPI-LE message
+   as defined in HIPPI-LE: containing an Self_Address_Resolution_Request
+   (see [3]) PDU Type, a Source_IEEE_Address and
+   Destination_IEEE_Address (set to the correct ULA for the sender), and
+   the Source_Switch_Address and Destination_Switch_Address.
+
+   This self address resolution message uses the same HIPPI-LE message
+   format as described in HIPPI-SC and HIPPI-LE: the Self Address
+   Resolution Request PDU and Self Address Resolution Response PDU type
+   codes and no piggybacked ULP data.  The HIPPI-LE header contents for
+   the request are:
+
+      HIPPI-LE Message_Type is            = 3, Self Addr. Resolution Request
+      HIPPI-LE Destination_Address_Type   = 0 (undefined)
+      HIPPI-LE Destination_Switch_Address = X (X element scan range)
+      HIPPI-LE Source_Address_Type        = 0 (undefined)
+      HIPPI-LE Source_Switch_Address      = 0 (unknown)
+      HIPPI-LE Destination_IEEE_Address   = 0
+      HIPPI-LE Source_IEEE_Address        = my ULA
+
+   There is no D2 data; the message contains only the HIPPI-FP header
+   and D1_Area with the HIPPI-LE header.
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 25]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   Ports SHALL start the scan with a configurable logical address
+   (default 0x000) and increment the value for by one for each
+   subsequent try. The port SHALL continue until it sees its own self
+   address resolution request or it has reached the end, which may be
+   another configurable value (default 0xFFF). It is RECOMMENDED that
+   the range of addresses to scan be configurable since some networks
+   have equipment that does not gracefully handle HIPPI-LE messages.
+
+   After a port sends the[se] request[s], two positive outcomes are
+   possible:
+
+   o  the port receives its own request(s), and obtains one of its own
+      Switch Address, or
+
+   o  the port receives an AR_S_Response with the
+      Destination_Switch_Address filled in.
+
+10 Security Considerations
+
+   HARP messages are not authenticated which is a potentially flaw that
+   could allow corrupt information to be introduced into the server
+   system.
+
+   There are other known security issues relating to port impersonation
+   via the address resolution protocols used in the Internet [8].  No
+   special security mechanisms have been added to the address resolution
+   mechanism defined here for use with networks using HARP.
+
+   Not all of the security issues relating to ARP over HIPPI are clearly
+   understood at this time. However, given the security hole ARP allows,
+   other concerns are probably minor.
+
+11 Open Issues
+
+   Synchronization and coordination of multiple HARP servers and
+   multiple broadcast servers are left for further study.
+
+12 HARP Examples
+
+   Assume a HIPPI-SC switch is installed with three connected ports: x,
+   y, and a.  Each port has a unique hardware address that consists of
+   Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and
+   ULAa, respectively). There is a HARP server connected to a switch
+   port that is mapped to the address HWa (SWa, ULAa), this address is
+   the authoritative HIPPI hardware address in the HRAL (HARP Request
+   Address List).
+
+
+
+
+
+Pittet                      Standards Track                    [Page 26]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   The HARP server's table is empty. Ports X and Y each know their own
+   hardware address.  Eventually they want to talk to each other; each
+   knows the other's IP address (from the port database) but neither
+   knows the other's ULA or Switch Address. Both ports X and Y have
+   their interfaces configured DOWN.
+
+   NOTE: The LLC, SNAP, Ethertype, HIPPI-LE Message Type, ar$hrd,
+   ar$pro, ar$pln fields are left out from the examples below since they
+   are constant. Likewise, ar$rhl = ar$thl = 9 are omitted since these
+   are all HIPPI-800 examples.
+
+12.1 Registration Phase of Client Y on Non-broadcast Hardware
+
+   Port Y starts: its HARP table entry state for the server: PENDING
+
+   1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa
+      after starting a table entry for HWa.
+
+      HIPPI-LE Destination_Switch_Address = SWa
+      HIPPI-LE Source_Switch_Address      = SWy
+      HIPPI-LE Destination_IEEE_Address   = ULAa
+      HIPPI-LE Source_IEEE_Address        = ULAy
+      HARP ar$op                          = 8 (InHARP_REQUEST)
+      HARP ar$rpa                         = IPy
+      HARP ar$tpa                         = 0 **
+      HARP ar$rha                         = SWy ULAy
+      HARP ar$tha                         = SWa ULAa
+      ** is what we would like to find out
+
+   2. HARP server receives Y's InHARP_REQUEST, it examines the source
+      addresses and scans its tables for a match. Since this is the
+      first time Y connects to this server there is no entry and one
+      will be created and time stamped with the information from the
+      InHARP_REQUEST. The HARP server will then send a InHARP_REPLY
+      including its IP address.
+
+      HIPPI-LE Destination_Switch_Address = SWy
+      HIPPI-LE Source_Switch_Address      = SWa
+      HIPPI-LE Destination_IEEE_Address   = ULAy
+      HIPPI-LE Source_IEEE_Address        = ULAa
+      HARP ar$op                          = 9 (InHARP_REPLY)
+      HARP ar$rpa                         = IPs *
+      HARP ar$tpa                         = IPy
+      HARP ar$rha                         = SWa ULAa
+      HARP ar$tha                         = SWy ULAy
+      * answer we were looking for
+
+
+
+
+
+Pittet                      Standards Track                    [Page 27]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   3. Port Y examines the incoming InHARP_REPLY, completes its table
+      entry for the HARP server. The client's HARP table entry for the
+      server now passes into the VALID state and is usable for regular
+      HARP traffic. Receiving this reply ensures that the HARP server
+      has properly registered the client.
+
+12.2 Registration Phase of Client Y on Broadcast Capable Hardware
+
+   If there is a broadcast capable network then the authoritative
+   address in the HRAL would be mapped to the broadcast address, HWb =
+   SWb, ULAb (likely 0xFE1 and FF:FF:FF:FF:FF:FF).
+
+   Port Y starts: its HARP table entry state for HWa: PENDING
+
+   1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa,
+      in this example the broadcast address, after starting a table
+      entry.
+
+      HIPPI-LE Destination_Switch_Address = SWb
+      HIPPI-LE Source_Switch_Address      = SWy
+      HIPPI-LE Destination_IEEE_Address   = ULAb
+      HIPPI-LE Source_IEEE_Address        = ULAy
+      HARP ar$op                          = 8 (InHARP_REQUEST)
+      HARP ar$rpa                         = IPy
+      HARP ar$tpa                         = 0 **
+      HARP ar$rha                         = SWy ULAy
+      HARP ar$tha                         = SWb ULAb
+      ** is what we would like to find out
+
+   2. Since the network is a broadcast network, client Y will receive a
+      copy of its InHARP_REQUEST. Client Y examines the source
+      addresses.  Since they are the same as what Y filled in the
+      InHARP_REQUEST, Y can deduce that it is connected to a broadcast
+      medium.  Port Y completes its table entry for HWa. This entry will
+      not timeout since it is considered unlikely for a particular
+      underlying hardware type to change between broadcast and non-
+      broadcast; therefore this mapping will never change.
+
+12.3 Operational Phase (phase II)
+
+   The Operational Phase of the HARP protocol as specified in this memo
+   is the same for both broadcast and non-broadcast capable HIPPI
+   hardware. The authoritative address in the HRAL for this example will
+   be HWa: <SWa, ULAa> and IPs for simplicity reasons.
+
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 28]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+12.3.1  Standard successful HARP_Resolve example
+
+   Assume the same process (steps 1-3 of section 10.1) happened for port
+   X. Then the state of X and Y's tables is: the HARP server table entry
+   is in the VALID state. So lets look at the message traffic when X
+   tries to send a message to Y. Since X doesn't have an entry for Y,
+
+   1. Port X connects to the authoritative address of the HRAL and sends
+      a HARP_REQUEST for Y's hardware address:
+
+      HIPPI-LE Destination_Switch_Address = SWa
+      HIPPI-LE Source_Switch_Address      = SWx
+      HIPPI-LE Destination_IEEE_Address   = ULAa
+      HIPPI-LE Source_IEEE_Address        = ULAx
+      HARP ar$op                          = 1  (HARP_REQUEST)
+      HARP ar$rpa                         = IPx
+      HARP ar$tpa                         = IPy
+      HARP ar$rha                         = SWx ULAx
+      HARP ar$tha                         = 0 **
+      ** is what we would like to find out
+
+   2. The HARP server receives the HARP request and updates its entry
+      for X if necessary. It then generates a HARP_REPLY with Y's
+      hardware address information.
+
+      HIPPI-LE Destination_Switch_Address = SWx
+      HIPPI-LE Source_Switch_Address      = SWa
+      HIPPI-LE Destination_IEEE_Address   = ULAx
+      HIPPI-LE Source_IEEE_Address        = ULAa
+      HARP ar$op                          = 2  (HARP_Reply)
+      HARP ar$rpa                         = IPy
+      HARP ar$tpa                         = IPx
+      HARP ar$rha                         = SWy ULAy *
+      HARP ar$tha                         = SWx ULAx
+      * answer we were looking for
+
+   3. Port X connects to port Y and transmits an IP message with the
+      following information in the HIPPI-LE header:
+
+      HIPPI-LE Destination_Switch_Address = SWy
+      HIPPI-LE Source_Switch_Address      = SWx
+      HIPPI-LE Destination_IEEE_Address   = ULAy
+      HIPPI-LE Source_IEEE_Address        = ULAx
+
+   If there had been a broadcast capable HIPPI network, the target ports
+   would themselves have received the HARP_REQUEST of step 2 above and
+   responded to them in the same way the HARP server did.
+
+
+
+
+Pittet                      Standards Track                    [Page 29]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+12.3.2 Standard non-successful HARP_Resolve example
+
+   Like in 12.3.1, assume that X and Y are fully registered with the
+   HARP server. Then the state of X and Y's HARP server table entry is:
+   VALID. So lets look at the message traffic when X tries to send a
+   message to Q. Further assume that interface Q is NOT configured UP,
+   i.e. it is DOWN.  Since X doesn't have an entry for Q,
+
+   1. Port X connects to the HARP server switch address and sends a
+      HARP_REQUEST for Q's hardware address:
+
+      HIPPI-LE Destination_Switch_Address = SWa
+      HIPPI-LE Source_Switch_Address      = SWx
+      HIPPI-LE Destination_IEEE_Address   = ULAa
+      HIPPI-LE Source_IEEE_Address        = ULAx
+      HARP ar$op                          = 1  (HARP_REQUEST)
+      HARP ar$rpa                         = IPx
+      HARP ar$tpa                         = IPq
+      HARP ar$rha                         = SWx ULAx
+      HARP ar$tha                         = 0 **
+      ** is what we would like to find out
+
+   2. The HARP server receives the HARP request and updates its entry
+      for X if necessary. It then looks up IPq in its tables and doesn't
+      find it. The HARP server then generates a HARP_NAK reply message.
+
+      HIPPI-LE Destination_Switch_Address = SWx
+      HIPPI-LE Source_Switch_Address      = SWa
+      HIPPI-LE Destination_IEEE_Address   = ULAx
+      HIPPI-LE Source_IEEE_Address        = ULAa
+      HARP ar$op                          = 10  (HARP_NAK)
+      HARP ar$rpa                         = IPx
+      HARP ar$tpa                         = IPq
+      HARP ar$rha                         = SWx ULAx
+      HARP ar$tha                         = 0 ***
+      *** No Answer, and notice that the fields do not get swapped,
+          i.e. the HARP message is the same as the HARP_REQUEST
+          except for the operation code.
+
+   If there had been a broadcast capable HIPPI network, then there would
+   not have been a reply.
+
+
+
+
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 30]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+13 References
+
+   [1]  ANSI X3.183-1991(R1996), Information Technology - High-
+        Performance Parallel Interface - Mechanical, Electrical and
+        Signaling Protocol Specification; (HIPPI-PH).
+
+   [2]  ANSI X3.210-1998, Information Technology - High-Performance
+        Parallel Interface - Framing Protocol; (HIPPI-FP).
+
+   [3]  ANSI X3.218-1993, Information Technology - High-Performance
+        Parallel Interface - Encapsulation of ISO 8802-2  (IEEE Std
+        802.2) Logical Link Control Protocol Data Units; (HIPPI-LE).
+
+   [4]  ANSI X3.222-1997, Information Technology - High-Performance
+        Parallel Interface - Physical Switch Control; (HIPPI-SC).
+
+   [5]  ANSI X3.300-1997, Information Technology - High-Performance
+        Parallel Interface -  Serial Specification;  (HIPPI-Serial).
+
+   [6]  Braden, R., "Requirements for Internet Hosts -- Communication
+        Layers", STD 3, RFC 1122, October 1989.
+
+   [7]  Bradely, T. and C. Brown, "Inverse Address Resolution Protocol",
+        RFC 2390, September 1998.
+
+   [8]  Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
+        Suite", ACM Computer Communications Review, Vol. 19, Issue 2,
+        pp. 32-48, 1989.
+
+   [9]  Deering, S, "Host Extensions for IP Multicasting", STD 5, RFC
+        1112, August 1989.
+
+   [10] Finlayson, R., Mann, T., Mogul, J. and M. Theimer, "A Reverse
+        Address Resolution Protocol", RFC 903, June 1984.
+
+   [11] ANSI/IEEE Std. 802.2-1989, Information Processing Systems -
+        Local Area Networks - Logical Link Control, "IEEE Standards for
+        Local Area Networks: Logical Link  Control", IEEE, New York, New
+        York, 1985.
+
+   [12] Laubach, Mark., "Classical IP and ARP over ATM", RFC 2225, April
+        1998.
+
+   [13] Plummer, D., "An Ethernet Address Resolution Protocol - or -
+        Converting Network Addresses to 48-bit Ethernet Address for
+        Transmission on Ethernet Hardware", RFC 826, November 1982.
+
+
+
+
+
+Pittet                      Standards Track                    [Page 31]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   [14] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC 1374,
+        October 1992.
+
+   [15] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
+
+   [16] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+        October 1994.
+
+   [17] ANSI NCITS xxx.199x, Project 1245-D, Scheduled Transfer Protocol
+        ANSI NCITS, Scheduled Transfer Protocol draft standard.
+
+   [18] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+14 Acknowledgments
+
+   This memo could not have come into being without the critical review
+   from Greg Chesson, Carlin Otto, the high performance interconnect
+   group of Silicon Graphics (specifically Jim Pinkerton, Brad Strand
+   and Jeff Young) and the expertise of the ANSI T11.1 Task Group
+   responsible for the HIPPI standards work.
+
+   This memo is based on the second part of [14], written by John
+   Renwick. ARP [13] written by Dave Plummer and Inverse ARP [7] written
+   by T. Bradley and C. Brown provide the fundamental algorithms of HARP
+   as presented in this memo. Further, the HARP server is based on
+   concepts and models presented in [12], written by Mark Laubach who
+   laid the structural groundwork for the HARP server.
+
+15 Changes from RFC-1374 [14]
+
+   RFC-2067 obsoletes RFC-1374 but left ARP outside of its scope because
+   there was not enough implementation experience. This memo is an
+   effort to clarify and expand the definition of ARP over HIPPI as
+   found in RFC-1374 such that implementations will be more readily
+   possible, especially considering forward interoperability with
+   HIPPI-6400.
+
+   The changes from RFC-1374 [14] are:
+
+   o  A new message format to acknowledge the HIPPI hardware address
+      format and to eliminate the requirement of HIPPI-LE ARP for HARP
+      to function.
+
+   o  Explicit registration phase.
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 32]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+   o  Additional message formats: InHARP requests and replies as well as
+      HARP_NAKs.
+
+   o  Details about the IP subnetwork configuration.
+
+   o  Details about table aging.
+
+   o  IP broadcast emulation.
+
+16 Author's Address
+
+   Jean-Michel Pittet
+   Silicon Graphics Inc
+   1600 Amphitheatre Parkway
+   Mountain View, CA 94043
+
+   Phone: 650-933-6149
+   Fax:   650-933-3542
+   EMail: jmp@sgi.com, jmp@acm.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 33]
+
+RFC 2834          ARP and IP Broadcast over HIPPI-800           May 2000
+
+
+17 Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pittet                      Standards Track                    [Page 34]
+