Network Working Group INTERNET DRAFT BigTen (BT) Packet Format Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 1. Introduction The BigTen (BT) is a new version of the Internet Protocol, designed as a successor to IP version 4 (IPv4) [RFC791]. This document specifies the basic BT header format and the initially defined BT options. 2. Acknowledgements This document attempts to borrow the best from all of the existing IPng proposals (CATNIP, SIPP, TUBA). Large portions of this document are taken almost verbatim from the SIPP document. 3. Terminology node - a protocol module that implements BT. Expiration Date December 1994 [Page 1] INTERNET DRAFT November 1994 router - a node that forwards BT packets not explicitly addressed to itself. host - any node that is not a router. address - a BT-layer identifier for a node or set of nodes. subnet - in the BT unicast addressing hierarchy, a lowest-level (finest-grain) aggregation of addresses sharing a common prefix, i.e., high- order address bits. link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below BT. interface - a node's attachment to a link. neighbors - nodes attached to the same link. link MTU - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed in one piece over a link (where a packet is a BT header plus payload). path MTU - the minimum link MTU of all the links in a path between a source node and a destination node. packetization layer - any protocol layer above BT that is responsible for packetizing data to fit within outgoing BT packets. Typically, transport-layer protocols, such as TCP, are packetization protocols, but there may also be higher- layer packetization protocols, such as protocols implemented on top of UDP. 4. BT Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Reser.| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | BOD | Curr Off | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Route (variable length, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (4 bits) -0x6 Expiration Date December 1994 [Page 2] INTERNET DRAFT November 1994 Flag (4 bits) -- -0x8 -- MRE, Must Report Errors -0x4 -- Behavior on Source Route Failure -0x2 -- Flow Present -0x1 -- Source Route Present Reserved (4 bits) Must be sent as zero and ignored on receipt. Total Length (20 bits). The value of this field is the total length (in octets) of a BT packet (including the BT header). Hop Count (8 bits). Field to be decremented by one by each hop. The packet is dropped when Hop Count goes to zero. Current Offset in Source Route (8 bits). Offset from the beginning of the source address to the currently active element of the Source Route, in bytes. Initialized by the source to the length of the source address. The value is checked by each router if the Source Route Present bit is set. May be updated by router. This field is present even if the source route is not present. BOD - Offset to End of Source Route (8 bits). This will commonly point to the end of the destination address and be a pointer to the payload. Set by the source node if the Source Route Present bit is set, routers do not change this value. Routers may look at this field if the Protocol field is set to a value that routers must look at (e.g. hop by hop option). This field is present even if the source route is not present. Protocol (8 bits). The type of Payload carried in this packet, with values as defined IANA. 0x06 == TCP. BT codes "options" and fragmentation as protocols in this field. Flow (32 bits). If the Flag field indicates Flow Present, then the 32 bits carry flow-id. Otherwise, this field is absent. Locators are 64 bit aligned collections of 64 bit chunks. The locator is defined as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Len | LF | 8 + 8 * Len bytes ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S (bit 0) Strict or Loose Indicator, for source routing. A one in this bit indicates that the this locator, if occuring in a source route, must be the next hop. Len (bits 1-3) Length of the entire locator (in multiples of 8 octets). Locator Family (bits 4-7) Assigned by IANA. Expiration Date December 1994 [Page 3] INTERNET DRAFT November 1994 A unicast, a multicast or a cluster address is a locator. A source address is a locator. A source route is a sequence of one or more locators. Multicast addresses may not appear in a Source Route. 5. BT Options In BT, optional internet-layer information is encoded in separate headers that may be placed between the BT header and the transport layer header in a packet. There are a small number of such optional headers, each identified by a distinct Payload value. As illustrated in these examples, a BT packet may carry zero, one, or more optional headers, each identified by the Payload field in the preceding header: +-------------+------------------------ | BT header | TCP header + data | | | Payload = | | TCP | +-------------+------------------------ +---------------------+-------------------+--------------------- | BT header | Hop-by-hop header | TCP header + data | | | | Payload = | Payload = | | Hop-by-hop header | TCP | +---------------------+-------------------+--------------------- +-----------------------+-------------------+------------------+------------ | BT header | Hop-by-hop header |End-to-end header | TCP header | | | | + data | Payload = | Payload = | Payload = | | Hop-by-hop option hdr | End-to-end header | TCP | +-----------------------+-------------------+------------------+------------ With one exception, optional headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or set of nodes, in the case of multicast) identified in the Destination Address field of the BT header. There, normal demultiplexing on the Payload field of the BT header invokes the module to process the first optional header, or the transport header if no optional header is present. The contents and semantics of each header determine whether or not to proceed to the next header. The one exception is the Hop-by-Hop Options header, which carries Expiration Date December 1994 [Page 4] INTERNET DRAFT November 1994 options that must be examined by every node along a packet's delivery path. The Hop-by-Hop options header, when present, must immediately follow the BT header. Its presence is indicated by the special value zero in the Payload field of the BT header. Each optional header is an integer multiple of 8 octets long, in order to retain 8-octet alignment for subsequent headers. Multi- octet fields within each optional header are aligned on their natural boundaries, i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header. 5.1 Hop-by-Hop Options Header The Hop-by-Hop (HBH) Options header is used to carry optional information that must be examined by every node along a packet's delivery path. The HBH Options header is identified by a Payload Type of 0 in the BT header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . Options . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload Type 8-bit selector. Identifies the type of header immediately following the HBH Options header. Uses the same values as the IPv4 Protocol field [RFC-1340]. Hdr Ext Len 8-bit unsigned integer. Length of the HBH Options header in 8-octet units, not including the first 8 octets. Options Variable-length field, an integer multiple of 8 octets long. One or more individual TLV- encoded options, as described below. The individual options within the Options area are each encoded in a Type- Length-Value (TLV) format, as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Option Type 8-bit identifier of the type of option. Expiration Date December 1994 [Page 5] INTERNET DRAFT November 1994 Opt Data Len 8-bit unsigned integer. Length of the Option Data field of this option, in octets. Option Data Variable-length field. Option-Type-specific data. The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken if the processing BT node does not recognize the Option Type: 00 - skip over this option and continue processing the HBH Options header. 01 - discard the packet. 10 - discard the packet and send an ICMP Parameter Problem message to the packet's Source Address, pointing to the unrecognized Option Type. 11 - discard the packet and, only if the packet's Destination Address is not a multicast address, send an ICMP Parameter Problem message to the packet's Source Address, pointing to the unrecognized Option Type. The third-highest-order bit of the Option Type specifies whether or not the Option Data of this option shall be included in the integrity assurance computation performed when an Authentication header is present. Option data that changes en route must be excluded from that computation. 0 - include in integrity computation 1 - exclude from integrity computation The Option Type 31 (0x1f) is reserved for future use. Individual options may have alignment requirements, to ensure that multi- octet values within Option Data fields fall on natural boundaries. The alignment requirement of an option is specified using the notation xn+y, meaning the Option Type must appear at an integer multiple of x octets from the start of the HBH Options header, plus y octets. For example: 2n means any 2-octet offset from the start of the header. 8n+2 means any 8-octet offset from the start of the header, plus 2 octets. Expiration Date December 1994 [Page 6] INTERNET DRAFT November 1994 5.1.1 Padding Options The only hop-by-hop options initially defined are padding options, which are used when necessary to align subsequent options and to pad out the Options area of the header to a multiple of 8 octets in length. These padding options must be recognized by all BT implementations: Pad1 option (alignment requirement: none) +-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+ NOTE! the format of the Pad1 option is a special case -- it does not have length and value fields. The Pad1 option is used to insert one octet of padding into the Options area of an HBH Options header. If more than one octet of padding is required, the PadN option, described next, should be used, rather than multiple Pad1 options. PadN option (alignment requirement: none) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 1 | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - The PadN option is used to insert two or more octets of padding into the Options area of an HBH Options header. For N octets of padding, the Opt Data Len field contains the value N-2, and the Option Data consists of N-2 zero-valued octets. 5.2 End-to-End Options Header The End-to-End Options header is used to carry optional information that must be examined only by the destination host. The End-to-End Options header is identified by a Payload Type of 2 in the BT header. The format of the End-to-End Options header and the encoding of individual options within the Options area are identical to that of the Hop-by-Hop options header, as found in section 5.1. The only End-to-End Options initially defined are fragmentation, authentication, and padding options. Expiration Date December 1994 [Page 7] INTERNET DRAFT November 1994 5.2.1 Padding Option Padding option is used when necessary to align subsequent options and to pad out the Options area of the header to a multiple of 8 octets in length. These padding options must be recognized by all BT implementations. The format of the padding option is identical to the Hop-by-Hop Padding option, found in section 5.1.1. 5.2.2 Fragment Option The Fragment Option is used by a BT source to send payloads larger than would fit in the path MTU to their destinations. (Note: unlike IPv4, fragmentation in BT is performed only by source nodes, not by routers along a packet's delivery path -- see section 5.) The Fragment Option has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 30 | 7 | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Option data has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |M| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 11-bit field. Initialized to zero for transmission; ignored on reception. M flag 1 = more fragments; 0 = last fragment. Fragment Offset 20-bit unsigned integer. The offset, in 8-octet units, of the following payload, relative to the start of the original, unfragmented payload. Identification 32 bits. See description below. The fragmentation algorithm is as follows: The payload (including any optional headers that need be processed only by the destination node(s)) is divided into fragments, each, except possibly the last, being an integer multiple of 8 octets long. Each fragment is prepended with a Fragment Option (carried in the End-to-end Option Header) and sent in a separate BT packet. The M ("more") flag is set to 1 on all fragments of the same payload except the last. The original payload is assigned an Identification value that is different than that of any other fragmented payload sent recently* Expiration Date December 1994 [Page 8] INTERNET DRAFT November 1994 with the same BT Source Address, BT Destination Address, and Fragment Payload Type. The Identification value is carried in the Fragment option of all of the original payload's fragments, and is used by the destination to identify all fragments belonging to the same original payload. * "recently" means within the maximum likely lifetime of a packet, including transit time from source to destination and time spent awaiting reassembly with other fragments of the same payload. However, it is not required that a source node know the maximum packet lifetime. Rather, it is assumed that the requirement can be met by maintaining the Identification value as a simple, 32-bit, "wrap- around" counter, incremented each time a payload must be fragmented. It is an implementation choice whether to maintain a single counter for the node or multiple counters, e.g., one for each of the node's possible source addresses, or one for each active (source address, destination address, payload type) combination. In a packet with a Fragment option, the Payload Length field of the BT header contains the length of that packet only (excluding the BT header itself), not the length of the original, unfragmented payload. 5.2.3 Authentication Option The Authentication option is used to provide authentication and integrity assurance for BT packets. Non-repudiation may be provided by an authentication algorithm used with the Authentication option, but it is not provided with all authentication algorithms that might be used with this header. Privacy of the payload following the Authentication option may optionally be provided by encryption, using an algorithm and keying information that has been pre-established as part of a security association. The Authentication option has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 29 | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Option data has the following format: 0 1 2 3 Expiration Date December 1994 [Page 9] INTERNET DRAFT November 1994 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Authentication Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number 16-bit wrap-around counter. The sequence number of this packet, relative to other packets sent in the same security association. Security Assoc. ID 32 bits. When combined with the BT Source Address, identifies to the receiver(s) the pre-established security association to which this packet belongs. Authentication Data Variable-length field, an integer multiple of 8 octets long. Algorithm-specific information required authenticate the source of the packet and assure its integrity, as specified for the pre-established security association. The usage of the Authentication option is specified in [SIPP_AUTH]. All BT nodes are required to support the keyed MD5 algorithm used with the Authentication option as described in that document. 5.3 Option Header Order When more than one optional header is used in the same packet, they should appear in the following order: BT header Hop-by-Hop Options header End-to-End Option header If and when other optional headers are defined, their ordering constraints relative to the above listed headers must be specified. BT nodes are not required to verify that the order of headers in received packets satifies the above order; sending packets with optional headers in some other order may or may not achieve useful effects. Expiration Date December 1994 [Page 10] INTERNET DRAFT November 1994 6. Packet Size Issues BT requires that every link in the internet have an MTU of 576 octets or greater. On any link that cannot convey a 576-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below BT. (Note: this minimum link MTU is NOT the same as the one in IPv4. In IPv4, the minimum link MTU is 68 octets [RFC-791, page 25]; 576 octets is the minimum reassembly buffer size required in an IPv4 node, which has nothing to do with link MTUs.) A node must be able to accept packets as large as that link's MTU, for each link to which a node is directly attached. Links that have a configurable MTU, such as PPP links [RFC-1548], should be configured with an MTU of 600 octets or greater. BT nodes are expected to implement Path MTU Discovery [RFC-1191], in order to discover and take advantage of paths with MTU greater than 576 octets. However, a minimal BT implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 576 octets, and omit implementation of Path MTU Discovery. In order to send a packet larger than a path's MTU, a node may use the optional BT Fragment Header to fragment the packet at the source and have it reassembled at the destination(s). However, the use of such fragmentation is discouraged in any application that is able to adapt its packets to fit the measured path MTU (i.e., down to 576 octets). A node must not send a packet larger than the path MTU (i.e., fragments that reassemble to a size larger than the path MTU) unless it has explicit knowledge that the destination(s) can reassemble a packet of that size. In response to a BT packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from BT to IPv4), the originating BT node may receive an ICMP Packet Too Big message reporting a Next- Hop MTU less than 576. Note: Since BT allows a subnet to span more than one link, Path MTU Discovery must be performed even between nodes on the same subnet. Note: Unlike IPv4, it is unnecessary in BT to set a "Don't Fragment" flag in the packet header in order to perform Path MTU Discovery; that is an implicit attribute of every BT packet. Also, those parts of the RFC-1191 procedures that involve use of a table of MTU "plateaus" do not apply to BT, because the BT version of the "Datagram Too Big" message always identifies the exact MTU to be used. Expiration Date December 1994 [Page 11] INTERNET DRAFT November 1994 7. Flow Label The Flow Label field in the BT header may be used by a source to label those packets for which it requests special handling by the BT routers, such as non-default quality of service or "real-time" service. This aspect of BT is, at the time of writing, still experimental and subject to change as the requirements for flow support in the Internet become clearer. Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, and to ignore the field when receiving a packet. The Flow Label is a 32-bit field, internally structured into two subfields as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TClass | Flow ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TClass 4-bit traffic class, described below. Flow ID 24-bit flow identifier, described below. A flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening routers. The nature of that special handling might be conveyed to the routers by a control protocol, such as a resource reservation protocol, or by information within the flow's packets themselves, e.g., in a hop-by-hop option. The details of such control protocols or options are beyond the scope of this document. There may be multiple active flows from a source to a destination, as well as traffic that is not associated with any flow. A flow is identified by the combination of a Source Address and a non-zero Flow ID. Packets that do not belong to a flow carry a Flow ID of zero. A Flow ID is assigned to a flow by the flow's source node. New Flow IDs must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFFFF hex. The purpose of the random allocation is to make any set of bits within the Flow ID suitable for use as a hash key by the routers, for looking up the special-handling state associated with the flow. A Flow ID must not be re-used by a source for a new flow while any state associated with the previous usage still exists in any router. The lifetime of flow state in routers depends on the method by which that state is created, and is beyond the scope of this document. All packets sent with the same Source Address and same non-zero Flow ID must also carry the same Destination Address, same Hop-by-Hop Options header contents (if present) and the same End-to-End Options header contents. The routers or destinations are permitted, but not Expiration Date December 1994 [Page 12] INTERNET DRAFT November 1994 required, to verify that this condition is satisfied. If a violation is detected, it should be reported to the source by an ICMP Parameter Problem message, pointing to any one of the invalid fields. The TClass subfield provides a means separate from the Flow ID for a source to identify the desired delivery priority of its packets, relative to other packets from the same source. The TClass values are divided into two ranges: values 0 through 7 are used to label flow-controlled packets, e.g., packets that belong to a TCP connection, and values 8 through 15 are used to label non-flow- controlled packets, e.g., "real-time" packets being sent without any flow-control feedback from the receivers. For flow-controlled traffic, the following TClass values are recommended for particular application categories: 0 - uncharacterized traffic 1 - "filler" traffic (e.g., netnews) 2 - unattended data transfer (e.g., email) 3 - 4 - attended bulk transfer (e.g., FTP, NFS) 5 - 6 - interactive traffic (e.g., telnet, X) 7 - internet control traffic (e.g., routing protocols, SNMP) For non-flow-controlled traffic, the lowest TClass value (8) should be used for those packets that the sender is most willing to have discarded under conditions of congestion (e.g., high-fidelity video traffic), and the highest value (15) should be used for those packets that the sender is least willing to have discarded (e.g., low- fidelity audio traffic). There is no relative ordering implied between the flow-controlled classes and the non-flow-controlled classes. For packets bearing non-zero Flow IDs, the method by which the flow requirements are conveyed (e.g., a control protocol or a hop-by-hop option) may include the ability to redefine the semantics of the TClass subfield, for example, to define it as a priority relative to packets belonging to the same flow or set of related flows. `` Need some text in here about what to do with packets where flow state is `` lost. 8. Transport-Layer Protocol Issues 8.1 Transport-Layer Checksums When TCP, UDP, ICMP, or IGMP (subsequently referred to as "transport" Expiration Date December 1994 [Page 13] INTERNET DRAFT November 1994 protocols) is used between two or more BT systems, the transport checksum computation includes a "pseudo-header" of the following form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type |Reserv.| Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o The Payload Type used in the pseudo-header is that of the transport protocol (6 for TCP, 17 for UDP, 1 for ICMP, or 2 for IGMP). It will differ from the Payload Type in the BT header if there are additional headers between the BT header and the transport header. o The Payload Length used in the pseudo-header is the length of the transport packet, incluing the transport header. It will be less than the Payload Length in the BT header if there are additional headers between the BT header and the transport header. o The UDP checksum is not optional when UDP is used between BT systems. At a recipient, a UDP checksum value of zero is considered valid only if the checksum computation across the the pseudo-header, UDP header, and UDP data yields a result of either zero or hex FFFF (which are equal values in ones-complement arithmetic). 8.2 Maximum Packet Lifetime BT does not enforce maximum packet lifetime. Any transport protocol that relies on IPv4 to limit packet lifetime must take this change into account, for example, by providing its own mechanisms for detecting and discarding obsolete packets. Expiration Date December 1994 [Page 14]