Network Working Group
`Request for Comments: 2460
`Obsoletes: 1883
`Category: Standards Track
`
`S. Deering
`Cisco
`R. Hinden
`Nokia
`December 1998
`
`Internet Protocol, Version 6 (IPv6)
`Specification
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1998). All Rights Reserved.
`
`Abstract
`
` This document specifies version 6 of the Internet Protocol (IPv6),
` also sometimes referred to as IP Next Generation or IPng.
`
`Table of Contents
`
`1. Introduction..................................................2
`2. Terminology...................................................3
`3. IPv6 Header Format............................................4
`4. IPv6 Extension Headers........................................6
`4.1 Extension Header Order...................................7
`4.2 Options..................................................9
`4.3 Hop-by-Hop Options Header...............................11
`4.4 Routing Header..........................................12
`4.5 Fragment Header.........................................18
`4.6 Destination Options Header..............................23
`4.7 No Next Header..........................................24
`5. Packet Size Issues...........................................24
`6. Flow Labels..................................................25
`7. Traffic Classes..............................................25
`8. Upper-Layer Protocol Issues..................................27
`8.1 Upper-Layer Checksums...................................27
`8.2 Maximum Packet Lifetime.................................28
`8.3 Maximum Upper-Layer Payload Size........................28
`8.4 Responding to Packets Carrying Routing Headers..........29
`
`Deering & Hinden
`
`Standards Track
`
`[Page 1]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 1 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` Appendix A. Semantics and Usage of the Flow Label Field.........30
` Appendix B. Formatting Guidelines for Options...................32
` Security Considerations.........................................35
` Acknowledgments.................................................35
` Authors’ Addresses..............................................35
` References......................................................35
` Changes Since RFC-1883..........................................36
` Full Copyright Statement........................................39
`
`1. Introduction
`
` IP version 6 (IPv6) is a new version of the Internet Protocol,
` designed as the 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 an "anycast address" is defined, used to send
` a packet to any one of a group of 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.
`
`Deering & Hinden Standards Track [Page 2]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 2 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` 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 traffic classes, and
` the effects of IPv6 on upper-layer protocols. The format and
` semantics of IPv6 addresses are specified separately in [ADDRARCH].
` The IPv6 version of ICMP, which all IPv6 implementations are required
` to include, is specified in [ICMPv6].
`
`2. Terminology
`
` node - a device that implements IPv6.
`
` router - a node that forwards IPv6 packets not explicitly
` addressed to itself. [See Note below].
`
` host - any node that is not a router. [See Note below].
`
` upper layer - a protocol layer immediately above IPv6. Examples are
` transport protocols such as TCP and UDP, control
` protocols such as ICMP, routing protocols such as OSPF,
` and internet or lower-layer protocols being "tunneled"
` over (i.e., encapsulated in) IPv6 such as IPX,
` AppleTalk, or IPv6 itself.
`
` link - a communication facility or medium over which nodes can
` communicate at the link layer, i.e., the layer
` immediately below IPv6. Examples are Ethernets (simple
` or bridged); PPP links; X.25, Frame Relay, or ATM
` networks; and internet (or higher) layer "tunnels",
` such as tunnels over IPv4 or IPv6 itself.
`
` neighbors - nodes attached to the same link.
`
` interface - a node’s attachment to a link.
`
` address - an IPv6-layer identifier for an interface or a set of
` interfaces.
`
` packet - an IPv6 header plus payload.
`
` link MTU - the maximum transmission unit, i.e., maximum packet
` size in octets, that can be conveyed over a link.
`
`Deering & Hinden Standards Track [Page 3]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 3 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` path MTU - the minimum link MTU of all the links in a path between
` a source node and a destination node.
`
` Note: it is possible, though unusual, for a device with multiple
` interfaces to be configured to forward non-self-destined packets
` arriving from some set (fewer than all) of its interfaces, and to
` discard non-self-destined packets arriving from its other interfaces.
` Such a device must obey the protocol requirements for routers when
` receiving packets from, and interacting with neighbors over, the
` former (forwarding) interfaces. It must obey the protocol
` requirements for hosts when receiving packets from, and interacting
` with neighbors over, the latter (non-forwarding) interfaces.
`
`3. IPv6 Header Format
`
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` |Version| Traffic Class | Flow Label |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Payload Length | Next Header | Hop Limit |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` + +
` | |
` + Source Address +
` | |
` + +
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` + +
` | |
` + Destination Address +
` | |
` + +
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` Version 4-bit Internet Protocol version number = 6.
`
` Traffic Class 8-bit traffic class field. See section 7.
`
` Flow Label 20-bit flow label. See section 6.
`
` Payload Length 16-bit unsigned integer. Length of the IPv6
` payload, i.e., the rest of the packet following
` this IPv6 header, in octets. (Note that any
`
`Deering & Hinden Standards Track [Page 4]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 4 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` extension headers [section 4] present are
` considered part of the payload, i.e., included
` in the length count.)
`
` 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-1700
` et seq.].
`
` 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-bit address of the originator of the packet.
` See [ADDRARCH].
`
` Destination Address 128-bit address of the intended recipient of the
` packet (possibly not the ultimate recipient, if
` a Routing header is present). See [ADDRARCH]
` and section 4.4.
`
`Deering & Hinden Standards Track [Page 5]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 5 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
`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 upper-
` 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 upper-layer header if no extension header is present. The
` contents and semantics of each extension header determine whether or
` not to proceed to the next header. Therefore, extension headers must
` be processed strictly in the order they appear in the packet; a
` receiver must not, for example, scan through a packet looking for a
` particular kind of extension header and process that header prior to
` processing all preceding ones.
`
`Deering & Hinden Standards Track [Page 6]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 6 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` The exception referred to in the preceding paragraph is the Hop-by-
` Hop Options header, which carries information that must be examined
` and processed by every node along a packet’s delivery path, including
` the source and destination nodes. The Hop-by-Hop Options header,
` when present, must immediately follow the IPv6 header. Its presence
` is indicated by the value zero in the Next Header field of the IPv6
` header.
`
` If, as a result of processing a header, a node is required to proceed
` to the next header but the Next Header value in the current header is
` unrecognized by the node, it should discard the packet and send an
` ICMP Parameter Problem message to the source of the packet, with an
` ICMP Code value of 1 ("unrecognized Next Header type encountered")
` and the ICMP Pointer field containing the offset of the unrecognized
` value within the original packet. The same action should be taken if
` a node encounters a Next Header value of zero in any header other
` than an 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.
`
` A full implementation of IPv6 includes implementation of the
` following extension headers:
`
` Hop-by-Hop Options
` Routing (Type 0)
` Fragment
` Destination Options
` Authentication
` Encapsulating Security Payload
`
` The first four are specified in this document; the last two are
` specified in [RFC-2402] and [RFC-2406], respectively.
`
`4.1 Extension Header Order
`
` When more than one extension header is used in the same packet, it is
` recommended that those headers appear in the following order:
`
` IPv6 header
` Hop-by-Hop Options header
` Destination Options header (note 1)
` Routing header
` Fragment header
`
`Deering & Hinden Standards Track [Page 7]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 7 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` Authentication header (note 2)
` Encapsulating Security Payload header (note 2)
` Destination Options header (note 3)
` upper-layer header
`
` note 1: for options to be processed by the first destination
` that appears in the IPv6 Destination Address field
` plus subsequent destinations listed in the Routing
` header.
`
` note 2: additional recommendations regarding the relative
` order of the Authentication and Encapsulating
` Security Payload headers are given in [RFC-2406].
`
` note 3: for options to be processed only by the final
` destination of the packet.
`
` Each extension header should occur at most once, except for the
` Destination Options header which should occur at most twice (once
` before a Routing header and once before the upper-layer header).
`
` If the upper-layer header is another IPv6 header (in the case of IPv6
` being tunneled over or encapsulated in IPv6), it may be followed by
` its own extension headers, which are separately subject to the same
` ordering recommendations.
`
` If and when other extension headers are defined, their ordering
` constraints relative to the above listed headers must be specified.
`
` IPv6 nodes must accept and attempt to process extension headers in
` any order and occurring any number of times in the same packet,
` except for the Hop-by-Hop Options header which is restricted to
` appear immediately after an IPv6 header only. Nonetheless, it is
` strongly advised that sources of IPv6 packets adhere to the above
` recommended order until and unless subsequent specifications revise
` that recommendation.
`
`Deering & Hinden Standards Track [Page 8]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 8 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
`4.2 Options
`
` Two of the currently-defined extension headers -- the Hop-by-Hop
` Options header and the Destination Options header -- 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 sequence of options within a header must be processed strictly in
` the order they appear in the header; a receiver must not, for
` example, scan through the header looking for a particular kind of
` option and process that option prior to processing all preceding
` ones.
`
` 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, regardless of whether or not the
` packet’s Destination Address was a multicast address, send an
` ICMP Parameter Problem, Code 2, 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 was not a multicast address, send an ICMP Parameter
` Problem, Code 2, message to the packet’s Source Address,
` pointing to the unrecognized Option Type.
`
` The third-highest-order bit of the Option Type specifies whether or
` not the Option Data of that option can change en-route to the
` packet’s final destination. When an Authentication header is present
`
`Deering & Hinden Standards Track [Page 9]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 9 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` in the packet, for any option whose data may change en-route, its
` entire Option Data field must be treated as zero-valued octets when
` computing or verifying the packet’s authenticating value.
`
` 0 - Option Data does not change en-route
`
` 1 - Option Data may change en-route
`
` The three high-order bits described above are to be treated as part
` of the Option Type, not independent of the Option Type. That is, a
` particular option is identified by a full 8-bit Option Type, not just
` the low-order 5 bits of an Option Type.
`
` The same Option Type numbering space is used for both the Hop-by-Hop
` Options header and the Destination Options header. However, the
` specification of a particular option may restrict its use to only one
` of those two headers.
`
` 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.
`
`Deering & Hinden Standards Track [Page 10]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 10 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` 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 B contains formatting guidelines for designing new options.
`
`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-1700 et seq.].
`
` 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 defined in this document are the Pad1 and
` PadN options specified in section 4.2.
`
`Deering & Hinden Standards Track [Page 11]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 11 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
`4.4 Routing Header
`
` The Routing header is used by an IPv6 source to list one or more
` intermediate nodes to be "visited" on the way to a packet’s
` destination. This function is very similar to IPv4’s Loose Source
` and Record Route option. The Routing header is identified by a Next
` Header value of 43 in the immediately preceding header, and has the
` following format:
`
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Next Header | Hdr Ext Len | Routing Type | Segments Left |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` . .
` . 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-1700 et seq.].
`
` Hdr Ext Len 8-bit unsigned integer. Length of the Routing
` header in 8-octet units, not including the first
` 8 octets.
`
` Routing Type 8-bit identifier of a particular Routing header
` variant.
`
` Segments Left 8-bit unsigned integer. Number of route
` segments remaining, i.e., number of explicitly
` listed intermediate nodes still to be visited
` before reaching the final destination.
`
` 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, while processing a received packet, a node encounters a Routing
` header with an unrecognized Routing Type value, the required behavior
` of the node depends on the value of the Segments Left field, as
` follows:
`
`Deering & Hinden Standards Track [Page 12]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 12 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` If Segments Left is zero, the node must ignore the Routing header
` and proceed to process the next header in the packet, whose type
` is identified by the Next Header field in the Routing header.
`
` If Segments Left is non-zero, the node must discard the packet and
` send an ICMP Parameter Problem, Code 0, message to the packet’s
` Source Address, pointing to the unrecognized Routing Type.
`
` If, after processing a Routing header of a received packet, an
` intermediate node determines that the packet is to be forwarded onto
` a link whose link MTU is less than the size of the packet, the node
` must discard the packet and send an ICMP Packet Too Big message to
` the packet’s Source Address.
`
`Deering & Hinden Standards Track [Page 13]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 13 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` The Type 0 Routing header has the following format:
`
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Next Header | Hdr Ext Len | Routing Type=0| Segments Left |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Reserved |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` + +
` | |
` + Address[1] +
` | |
` + +
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` + +
` | |
` + Address[2] +
` | |
` + +
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` . . .
` . . .
` . . .
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | |
` + +
` | |
` + Address[n] +
` | |
` + +
` | |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` 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-1700 et seq.].
`
` Hdr Ext Len 8-bit unsigned integer. Length of the Routing
` header in 8-octet units, not including the first
` 8 octets. For the Type 0 Routing header, Hdr
` Ext Len is equal to two times the number of
` addresses in the header.
`
` Routing Type 0.
`
`Deering & Hinden Standards Track [Page 14]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 14 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` Segments Left 8-bit unsigned integer. Number of route
` segments remaining, i.e., number of explicitly
` listed intermediate nodes still to be visited
` before reaching the final destination.
`
` Reserved 32-bit reserved field. Initialized to zero for
` transmission; ignored on reception.
`
` Address[1..n] Vector of 128-bit addresses, numbered 1 to n.
`
` 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.
`
` 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 header module to be invoked,
` which, in the case of Routing Type 0, performs the following
` algorithm:
`
`Deering & Hinden Standards Track [Page 15]
`
`CODE200 ET AL. EXHIBIT 1022
`Page 15 of 39
`
`

`

`
`RFC 2460 IPv6 Specification December 1998
`
` if Segments Left = 0 {
` proceed to process the next header in the packet, whose type is
` identified by the Next Header field in the Routing header
` }
` else if Hdr Ext Len is odd {
` send an ICMP Parameter Problem, Code 0, message to the Sou