INTERNET-DRAFT S. Deering July 17, 1994 Xerox PARC Obsoletes: draft-ietf-sipp-spec-00.txt Simple Internet Protocol Plus (SIPP) Specification (128-bit address version) draft-ietf-sipp-spec-01.txt Abstract This document specifies a proposed new version of the Internet Protocol. The most significant difference from the previous draft is the change of address length from 64 to 128 bits. All changes from the previous draft are listed in Appendix B. [editorial comments enclosed in square brackets, thus. -SD] 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 January 17, 1995. 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: January 17, 1995 [Page 1] Internet Draft SIPP Specification July 17, 1994 Contents Status of this Memo..............................................1 1. Introduction..................................................3 2. Terminology...................................................4 3. SIPP Header Format............................................5 4. SIPP Extension Headers........................................6 4.1 Extension Header Order...................................7 4.2 Options..................................................8 4.3 Hop-by-Hop Options Header...............................10 4.4 Routing Header..........................................11 4.5 Fragment Header.........................................14 4.6 Authentication Header...................................16 4.7 End-to-End Options Header...............................17 4.8 SIPP-in-SIPP Encapsulation..............................18 5. Packet Size Issues...........................................19 6. Flow Labels..................................................21 7. Transport-Layer Protocol Issues..............................23 7.1 Transport-Layer Checksums...............................23 7.2 Maximum Packet Lifetime.................................25 Appendix A. Formatting Guidelines for Options...................26 Appendix B. Changes from Previous Draft.........................29 Security Considerations.........................................31 Acknowledgments.................................................31 Author's Address................................................31 References......................................................32 Expires: January 17, 1995 [Page 2] Internet Draft SIPP Specification July 17, 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 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes, and simpler auto-configuration of addresses. The scalability of multicast routing is improved by adding a "scope" field to multicast addresses. And a new type of address called a "cluster address" is defined, to identify topological regions rather than individual nodes. 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 limit the bandwidth cost of the SIPP header. o Improved Support for Extensions and 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. o Authentication and Privacy Capabilities Extensions to support authentication, data integrity, and (optional) data confidentiality are specified for SIPP. This document specifies the basic SIPP header and the initially-defined SIPP extension headers and 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: Expires: January 17, 1995 [Page 3] Internet Draft SIPP Specification July 17, 1994 o Simple Internet Protocol Plus (SIPP): Routing and Addressing [SIPP-ROAD] o ICMP and IGMP for SIPP Specification [SIPP-ICMP] o Simple SIPP Transition (SST) Overview [SST] 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. interface - a node's attachment to a link. address - a SIPP-layer identifier for an interface or a group of interfaces. link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below SIPP. 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. Expires: January 17, 1995 [Page 4] Internet Draft SIPP Specification July 17, 1994 3. SIPP Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | 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. Next Header 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 128 bits. An address of the initial sender of the packet. See [SIPP-ROAD] for details. Destination Address 128 bits. An address of the intended recipient of the packet (possibly not the ultimate recipient, if a Routing Header is present). Expires: January 17, 1995 [Page 5] Internet Draft SIPP Specification July 17, 1994 4. SIPP Extension Headers 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 extension headers, each identified by a distinct Next Header value. As illustrated in these examples, a SIPP packet may carry zero, one, or more extension headers, each identified by the Next Header field of the preceding header: +---------------+------------------------ | SIPP header | TCP header + data | | | Next Header = | | TCP | +---------------+------------------------ +---------------+----------------+------------------------ | SIPP header | Routing header | TCP header + data | | | | Next Header = | Next Header = | | Routing | TCP | +---------------+----------------+------------------------ +---------------+----------------+-----------------+----------------- | SIPP header | Routing header | Fragment header | fragment of TCP | | | | header + data | Next Header = | Next Header = | Next Header = | | Routing | Fragment | TCP | +---------------+----------------+-----------------+----------------- With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the SIPP header. There, normal demultiplexing on the Next Header field of the SIPP header invokes the module to process the first extension header, or the transport header if no extension 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 information 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 Expires: January 17, 1995 [Page 6] Internet Draft SIPP Specification July 17, 1994 special value zero in the Next Header field of the SIPP header. Each extension header is an integer multiple of 8 octets long, in order to retain 8-octet alignment for subsequent headers. Multi-octet fields within each extension 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, for n = 1, 2, 4, or 8. 4.1 Extension Header Order When more than one extension header is used in the same packet, the headers should appear in the following order: SIPP header Hop-by-Hop Options header Routing header Fragment header Authentication header End-to-End Options header Each type of header should appear only once in a packet (except in the case of SIPP-in-SIPP encapsulation, where each encapsulated SIPP header may be followed by its own instance of a particular extension header -- see section 4.8). If and when other extension 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 packets satisfies the above order; sending packets with extension headers in some other order may or may not achieve useful effects. Expires: January 17, 1995 [Page 7] Internet Draft SIPP Specification July 17, 1994 4.2 Options Two of the currently-defined extension headers -- the Hop-by-Hop Options header and the End-to-End Options header -- may carry a variable number of Type-Length-Value (TLV) encoded "options", of the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 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 header. 01 - discard the packet. 10 - discard the packet and send an ICMP Unrecognized Type 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 Unrecognized Type message to the packet's Source Address, pointing to the unrecognized Option Type. In the case of Hop-by-Hop options only, 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 Data fields of End-to-End options never change en route and, therefore, are always included in the integrity computation. Expires: January 17, 1995 [Page 8] Internet Draft SIPP Specification July 17, 1994 Individual options may have specific 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 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. There are two padding options which are used when necessary to align subsequent options and to pad out the containing 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 a 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 a 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. Appendix A contains formatting guidelines for designing new options. Expires: January 17, 1995 [Page 9] Internet Draft SIPP Specification July 17, 1994 4.3 Hop-by-Hop Options Header The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path. The Hop-by-Hop Options header is identified by a Next Header value of 0 in the SIPP header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the type of header immediately following the Hop-by-Hop Options header. Uses the same values as the IPv4 Protocol field [RFC-1340]. Hdr Ext Len 8-bit unsigned integer. Length of the Hop-by-Hop Options header in 8-octet units, not including the first 8 octets. Options Variable-length field, of length such that the complete Hop-by-Hop Options header is an integer multiple of 8 octets long. Contains one or more TLV-encoded options, as described in section 4.2. The only Hop-by-Hop options specified by this document are the two Pad options described in section 4.2. Expires: January 17, 1995 [Page 10] Internet Draft SIPP Specification July 17, 1994 4.4 Routing Header The Routing header is used by a SIPP source to list one or more intermediate nodes (or topological clusters) to be "visited" on the way to a packet's destination. This function is very similar to IPv4's Source Route options. It is NOT intended that this header be inserted into a packet by any node other than the one identified in the Source Address field of the SIPP header; if another node somewhere along a packet's path wishes to change or influence the route of a packet, it may encapsulate it in other SIPP header, possibly with its own Routing extension header (see section 4.8). The Routing header is identified by a Next Header value of 43 in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Routing Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . type-specific data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the type of header immediately following the Routing header. Uses the same values as the IPv4 Protocol field [RFC-1340]. Routing Type 8-bit identifier of a particular Routing header variant. type-specific data Variable-length field, of format determined by the Routing Type, and of length such that the complete Routing header is an integer multiple of 8 octets long. If the SIPP node that is processing a Routing Header does not recognize the Routing Type value, it must discard the packet and, only if the packet's Destination Address is not a multicast address, send an ICMP Unrecognized Type message to the packet's Source Address, pointing to the unrecognized Routing Type. Expires: January 17, 1995 [Page 11] Internet Draft SIPP Specification July 17, 1994 Routing Type 0 means "Loose Source Route"; a Type 0 Routing header has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Routing Type=0 | Num Addrs | Next Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[0] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[1] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[Num Addrs - 1] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the type of header immediately following the Routing header. Uses the same values as the IPv4 Protocol field [RFC-1340]. Routing Type 0. Num Addrs 8-bit unsigned integer. Number of addresses in the Routing header. Expires: January 17, 1995 [Page 12] Internet Draft SIPP Specification July 17, 1994 Next Addr 8-bit unsigned integer. Index of next address to be processed; initialized to 0 by the originating node. Reserved 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 Next Header field of the immediately preceding header causes the Routing module to be invoked, which, in the case of Routing Type 0, 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 packet to the SIPP module for forwarding to the next destination. o If Next Addr = Num Addrs, dispatch to the next header processing module, as identified by the Next Header 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. [need to put route-reversing rules here, for reply messages from a destination and for ICMP error messages from any intermediate node along the source-routed path; is this safe to do in response to non- authenticated packets? -SD] Multicast addresses must not appear in a Routing header of Type 0, or in the SIPP Destination Address field of a packet carrying a Routing header of Type 0. It is expected the additional Routing Types will be defined in the future, to support more sophisticated routing alternatives. Expires: January 17, 1995 [Page 13] Internet Draft SIPP Specification July 17, 1994 4.5 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 Next Header value of 44 in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 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, Res Initialized to zero for transmission; ignored on reception. 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. M flag 1 = more fragments; 0 = last fragment. Identification 32 bits. See description below. The fragmentation algorithm is as follows: The payload (including any extension 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 Next Header value. (If a 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. Expires: January 17, 1995 [Page 14] Internet Draft SIPP Specification July 17, 1994 * "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, next header 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. Expires: January 17, 1995 [Page 15] Internet Draft SIPP Specification July 17, 1994 4.6 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. The Authentication header is identified by a Next Header value of 51 in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type | Auth Data Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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]. Auth Data Len 8-bit unsigned integer. Length of the Authentication Data field in 8-octet units. Reserved Initialized to zero for transmission; ignored on reception. 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. Use of the Authentication header is specified in [SIPP_AUTH]. All SIPP nodes are required to support the keyed MD5 algorithm used with the Expires: January 17, 1995 [Page 16] Internet Draft SIPP Specification July 17, 1994 Authentication header as described in that document. [should transport-layer checksumming rules change when integrity is being provided by the authentication header? -SD] 4.7 End-to-End Options Header The End-to-End Options header is used to carry optional information that need be examined only by a packet's destination node(s). The End-to-End Options header is identified by a Next Header value of TBD in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the type of header immediately following the End-to-End Options header. Uses the same values as the IPv4 Protocol field [RFC-1340]. Hdr Ext Len 8-bit unsigned integer. Length of the End-to-End Options header in 8-octet units, not including the first 8 octets. Options Variable-length field, of length such that the complete End-to-End Options header is an integer multiple of 8 octets long. Contains one or more TLV-encoded options, as described in section 4.2. The only End-to-End options specified by this document are the two Pad options described in section 4.2. Note that there are two possible ways to encode optional end-to-end information in a SIPP packet: either as an option in the End-to-End Options header, or as a separate extension header that does not precede the Routing header (see the header ordering rules in section 4.1). The Expires: January 17, 1995 [Page 17] Internet Draft SIPP Specification July 17, 1994 Fragment header and the Authentication header are examples of the latter approach. Which approach can be used depends on what action is desired of a destination node that does not understand the optional information: o if the desired action is for the destination node to discard the packet and, only if the packet's Destination Address is not a multicast address, send an ICMP Unrecognized Type message to the packet's Source Address, then the information may be encoded either as a separate header or as an option in the End-to-End Options header whose Option Type has the value 11 in its highest- order two bits. The choice may depend on such factors as which takes fewer octets, which yields better alignment, or simply "aesthetics". o if any other action is desired, the information must be encoded as an option in the End-to-End Options header whose Option Type has the value 00, 01, or 10 in its highest-order two bits, specifying the desired action (see section 4.2). 4.8 SIPP-in-SIPP Encapsulation The value 41 in the Next Header field of a SIPP header or any of its extension headers indicates that the immediately following header is another SIPP header (which, in turn, may have its own extension headers). [a discussion of tunneling needs to go here. -SD] [should specify that extension headers must not be inserted into a packet en route, because of the negative effect of that on path MTU discovery and interpretation of ICMP error messages, but rather can be added only by prepending another SIPP header and the desired extension header(s). -SD] Expires: January 17, 1995 [Page 18] Internet Draft SIPP Specification July 17, 1994 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 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 528 octets (576 minus 40 for the SIPP Header and 8 for the Fragment Header), and smaller still if additional extension headers are used. Note: Path MTU Discovery must be performed even in cases where a host "thinks" a destination is attached to the same link as itself. Note: Unlike IPv4, it is unnecessary in SIPP to set a "Don't Expires: January 17, 1995 [Page 19] Internet Draft SIPP Specification July 17, 1994 Fragment" 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. [perhaps we should make the SIPP minimum MTU be 1500 octets, and rely on link-level fragmentation/reassembly and fragment interleaving over slow links to provide adequately low delay for interactive packets? -SD] Expires: January 17, 1995 [Page 20] Internet Draft SIPP Specification July 17, 1994 6. Flow Labels 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, pass the field on unchanged when forwarding a packet, and 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: January 17, 1995 [Page 21] Internet Draft SIPP Specification July 17, 1994 All packets sent with the same Source Address and same non-zero Flow ID must also be originated with 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 the high-order octet of the Flow ID field (i.e., the second octet of the SIPP header). 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 - (reserved) 4 - attended bulk transfer (e.g., FTP, NFS) 5 - (reserved) 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. Expires: January 17, 1995 [Page 22] Internet Draft SIPP Specification July 17, 1994 7. Transport-Layer Protocol Issues 7.1 Transport-Layer Checksums When TCP or UDP (or any other protocol that includes in its transport or higher-layer checksum the same "pseudo-header" of internet-layer information as do TCP and UDP) is used between SIPP nodes, their checksum algorithms must be changed to use the pseudo-header illustrated below. When ICMP or IGMP is used between SIPP nodes, their checksum algorithms must also be changed to include this pseudo-header, even though those protocols do not include a pseudo-header when used between IPv4 nodes (the reason being to protect ICMP and IGMP from misdelivery or corruption of those fields of the SIPP header on which they depend, which, unlike IPv4, are not covered by an internet-layer checksum). All of these protocols (TCP, UDP, ICMP, IGMP, and others) are referred to as "transport protocols", below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | Next Header | 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 SIPP header. o The Next Header value in the pseudo-header identifies the transport protocol (e.g., 1 for ICMP, 6 for TCP, etc.). It will differ from the Next Header value in the SIPP header if there are Expires: January 17, 1995 [Page 23] Internet Draft SIPP Specification July 17, 1994 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, including the transport header. It will be less than the Payload Length in the SIPP header if there are additional headers between the SIPP header and the transport header. o Unlike IPv4, when UDP are originated by a SIPP node, the UDP checksum is not optional. That is, whenever originating a UDP packet, a SIPP node must compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, it must be changed to hex FFFF for placement in the UDP header. For TCP, UDP or other protocols using the same pseudo-header (but NOT ICMP or IGMP), 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-only system, i.e., has a prefix of 96 zero bits, 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 | Next Header | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the remote address is that of an IPv4-only system, a UDP Checksum field of zero in an incoming packet indicates the absence of a UDP checksum. Such packets shall be accepted as is. However, a SIPP system must always compute a valid (non-zero) checksum for outgoing UDP packets. For ICMP or IGMP, if the remote address is that of an IPv4-only system, then the following pseudo-header is used, instead of the one shown above: Expires: January 17, 1995 [Page 24] Internet Draft SIPP Specification July 17, 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | Next Header | 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 Unlike IPv4, SIPP nodes are not required to enforce maximum packet lifetime. (That's why the IPv4 "Time to Live" field was renamed "Hop Limit" in SIPP.) In practice, very few, if any, IPv4 implementations conform to the requirement that they limit packet lifetime, so this is not really a change in practice. Any transport protocol that relies on the internet layer (whether IPv4 or SIPP) to limit packet lifetime ought to be upgraded to provide its own mechanisms for detecting and discarding obsolete packets. Expires: January 17, 1995 [Page 25] Internet Draft SIPP Specification July 17, 1994 Appendix A. Formatting Guidelines for Options This appendix gives some advice on how to lay out the fields in options to be used in the Hop-by-Hop Options header or the End-to-End Options header, as described in section 4.2. These guidelines are based on the following assumptions: o One desirable feature is that any multi-octet fields within the Option Data area of an option be aligned on their natural boundaries, i.e., fields of width n octets should be placed at an integer multiple of n octets from the start of the Hop-by-Hop or End-to-End Options header, for n = 1, 2, 4, or 8. o Another desirable feature is that the Hop-by-Hop or End-to-End Options header take up as little space as possible, subject to the requirement that the header be an integer multiple of 8 octets long. o It may be assumed that, when either of the option-bearing headers are present, they carry a very small number of options, usually only one. These assumptions suggest the following approach to laying out the fields of an option: order the fields from smallest to largest, with no interior padding, then derive the alignment requirement for the entire option based on the alignment requirement of the largest field. This approach is illustrated in the following examples: Example 1 If an option X required two data fields, one of length 8 octets and one of length 4 octets, it would be laid out as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-octet field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Its alignment requirement is 8n+2, to ensure that the 8-octet field ends up on a multiple-of-8 offset from the start of the enclosing header. A Expires: January 17, 1995 [Page 26] Internet Draft SIPP Specification July 17, 1994 complete Hop-by-Hop or End-to-End Options header containing this one option would look as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Hdr Ext Len=1 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-octet field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example 2 If an option Y required three data fields, one of length 4 octets, one of length 2 octets, and one of length 1 octet, it would be laid out as follows: +-+-+-+-+-+-+-+-+ | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-octet field | 2-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Its alignment requirement is 4n+3, to ensure that the 4-octet field ends up on a multiple-of-4 offset from the start of the enclosing header. A complete Hop-by-Hop or End-to-End Options header containing this one option would look as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Hdr Ext Len=1 |Pad1 Option=0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-octet field | 2-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PadN Option = 1|Opt Data Len=2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires: January 17, 1995 [Page 27] Internet Draft SIPP Specification July 17, 1994 Example 3 A Hop-by-Hop or End-to-End Options header containing both options X and Y from Example 1 and 2 would have one of the two following formats, depending on which option appeared first: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Hdr Ext Len=1 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-octet field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PadN Option = 1|Opt Data Len=1 | 0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-octet field | 2-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PadN Option = 1|Opt Data Len=2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Hdr Ext Len=1 |Pad1 Option=0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | 1-octet field | 2-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PadN Option = 1|Opt Data Len=4 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4-octet field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 8-octet field + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires: January 17, 1995 [Page 28] Internet Draft SIPP Specification July 17, 1994 Appendix B. Changes from Previous Draft Changes from the SIPP Draft of February 21, 1994 (erroneously dated February 21, 1993), draft-ietf-sipp-spec-00.txt: o Changed address size from 8 octets to 16 octets o Changed addresses back to identifying interfaces, not nodes. o Changed name of "Payload Type" field to "Next Header". o Changed to reference the SST transition plan, rather than IPAE. o Deleted the term "subnet" from the Terminology section, and changed wording of the Note under Packet Size Issues specifying that Path MTU Discovery must be performed even between nodes on the same subnet. o Deleted the term "packetization layer" from the Terminology section, since it was not used anywhere. o Rearranged the subsections on extension headers and options. o Specified an End-to-End Options header, for advisory (ignorable) end-to-end options. o Changed the phrase "optional headers" to "extension headers", to avoid confusion with "options" that are carried within the Hop- by-Hop and End-to-End Options headers. o Specified that unrecognized options should trigger a new ICMP Unrecognized Type message, instead of Parameter Problem. o Corrected description of the Options field in the Hop-by-Hop Options header to state that the complete header is a multiple of 8 octets, rather than the Options field itself being a multiple of 8 octets. o Added some text noting that the Routing Header is for use only by the source of a packet, and not to be inserted by some other node while a packet is in transit. o Defined a new Routing Type field in the Routing header, to allow for the future definition of different variants of the header. o Changed position of the Next Addr field in the Routing Header to exploit cheap increment instructions. Expires: January 17, 1995 [Page 29] Internet Draft SIPP Specification July 17, 1994 o Changed field layout of Fragment Header to eliminate need to shift the Fragment Offset field. o Under Authentication Header, deleted a sentence about optional privacy via encryption. o Deleted Sequence Number field from the Authentication Header. o Added a (one sentence) subsection on SIPP-in-SIPP encapsulation. o Specified that, when a change of Destination Address, Hop-by-Hop Option header, or Routing header is detected within a flow, the resulting Parameter Problem message should point to the Flow ID field, not the changed field. o Under Transport-Layer Checksums, changed reference to the "C-bit" to "a prefix of 96 zero bits". o Simplified the rule for SIPP handling of UDP checksums: now, SIPP nodes must always generate non-zero UDP checksums. o Added a sentence pointing out that the lack of maximum packet lifetime enforcement in SIPP is not a change from current IPv4 practice. o Added an appendix on how to format options. Expires: January 17, 1995 [Page 30] Internet Draft SIPP Specification July 17, 1994 Security Considerations This document specifies the format of an Authentication option, which is part of the machinery intended to provide end-to-end authentication and integrity assurance for SIPP 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 option. Usage of the option is specified in [SIPP_AUTH]. 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: January 17, 1995 [Page 31] Internet Draft SIPP Specification July 17, 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, April, 1994. [SIPP-AUTH] R. Atkinson. SIPP Authentication Header. Internet Draft, July 1994. [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. [SST] R. Gilligan. Simple SIPP Transition (SST) Overview. Internet Draft, July 1994. Expires: January 17, 1995 [Page 32]