📄 rfc2835.txt
字号:
RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000 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 sect. 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. 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 the invalidated entry prior to transmitting any non-address resolution traffic to the port referred to by this entry.Pittet Standards Track [Page 18]RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000 The client revalidates the entry by querying the HARP server. 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 another type of IEEE 802 payload as described in section 4.1.3 above. The HIPPI-6400 HARP SHALL support two packet formats, both the generic Ethernet ARP packet and the HIPPI-800 HARP packet format defined in [13]. HARP messages SHALL be transmitted with a hardware type code of 28 on non-broadcast capable hardware or 1 in either case. The ar$hrd field SHALL be used to differentiate between the two packet formats. The reply SHALL be in the format of the request.6.1 Generic IEEE 802 ARP Message Format This is the ARP packet format used by conventional IEEE 802 networks (i.e. Ethernet, etc). The packet format is described in RFC-826 [14] and is given here only for completeness purpose. ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type of the protocol fields below ar$hln 8 bits byte length of each hardware address ar$pln 8 bits byte length of each protocol address ar$op 16 bits opcode (ares_op$REQUEST | ares_op$REPLY) ar$sha 48 bits Hardware address of sender of this packet ar$spa 32 bits Protocol address of sender of this packet ar$tha 48 bits Hardware address of target of this ar$tpa 32 bits Protocol address of target. Where: ar$hrd - SHALL contain 1. (Ethernet) ar$pro - SHALL contain the IP protocol code 2048 (decimal). ar$hln - SHALL contain 6. ar$pln - SHALL contain 4.Pittet Standards Track [Page 19]RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000 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$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$sha - in requests and NAKs it SHALL contain the requester's ULA In replies it SHALL contain the target port's ULA. ar$spa - 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 ULA if known, otherwise zero. In other replies it SHALL contain the requester's ULA. 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.Pittet Standards Track [Page 20]RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000 |31 |23 |15 |7 0| +---------------+---------------+---------------+---------------+----- 0 | | | D_ULA +-------------------------------+HIPPI 1 | | |6400 +-------------------------------+ S_ULA |MAC 2 | |hdr +---------------------------------------------------------------+ 3 | M_len | +---------------+---------------+---------------+---------------+----- 4 | AA | AA | 03 | 00 |IEEE +---------------+---------------+---------------+---------------+802 5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC/ +------------+------------------+-------------------------------+SNAP 6 | hrd (1) | pro (2048) | +---------------+---------------+---------------+---------------+ 7 | hln (6) | phl (4) | op (ar$op) | +<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+ 8 | Source Hardware Address 0 - 3 | +-------------------------------+-------------------------------+ 9 | Source ULA bytes 4 - 5 | Source IP Address bytes 0 - 1 | +-------------------------------+-------------------------------+10 | Source IP Address bytes 2 - 3 | Target ULA bytes 0 - 1 | +-------------------------------+-------------------------------+11 | Target Hardware Address (ULA) bytes 2 - 5 | +---------------------------------------------------------------+12 | Target IP Address | +---------------+---------------+---------------+---------------+13 | FILL | FILL | FILL | FILL | +---------------+---------------+---------------+---------------+14 | FILL | FILL | FILL | FILL | +><><><><><><><>+<><><><><><><><+><><><><><><><>+<><><><><><><><+6.2 HIPARP Message Formats The HARP protocols further SHALL support the HIPARP hardware type (ar$hrd) = 28 (dec) [18], protocol type (ar$pro), and operation code (ar$op) data formats as the ARP, and InARP protocols [14,7]. In addition, HARP makes use of an additional operation code for ARP_NAK introduced with [11]. The remainder of the HIPARP message format (defined in [13]) is different than the ARP/InARP message format defined in [14,7,10] and it is also different from the format defined in the first "IP and ARP on HIPPI" RFC-1374 [16]. The HARP message has several fields that have the following format and values:Pittet Standards Track [Page 21]RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000 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 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 address.Pittet Standards Track [Page 22]RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000 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. Payload Format for HARP/InHARP PDUs: |31 |23 |15 |7 0| +---------------+---------------+---------------+---------------+----- 0 | | | D_ULA +-------------------------------+HIPPI 1 | | |6400 +-------------------------------+ S_ULA |MAC 2 | |hdr +---------------------------------------------------------------+ 3 | M_len | +---------------+---------------+---------------+---------------+----- 4 | AA | AA | 03 | 00 |IEEE +---------------+---------------+---------------+---------------+802 5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC/ +------------+------------------+-------------------------------+SNAP 6 | hrd (28) | pro (2048) | +---------------+---------------+---------------+---------------+ 7 | op (ar$op) | pln (6) | shl (q) | +<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+ 8 | thl (x) | Source IP Address upper (24 bits) | +---------------------------------------------------------------+ 9 | Src. IP lower | Target IP Address upper (24 bits) | +---------------+-----------------------------------------------+10 | Tgt. IP lower | Source HW Address bytes 0 - 2 | +---------------+-------------------------------+---------------+11 | Source HW Address bytes 3 - q | Tgt HW byte 0 | +-----------------------------------------------+---------------+12 | Target Hardware Address bytes 1 - 4 |
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -