INTERNET-DRAFT S. Deering February 21, 1993 Xerox PARC Obsoletes: draft-deering-sip-00.txt Simple Internet Protocol Plus (SIPP) Specification draft-ietf-sipp-spec-00.txt Abstract This document specifies a proposed new version of the Internet Protocol. Changes from the previous specification (SIP) are listed in Appendix A. Status of this Memo 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. This Internet Draft expires on September 21, 1994. 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 I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this memo is unlimited. Expires: September 21, 1994 [Page 1]
INTERNET DRAFT SIPP Specification February 21, 1994 Contents Status of this Memo 1. Introduction 2. Terminology 3. SIPP Header Format 4. SIPP Options 4.1 Fragment Header 4.2 Routing Header 4.3 Authentication Header 4.4 Hop-by-Hop Options Header 4.5 Option Header Order 5. Packet Size Issues 6. Flow Labels 7. Transport-Layer Protocol Issues 7.1 Transport-Layer Checksums 7.2 Maximum Packet Lifetime Appendix A. Changes from the SIP Draft of November 10, 1992 Security Considerations Acknowledgments Author's Address References Expires: September 21, 1994 [Page 2]
INTERNET DRAFT SIPP Specification February 21, 1994 1. Introduction The Simple Internet Protocol Plus (SIPP) is a new version of the Internet Protocol, designed as a successor to IP version 4 (IPv4) [RFC-791]. The changes from IPv4 to SIPP fall primarily into the following categories: o Expanded Addressing Capabilities SIPP increases the IP address size from 32 bits to 64 bits, to support more levels of addressing hierarchy and a much greater number of addressable nodes. SIPP addressing can be further extended, in units of 64 bits, by a facility equivalent to IPv4's Loose Source and Record Route option, in combination with a new address type called "cluster addresses" which identify topological regions rather than individual nodes. The scalability of multicast routing is improved by adding a "scope" field to multicast addresses. o Header Format Simplification Some IPv4 header fields have been dropped or made optional, to reduce the common-case processing cost of packet handling and to keep the bandwidth cost of the SIPP header almost as low as that of IPv4, despite the increased size of the addresses. o Improved Support for Options Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future. o Flow Labeling Capability A new capability is added to enable the labeling of packets belonging to particular traffic "flows" for which the sender requests special handling, such as non-default quality of service or "real-time" service. This document specifies the basic SIPP header and the initially-defined SIPP options. It also discusses packet size issues, the semantics of Flow Labels, and the effects of SIPP on transport-layer protocols. Other aspects of SIPP are specified in separate documents, including the following: o Simple Internet Protocol Plus (SIPP): Routing and Addressing [SIPP- ROAD] o ICMP and IGMP for SIPP Specification [SIPP-ICMP] o IPAE: The SIPP Interoperability and Transition Mechanism [IPAE] Expires: September 21, 1994 [Page 3]
INTERNET DRAFT SIPP Specification February 21, 1994 2. Terminology node - a protocol module that implements SIPP. router - a node that forwards SIPP packets not explicitly addressed to itself. host - any node that is not a router. address - a SIPP-layer identifier for a node or set of nodes. subnet - in the SIPP 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 SIPP. 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 SIPP 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 SIPP that is responsible for packetizing data to fit within outgoing SIPP 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. Expires: September 21, 1994 [Page 4]
INTERNET DRAFT SIPP Specification February 21, 1994 3. SIPP Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Payload Type | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version 4-bit Internet Protocol version number = 6. Flow Label 28-bit field. See "Flow Labels" section, below. Payload Length 16-bit unsigned integer. Length of payload, i.e., the rest of the packet following the SIPP header, in octets. Payload Type 8-bit selector. Identifies the type of header immediately following the SIPP header. Uses the same values as the IPv4 Protocol field [RFC-1340]. Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. Source Address 64 bits. An address of the initial sender of the packet. See [SIPP-ROAD] for details. Destination Address 64 bits. An address of the intended recipient of the packet (possibly not the ultimate recipient, if an optional Routing Header is present). See section 4.2 and [SIPP-ROAD] for details. 4. SIPP Options In SIPP, optional internet-layer information is encoded in separate headers that may be placed between the SIPP header and the transport- layer header in a packet. There are a small number of such optional headers, each identified by a distinct Payload Type. As illustrated in these examples, a Expires: September 21, 1994 [Page 5]
INTERNET DRAFT SIPP Specification February 21, 1994 SIPP packet may carry zero, one, or more optional headers, each identified by the Payload Type field of the preceding header: +-------------+------------------------ | SIPP header | TCP header + data | | | Pyld Type = | | TCP | +-------------+------------------------ +-------------+----------------+------------------------ | SIPP header | Routing header | TCP header + data | | | | Pyld Type = | Payload Type = | | Routing | TCP | +-------------+----------------+------------------------ +-------------+----------------+-----------------+----------------- | SIPP header | Routing header | Fragment header | fragment of TCP | | | | header + data | Pyld Type = | Payload Type = | Payload Type = | | Routing | Fragment | 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 SIPP header. There, normal demultiplexing on the Payload Type field of the SIPP 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 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 SIPP header. Its presence is indicated by the special value zero in the Payload Type field of the SIPP 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. 4.1 Routing Header The Routing header is used by a SIPP source to list one or more Expires: September 21, 1994 [Page 6]
INTERNET DRAFT SIPP Specification February 21, 1994 intermediate nodes (or topological clusters) to be "visited" on the way to a packet's destination. This function is very similar to IPv4's Loose Source and Record Route option. The Routing header is identified by a Payload Type of 43 in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type | Num Addrs | Next Addr | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Address[0] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Address[1] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Address[Num Addrs - 1] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload Type 8-bit selector. Identifies the type of header immediately following the Routing header. Uses the same values as the IPv4 Protocol field [RFC-1340]. Num Addrs 8-bit unsigned integer. Number of addresses in the Routing header. Next Addr 8-bit unsigned integer. Index of next address to be processed; initialized to 0 by the originating node. Reserved 40-bit field. Initialized to zero for transmission; ignored on reception. A Routing header is not examined or processed until it reaches the node identified in the Destination Address field of the SIPP header. In that node, dispatching on the Payload Type of the immediately preceding header causes the Routing module to be invoked, which performs the following algorithm: o If Next Addr < Num Addrs, swap the SIPP Destination Address and Address[Next Addr], increment Next Addr by one, and re-submit the Expires: September 21, 1994 [Page 7]
INTERNET DRAFT SIPP Specification February 21, 1994 packet to the SIPP module for forwarding to the next destination. o If Next Addr = Num Addrs, dispatch to the local protocol module identified by the Payload Type field in the Routing header. o If Next Addr > Num Addrs, send an ICMP Parameter Problem message to the Source Address, pointing to the Num Addrs field. Multicast addresses may not appear in a Routing header. 4.2 Fragment Header The Fragment header is used by a SIPP source to send payloads larger than would fit in the path MTU to their destinations. (Note: unlike IPv4, fragmentation in SIPP is performed only by source nodes, not by routers along a packet's delivery path -- see section 5.) The Fragment header is identified by a Payload Type of 44 in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type | Reserved |M| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload Type 8-bit selector. Identifies the type of header immediately following the Fragment header. Uses the same values as the IPv4 Protocol field [RFC-1340]. Reserved 10-bit field. Initialized to zero for transmission; ignored on reception. M flag 1 = more fragments; 0 = last fragment. Fragment Offset 13-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 header and sent in a separate SIPP 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* with the same SIPP Source Address, SIPP Destination Address, and Fragment Payload Type. (If an optional Expires: September 21, 1994 [Page 8]
INTERNET DRAFT SIPP Specification February 21, 1994 Routing header is present, the SIPP Destination Address is that of the final destination.) The Identification value is carried in the Fragment header 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 header, the Payload Length field of the SIPP header contains the length of that packet only (excluding the SIPP header itself), not the length of the original, unfragmented payload. 4.3 Authentication Header The Authentication header is used to provide authentication and integrity assurance for SIPP packets. Non-repudiation may be provided by an authentication algorithm used with the Authentication header, but it is not provided with all authentication algorithms that might be used with this header. Privacy of the payload following the Authentication header 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 header is identified by a Payload Type of TBD in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type | Auth Data Len | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Authentication Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Payload Type 8-bit selector. Identifies the type of header immediately following the Authentication header. Uses the same values as the IPv4 Protocol field [RFC-1340]. Expires: September 21, 1994 [Page 9]
INTERNET DRAFT SIPP Specification February 21, 1994 Auth Data Len 8-bit unsigned integer. Length of the Authentication Data field in 8-octet units. 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 SIPP 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 header is specified in [SIPP_AUTH]. All SIPP nodes are required to support the keyed MD5 algorithm used used with the Authentication header as described in that document. 4.4 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 SIPP 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- Expires: September 21, 1994 [Page 10]
INTERNET DRAFT SIPP Specification February 21, 1994 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. 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 SIPP 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 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. Expires: September 21, 1994 [Page 11]
INTERNET DRAFT SIPP Specification February 21, 1994 8n+2 means any 8-octet offset from the start of the header, plus 2 octets. 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 SIPP 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. 4.5 Option Header Order When more than one optional header is used in the same packet, they should appear in the following order: SIPP header Hop-by-Hop Options header Routing header Fragment header Authentication header If and when other optional headers are defined, their ordering constraints relative to the above listed headers must be specified. SIPP nodes are not required to verify that the order of headers in received Expires: September 21, 1994 [Page 12]
INTERNET DRAFT SIPP Specification February 21, 1994 packets satifies the above order; sending packets with optional headers in some other order may or may not achieve useful effects. 5. Packet Size Issues SIPP 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 SIPP. (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.) From each link to which a node is directly attached, the node must be able to accept packets as large as that link's MTU. Links that have a configurable MTU, such as PPP links [RFC-1548], should be configured with an MTU of 600 octets or greater. SIPP 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 SIPP 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 SIPP 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 SIPP packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from SIPP to IPv4), the originating SIPP node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 576. In that case, the SIPP node is not required to reduce the size of subsequent packets to less than 576, but must include a Fragment Header in those packets so that the SIPP-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 544 octets (576 minus 24 for the SIPP Header and 8 for the Fragment Header), and smaller still if additional optional SIPP headers are used. Note: Since SIPP 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 SIPP to set a "Don't Fragment" Expires: September 21, 1994 [Page 13]
INTERNET DRAFT SIPP Specification February 21, 1994 flag in the packet header in order to perform Path MTU Discovery; that is an implicit attribute of every SIPP packet. Also, those parts of the RFC-1191 procedures that involve use of a table of MTU "plateaus" do not apply to SIPP, because the SIPP version of the "Datagram Too Big" message always identifies the exact MTU to be used. 6. Flow Label The Flow Label field in the SIPP header may be used by a source to label those packets for which it requests special handling by the SIPP routers, such as non-default quality of service or "real-time" service. This aspect of SIPP 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 28-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 FFFFFF 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. Expires: September 21, 1994 [Page 14]
INTERNET DRAFT SIPP Specification February 21, 1994 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 same Routing header contents (if present). The routers or destinations are permitted, but not 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. 7. Transport-Layer Protocol Issues 7.1 Transport-Layer Checksums When TCP, UDP, ICMP, or IGMP (subsequently referred to as "transport" protocols) is used between two or more SIPP systems, the transport checksum computation includes a "pseudo-header" of the following form: Expires: September 21, 1994 [Page 15]
INTERNET DRAFT SIPP Specification February 21, 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | Payload Type | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o If the packet contains a Routing header, the Destination Address used in the pseudo-header is that of the final destination. At the originating system, that address will be in the last element of the Routing header; at the recipient(s), that address will be in the Destination Address field of the SIP header. 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 SIPP header if there are additional headers between the SIPP 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 SIPP header if there are additional headers between the SIP header and the transport header. o The UDP checksum is not optional when UDP is used between SIPP 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). For TCP or UDP, if the remote address (i.e., the Source Address in an incoming packet, or the Destination Address in an outgoing packet) is that of an IPv4 system, i.e., has a C-bit value of 1, then the following pseudo-header is used, instead of the one shown above: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | low-order 32 bits of Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | low-order 32 bits of Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | Payload Type | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the remote address is that of an IPv4 system, a UDP Checksum field of zero in an incoming packet indicates the absence of a UDP checksum. Such Expires: September 21, 1994 [Page 16]
INTERNET DRAFT SIPP Specification February 21, 1994 packets shall be accepted as is. However, a SIPP system must always compute a checksum for outgoing UDP outgoing packets, and it must be non- zero if the remote address is that of an IPv4 system (i.e., if the result of the checksum computation is zero, the value hex FFFF must be sent in the UDP Checksum field). For ICMP or IGMP, if the remote address is that of an IPv4 system, then the following pseudo-header is used, instead of the one shown above: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | Payload Type | zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It is different from the TCP and UDP case because IPv4 systems do not include a pseudo-header in the ICMP or IGMP checksums, and therefore those checksums have to be adjusted when translating between SIPP and IPv4. The Payload Length is omitted because, otherwise, translating gateways would not be able to adjust the checksum properly when translating between a SIPP fragment and an IPv4 fragment, since the Payload Length would not be known to the translating gateway. Note that this makes ICMP and IGMP packets between SIPP and IPv4 systems vulnerable to undetected padding or truncation, if the SIPP Payload Length field is corrupted en route. Truncation would be undetected only if the missing original octets were all zero; padding would be undetected only if the added octets were all zero. 7.2 Maximum Packet Lifetime SIPP 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. Expires: September 21, 1994 [Page 17]
INTERNET DRAFT SIPP Specification February 21, 1994 Appendix A. Changes from the SIP Draft of November 10, 1992 o Changed name from "SIP" to "SIPP" as part of merger with Pip. o Revised Introduction section. o Changed the term "system" to "node", in the terminology section. o Changed Reserved field in SIP header to Flow Label. o In the section on packet size issues, added reference to possible use of the Fragment Header, described handling of path MTUs less than 576 (due to SIPP-to-IPv4 translation), and specified that PMTU Discovery must be performed even between nodes on the same subnet. o Added discussion of general structure of option headers and the ordering constraints on option headers. o Changed "Source Routing Header" to "Routing Header", and changed the field layout. o Changed "Fragmentation Header" to "Fragment Header", changed the field layout, and changed the text describing the option, including dropping the requirement that all nodes be able to reassemble packets up to 1024 octets in length. o Added the Authentication header. o Added the Hop-by-Hop Options header. o Added section on Flow Labels. o Addresses section moved to a separate SIPP Routing and Addressing Specification, in which the following changes were made: - Addresses now identify nodes, not interfaces. - Added some introductory text to the Addressing section, discussing the binding of addresses to interfaces, and the independence of subnets from physical links. - Changed text representation of SIPP addresses. - Eliminated discussion of address masks; changed to refer to prefix lengths instead. - Added definition of local-use addresses. - Changed the term "anyone address" to "cluster address", and changed definition to include only boundary routers of a cluster, not internal nodes. Expires: September 21, 1994 [Page 18]
INTERNET DRAFT SIPP Specification February 21, 1994 - Added specification of "C-bit = 1" unicast addresses. - Changed the names of some of the multicast scope levels from geographic terms (metro, country) to administrative terms (organization, community). o Subsections on ICMP and IGMP changes moved to a separate document. o Deleted subsection on Changes to Link-Layer Protocols, and revised subsection on Changes to Transport-Layer Protocols (renamed Transport-Layer Protocol Issues). o Deleted appendix on SIP Design Rationale. o Deleted appendix on Future Directions. Important differences from the SIP paper that appeared in the May 1993 issue of IEEE Network Magazine: o First 32 values of Flow Label field no longer correspond to IPv4 TOS values. o Change in the way Hop-by-Hop Options are encoded. Expires: September 21, 1994 [Page 19]
INTERNET DRAFT SIPP Specification February 21, 1994 Security Considerations <to be done> Acknowledgments The author gratefully acknowledges the many helpful suggestions of the members of the SIPP working group (formerly the SIP, IPAE, and Pip working groups), the End-to-End Protocols research group, and the Internet Community At Large. Author's Address Steve Deering Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 phone: (415) 812-4839 email: deering@parc.xerox.com Expires: September 21, 1994 [Page 20]
INTERNET DRAFT SIPP Specification February 21, 1994 References [RFC-791] J. Postel. Internet Protocol. RFC-791, September, 1981. [RFC-1191] J. Mogul and S. Deering. Path MTU Discovery. RFC-1191, November 1990. [RFC-1340] J. Reynolds and J. Postel. Assigned Numbers. RFC-1340, July 1992. [RFC-1548] W. Simpson. The Point-to-Point Protocol (PPP). RFC-1548, December, 1993. [SIPP-AUTH] R. Atkinson. SIPP Authentication Header. Internet Draft, December 1993. [SIPP-ICMP] R. Govindan and S. Deering. ICMP and IGMP for SIPP Specification. Internet Draft, February 1994. [SIPP-ROAD] S. Deering, P. Francis, and R. Govindan. Simple Internet Protocol Plus (SIPP): Routing and Addressing. Internet Draft, January 1994. [IPAE] R. Gilligan, E. Nordmark, and B. Hinden. IPAE: The SIPP Interoperability and Transition Mechanism. Internet Draft, October 1993. Expires: September 21, 1994 [Page 21]
