October 1994 R. Hinden, Editor Sun Microsystems, Inc. Internet Protocol, Version 6 (IPv6) Specification Abstract This document specifies version 6 of the Internet Protocol, a proposed successor to IP version 4. All changes from the previous draft are listed in Appendix B. There have been many contributors to this work both in terms of concepts and in terms of text. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This Internet Draft expires on March 1, 1995. Distribution of this memo is unlimited. [ED: editorial comments enclosed in square brackets, thus.] draft-hinden-ipng-ipv6-spec-00.txt [Page 1] INTERNET-DRAFT IPv6 Specification October 1, 1994 Contents Status of this Memo 1. Introduction.....................................................3 2. Terminology......................................................4 3. IPv6 Header Format...............................................5 4. IPv6 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 IPv6-in-IPv6 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............................................30 Acknowledgments....................................................30 Document Editor's Address..........................................30 References.........................................................31 draft-hinden-ipng-ipv6-spec-00.txt [Page 2] INTERNET-DRAFT IPv6 Specification October 1, 1994 1. Introduction IP version 6 (IPv6) is a new version of the Internet Protocol, designed as a successor to IP version 4 (IPv4) [RFC-791]. The changes from IPv4 to IPv6 fall primarily into the following categories: o Expanded Addressing Capabilities IPv6 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 IPv6 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 IPv6. This document specifies the basic IPv6 header and the initially-defined IPv6 extension headers and options. It also discusses packet size issues, the semantics of Flow Labels, and the effects of IPv6 on transport-layer protocols. Other aspects of IPv6 are specified in separate documents, including the following: o IPv6 Routing and Addressing [IPV6-ADDR] draft-hinden-ipng-ipv6-spec-00.txt [Page 3] INTERNET-DRAFT IPv6 Specification October 1, 1994 o ICMP and IGMP for IPv6 Specification [IPV6-ICMP] o Simple IPv6 Transition (SIT) Overview [SIT] 2. Terminology node - a protocol module that implements IPv6. router - a node that forwards IPv6 packets not explicitly addressed to itself. host - any node that is not a router. interface - a node's attachment to a link. address - an IPv6-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 IPv6. 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 an IPv6 header plus payload). path MTU - the minimum link MTU of all the links in a path between a source node and a destination node. draft-hinden-ipng-ipv6-spec-00.txt [Page 4] INTERNET-DRAFT IPv6 Specification October 1, 1994 3. IPv6 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 IPv6 header, in octets. Next Header 8-bit selector. Identifies the type of header immediately following the IPv6 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 [IPV6-ADDR] 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). draft-hinden-ipng-ipv6-spec-00.txt [Page 5] INTERNET-DRAFT IPv6 Specification October 1, 1994 4. IPv6 Extension Headers In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 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, an IPv6 packet may carry zero, one, or more extension headers, each identified by the Next Header field of the preceding header: +---------------+------------------------ | IPv6 header | TCP header + data | | | Next Header = | | TCP | +---------------+------------------------ +---------------+----------------+------------------------ | IPv6 header | Routing header | TCP header + data | | | | Next Header = | Next Header = | | Routing | TCP | +---------------+----------------+------------------------ +---------------+----------------+-----------------+----------------- | IPv6 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 IPv6 header. There, normal demultiplexing on the Next Header field of the IPv6 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 IPv6 header. Its presence is indicated by the draft-hinden-ipng-ipv6-spec-00.txt [Page 6] INTERNET-DRAFT IPv6 Specification October 1, 1994 special value zero in the Next Header field of the IPv6 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: IPv6 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 IPv6-in-IPv6 encapsulation, where each encapsulated IPv6 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. IPv6 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. draft-hinden-ipng-ipv6-spec-00.txt [Page 7] INTERNET-DRAFT IPv6 Specification October 1, 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 IPv6 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. draft-hinden-ipng-ipv6-spec-00.txt [Page 8] INTERNET-DRAFT IPv6 Specification October 1, 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 IPv6 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. draft-hinden-ipng-ipv6-spec-00.txt [Page 9] INTERNET-DRAFT IPv6 Specification October 1, 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 IPv6 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. draft-hinden-ipng-ipv6-spec-00.txt [Page 10] INTERNET-DRAFT IPv6 Specification October 1, 1994 4.4 Routing Header The Routing header is used by an IPv6 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 IPv6 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 IPv6 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 IPv6 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. draft-hinden-ipng-ipv6-spec-00.txt [Page 11] INTERNET-DRAFT IPv6 Specification October 1, 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. draft-hinden-ipng-ipv6-spec-00.txt [Page 12] INTERNET-DRAFT IPv6 Specification October 1, 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 IPv6 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 IPv6 Destination Address and Address[Next Addr], increment Next Addr by one, and re-submit the packet to the IPv6 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. [ED: 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?] Multicast addresses must not appear in a Routing header of Type 0, or in the IPv6 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. draft-hinden-ipng-ipv6-spec-00.txt [Page 13] INTERNET-DRAFT IPv6 Specification October 1, 1994 4.5 Fragment Header The Fragment header is used by an IPv6 source to send payloads larger than would fit in the path MTU to their destinations. (Note: unlike IPv4, fragmentation in IPv6 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 IPv6 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 IPv6 Source Address, IPv6 Destination Address, and Fragment Next Header value. (If a Routing header is present, the IPv6 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. draft-hinden-ipng-ipv6-spec-00.txt [Page 14] INTERNET-DRAFT IPv6 Specification October 1, 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 IPv6 header contains the length of that packet only (excluding the IPv6 header itself), not the length of the original, unfragmented payload. draft-hinden-ipng-ipv6-spec-00.txt [Page 15] INTERNET-DRAFT IPv6 Specification October 1, 1994 4.6 Authentication Header The Authentication header is used to provide authentication and integrity assurance for IPv6 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 IPv6 Destination 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 [IPV6_AUTH]. All IPv6 nodes are required to support the keyed MD5 algorithm used with the draft-hinden-ipng-ipv6-spec-00.txt [Page 16] INTERNET-DRAFT IPv6 Specification October 1, 1994 Authentication header as described in that document. [ED: Should transport-layer checksumming rules change when integrity is being provided by the authentication header?] 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 an IPv6 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 draft-hinden-ipng-ipv6-spec-00.txt [Page 17] INTERNET-DRAFT IPv6 Specification October 1, 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 more efficient parsing, 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 IPv6-in-IPv6 Encapsulation The value 41 in the Next Header field of an IPv6 header or any of its extension headers indicates that the immediately following header is another IPv6 header (which, in turn, may have its own extension headers). [ED: A discussion of tunneling needs to go here.] [ED: 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 IPv6 header and the desired extension header(s).] draft-hinden-ipng-ipv6-spec-00.txt [Page 18] INTERNET-DRAFT IPv6 Specification October 1, 1994 5. Packet Size Issues IPv6 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 IPv6. 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. IPv6 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 IPv6 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 IPv6 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 an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next- Hop MTU less than 576. In that case, the IPv6 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 IPv6-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 IPv6 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 IPv6 to set a "Don't draft-hinden-ipng-ipv6-spec-00.txt [Page 19] INTERNET-DRAFT IPv6 Specification October 1, 1994 Fragment" flag in the packet header in order to perform Path MTU Discovery; that is an implicit attribute of every IPv6 packet. Also, those parts of the RFC-1191 procedures that involve use of a table of MTU "plateaus" do not apply to IPv6, because the IPv6 version of the "Datagram Too Big" message always identifies the exact MTU to be used. [ED: Perhaps we should make the IPv6 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?] draft-hinden-ipng-ipv6-spec-00.txt [Page 20] INTERNET-DRAFT IPv6 Specification October 1, 1994 6. Flow Labels The Flow Label field in the IPv6 header may be used by a source to label those packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. This aspect of IPv6 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. draft-hinden-ipng-ipv6-spec-00.txt [Page 21] INTERNET-DRAFT IPv6 Specification October 1, 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 IPv6 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. draft-hinden-ipng-ipv6-spec-00.txt [Page 22] INTERNET-DRAFT IPv6 Specification October 1, 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 IPv6 nodes, their checksum algorithms must be changed to use the pseudo-header illustrated below. When ICMP or IGMP is used between IPv6 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 IPv6 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 IPv6 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 IPv6 header if there are draft-hinden-ipng-ipv6-spec-00.txt [Page 23] INTERNET-DRAFT IPv6 Specification October 1, 1994 additional headers between the IPv6 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 IPv6 header if there are additional headers between the IPv6 header and the transport header. o Unlike IPv4, when UDP are originated by an IPv6 node, the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 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. [ED: The following rules for pseudo checksum calculation need to reviewed] 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 80 zero bits, then the pseudo-header shown above is used. 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, an IPv6 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: draft-hinden-ipng-ipv6-spec-00.txt [Page 24] INTERNET-DRAFT IPv6 Specification October 1, 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 IPv6 and IPv4. The Payload Length is omitted because, otherwise, translating gateways would not be able to adjust the checksum properly when translating between an IPv6 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 IPv6 and IPv4 systems vulnerable to undetected padding or truncation, if the IPv6 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, IPv6 nodes are not required to enforce maximum packet lifetime. (That's why the IPv4 "Time to Live" field was renamed "Hop Limit" in IPv6.) 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 IPv6) to limit packet lifetime ought to be upgraded to provide its own mechanisms for detecting and discarding obsolete packets. draft-hinden-ipng-ipv6-spec-00.txt [Page 25] INTERNET-DRAFT IPv6 Specification October 1, 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 (up to a maximum alignment of 8 octets). 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 draft-hinden-ipng-ipv6-spec-00.txt [Page 26] INTERNET-DRAFT IPv6 Specification October 1, 1994 up on a multiple-of-8 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 | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-hinden-ipng-ipv6-spec-00.txt [Page 27] INTERNET-DRAFT IPv6 Specification October 1, 1994 Example 3 A Hop-by-Hop or End-to-End Options header containing both options X and Y from Examples 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 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ draft-hinden-ipng-ipv6-spec-00.txt [Page 28] INTERNET-DRAFT IPv6 Specification October 1, 1994 Appendix B. Changes from Previous Draft Changes from the SIPP Draft of July 17, 1994 [SIPP]. o Changed name of protocol from SIPP to IPv6. o Changed the Security Association ID in the Authentication Header to be destination-relative, rather than source-relative. o Changed (simplified) the rules for pseudo-checksum calculation for datagrams sent/received to/from IPv4 system to accommodate the current formats for these addresses. draft-hinden-ipng-ipv6-spec-00.txt [Page 29] INTERNET-DRAFT IPv6 Specification October 1, 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 IPv6 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 [IPV6_AUTH]. Acknowledgments The document editor gratefully acknowledges the contributions of Steve Deering of Xerox PARC, who contributed most of the text and ideas in this document, the many helpful suggestions of the members of the IPng working group, the End-to-End Protocols research group, and the Internet Community At Large. Editor's Address Robert M. Hinden Sun Microsystems, Inc. MS MTV5-44 2550 Garcia Ave. Mt. View, CA 94043 USA Phone: (415) 336-2082 FAX: (415) 336-6015 Email: hinden@eng.sun.com draft-hinden-ipng-ipv6-spec-00.txt [Page 30] INTERNET-DRAFT IPv6 Specification October 1, 1994 References [IPV6-AUTH] R. Atkinson, "IPv6 Authentication Header", Internet Draft, draft-ietf-sipp-ap-04.txt, August 1994. [IPV6-ICMP] S. Deering, A. Conta, "ICMP and IGMP for the Internet Protocol Version 6 (IPv6)", Internet Draft, In Preparation, October 1994. [IPV6-ADDR] R. Hinden, Editor, "IP Next Generation Addressing Architecture", Internet Draft, draft-hinden-ipng-addr- 00.txt, October 1994. [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] S. Deering, "Simple Internet Protocol Plus (SIPP) Specification (128-bit address version)", Internet Draft, draft-ietf-sipp-spec-00.txt, July 1994. [SIT] R. Gilligan, "Simple IPv6 Transition (SIT) Overview, Internet Draft, In Perpetration. draft-hinden-ipng-ipv6-spec-00.txt [Page 31]