Network Working Group
`Request for Commen ts: 24 60
`Obsoletes: 1883
`Category: Standards Track
`
`S . Deering
`Cisco
`R . Hinden
`No kia
`Dec ember 1998
`
`Intern et Protocol, Ve r sio n 6 (IPv6 )
`Specification
`
`Status of t h is Memo
`
`This document specifies an Intern et s t andar ds track pro t ocol f o r
`Internet commun ity, and requests discussio n and suggestio ns for
`improvements.
`Please refer to t h e c u rrent edition of the "I nternet
`Official Protoco l Standards" (STD 1) for t h e stan da r dization sta te
`and statu s of t h is protocol. Distribution of this memo is u n limite d .
`
`t he
`
`Copyright No tice
`
`Copyrig h t
`
`(C) Th e Internet Soci ety (19 98). All Rights Res erved.
`
`Abstract
`
`This documen t speci fies ver s i o n 6 o f the I nte r net Pr otoco l
`also sometimes referred to as IP Next Gener ation or I Png .
`
`(IPv6 ),
`
`Tabl e of Con tents
`
`1 . Int r oduction .................................................. 2
`2. Te rminology ................................................... 3
`3 . IPv 6 Heade r Format ............................................ 4
`4 . IPv6 Exte n s i o n Head ers ........................................ 6
`4.1 Extensio n Head er Order ................................... 7
`4 . 2 Options .................................................. 9
`4.3 Hop-b y-Hop Option s Header ... . ..... . ..... . ............... 11
`4. 4 Routing Hea de r .......................................... 12
`4. 5 Fragment He ade r ......................................... 1 8
`4. 6 Dest i nation Optio ns Header .............................. 2 3
`4 . 7 No Next Header .......................................... 2 4
`5. Packet Size Issu es ........................................... 24
`6 . Flow Labe ls .................................................. 25
`7. Traffic Clas ses .............................................. 2 5
`8. Uppe r - Laye r Pr o t oc o l Issues .................................. 2 7
`8 .1 Upper-La ye r Check sums ... . ..... . ..... . ..... . ..... . ..... . . 2 7
`8 . 2 Ma ximum Packet Lifetime ................................. 2 8
`8.3 Maximum Upp er-Lay er Pa y l o ad Size ........................ 2 8
`8 .4 Responding to Packets Carr yi n g Routi n g Headers .......... 2 9
`
`Deer i n g & Hinde n
`
`Standards T r ack
`
`[Pa ge 1]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 1 of 39
`
`

`

`RFC 2460
`
`IPv6 Specification
`
`Dec ember 1 99 8
`
`Appendix A. Semantics and Usage of t h e Flow La bel Field ....... . . 30
`Appendix B. Formatting Gu idelin es fo r Options ................... 3 2
`Security Considerations ......................................... 35
`Acknowledgments ................................................. 35
`Authors' Add r esses .............................................. 3 5
`References ...................................................... 35
`Changes Since RFC-1883 .......................................... 3 6
`Ful l Copyright Statement ........................................ 39
`
`1.
`
`I n troduction
`
`IP version 6 (IPv6) is a new version of the Inter net Pr otoc ol,
`designed as the successo r to IP v ersion 4 (I Pv 4)
`[RFC-791]. The
`changes from IPv4 to IPv6 fall primar ily i nto the f o llowing
`catego r ies:
`
`o Expanded Addr e s sing Capabilities
`
`IPv6 increases the IP address si z e fr om 32 bits to 12 8 b it s ,
`support more levels of addressing hie rarchy , a mu ch g r e ate r
`number of addressable nodes , a n d simpler a uto -con figura t i o n o f
`addresses. The scalability of mu lticast routing is imp roved by
`addi ng a "scope" fi e ld to mul t i cast addr e sses. And a n ew t ype
`of add r es s c alle d an "anycas t addr e ss " is def ined, used to send
`a packet to any one of a gro up of nodes.
`
`t o
`
`o Header Fo r mat Si mplifi cat i on
`
`Some IPv4 he ade r fi e lds h ave b een droppe d or made optional, to
`r educe t h e commo n-c ase p r ocessing cos t of p a cket hand ling and
`to limit the bandwidth cost of t he I Pv6 header.
`
`o
`
`Improve d Support for Exte nsions and Options
`
`Cha nge s in t h e way IP hea de r o p t i o n s are encoded allows fo r
`more efficien t forwarding, less str i n gent limits on the length
`o f opt i on s, a nd g re a ter flexib i l i ty for i n t roducing new options
`in the f ut ure.
`
`o Flow Labe ling Cap a bility
`
`A new capabilit y is added t o e n able the lab eling of pac ke ts
`belonging t o particular traffic "flo ws" f or which the sen der
`r e quest s s pec ial hand l ing, s uch as n on -default q ual i ty of
`serv ice o r " r eal-time" serv ice.
`
`De e r i n g & Hinde n
`
`Standard s Tr ack
`
`[Pa ge 2 ]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`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(cid:173)
`defined IPv6 extension headers and options. It also discusses packet
`size issues, the semantics of flow labels and traffic c l asses, 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 implemen t ations are required
`to include, is specified in [ICMPv6].
`
`2. Terminology
`
`node
`
`- a device that implements IPv6.
`
`router
`
`- a node that forwards IPv6 pac kets not explicitly
`addressed to itself.
`[See No t e below].
`
`host
`
`- any node that is not a router.
`
`[See Note below].
`
`upper
`
`l ayer
`
`link
`
`l ayer immedi atel y abo ve I Pv6. Examples a r e
`- a protocol
`transport pro t ocols such as TCP and UDP, control
`protocols such as ICMP, routing pro t ocols such as OSPF,
`and internet or lower-layer protocols being "tunneled"
`over (i.e., encapsulated i n) I Pv6 such as IPX,
`AppleTalk, or IPv6 itself.
`
`- a communication facility or medium over which nodes can
`c ommunicate at the link layer, i.e., the layer
`immediately below IPv6. Examples are Ethernets (simple
`or bridge d); PPP links; X.25, Frame Relay, or ATM
`n etwo rks; and internet (o r higher) l ayer "tunne l s",
`such as tunnels over IPv4 or IPv6 i t self.
`
`neighbors
`
`- nodes attached to the same link.
`
`interface
`
`- a node's attachment t o a link.
`
`address
`
`- an IPv6-layer identifier for a n interface or a set of
`interfaces.
`
`packet
`
`- an IPv6 header p l us payl o ad .
`
`link MTU
`
`-
`
`the maximum transmission unit, i.e., maximum packet
`size in octets, t hat can be conveyed over a lin k.
`
`Dee ring & Hinden
`
`Stand ards Track
`
`[Page 3]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 3 of 39
`
`

`

`RFC 2460
`
`IPv6 Specification
`
`December 1998
`
`path MTU
`
`-
`
`the minimum link MTU of all the lin ks in a path between
`a source node and a des t ination 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 in t erfaces, and to
`discard non-self-destined packets arriving from i t s other interfaces.
`Such a device must obey the protocol r equir ements for r outers when
`receiving packets from, and interacting with neighbors over, the
`former (forwarding) interfaces. It must obey the protocol
`requirements for hosts when receiving packe t s from, and interacting
`with neighbors over, the latter (non-forwarding) interfaces.
`
`3.
`
`IPv6 Header Format
`
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`IVersionl Traffic Class I
`Flow Label
`I
`+- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +
`I Next Header
`I
`Payload Length
`I
`Hop Limit
`I
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`+
`
`+
`
`+
`
`Source Address
`
`+
`
`+
`
`+
`
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`+
`
`+
`
`+
`
`I
`
`+
`I
`+
`+
`I
`I
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`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.
`
`Payl oad Length
`
`16-b i t uns igned intege r . Length of the I Pv 6
`payload, i.e., the rest of the pac ket following
`this IPv6 header, in octets.
`(Note that any
`
`Dee r ing & Hinden
`
`Standards T rac k
`
`[Page 4]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 4 of 39
`
`

`

`RFC 2460
`
`IPv6 Specification
`
`December 1998
`
`Next Header
`
`Hop Limit
`
`extension headers [sec t ion 4] present are
`considered part of the payload, i.e., included
`in the length count.)
`
`Identifies the type of header
`8-bit selector.
`immediately following t he IPv6 header. Uses the
`same values as the IPv4 Protocol field [RFC-1700
`et seq.].
`
`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 o f the packe t .
`See [ADDRARCH].
`
`Destination Address 128 - bit address of the intended recipien t of the
`packet (possibly not the ultimate recipient, if
`a Routing header is present). See [ADDRARCH]
`and section 4.4.
`
`Dee r i n g & Hinden
`
`Standards Trac k
`
`[Page 5]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`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 t he upper(cid:173)
`layer header in a packet. There are a small number of such extension
`headers, each identified by a distinc t Next Header value. As
`illustrated in these examples, an IPv6 packet may carry zero, one, or
`more extension headers, each identified by the Next Heade r field of
`the preceding header:
`
`+---------------+------------------------
`IPv6 header
`TCP header+ data
`
`Next Header =
`TCP
`+---------------+------------------------
`
`+---------------+----------------+------------------------
`IPv6 header
`Routing header
`TCP header+ data
`
`Next Header =
`Next Header =
`Rout ing
`TCP
`+---------------+----------------+------------------------
`
`+---------------+----------------+-----------------+-----------------
`IPv6 header
`Routing header
`Fragment header
`fragment of TCP
`header+ data
`
`Next Header=
`Next Header=
`Next Header=
`TC P
`Fragment
`Routing
`+---------------+----------------+-----------------+-----------------
`
`Wi th one except i on, extens ion h eaders a r e 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 t h e 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 presen t . The
`contents and semantics of each extension header determine whether or
`not to proceed to the next header. Therefore, ext ension headers must
`be processed strictly in the order they appear in the packet; a
`r eceive r must not, fo r example, scan through a packet l ooking f or a
`particular kind of extension header and process that header prior to
`processing all preceding ones.
`
`Dee r ing & Hinden
`
`Standards T rack
`
`[Page 6 ]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 6 of 39
`
`

`

`RFC 2460
`
`IPv6 Specification
`
`December 1998
`
`The exception referred to in t h e preceding paragraph is the Hop-by(cid:173)
`Hop Options header, which carries information tha t must be examined
`and processed by every node along a packet's delivery path, including
`the source and destination nodes. Th e Hop-by-Hop Options header,
`when present, must immediately follow the I Pv6 header.
`Its presence
`is indicated by the value zero in the Next Hea der field of t h e IPv6
`header.
`
`If, as a result of processing a h eader, a node is required to proceed
`to the next header but t h e Next Header value in the cur rent h eader is
`unrecognized by the node, it s h ould discard the packet and send an
`ICMP Parameter Problem message to the source of the pac ket, with an
`I CMP Code value of 1 ("unrecognized Next Header t ype encountered")
`and the ICMP Pointer field containing the offset of the unrecognized
`value within the original packet. Th e same action should be t aken i f
`a node encounters a Next Header value of zero in any header o t her
`than an IPv6 header .
`
`Each extension header is an integer multiple of 8 octets long, in
`order to retain 8-octet alignment for subsequ ent headers. Multi(cid:173)
`octet fields within each extensio n header are aligned on their
`natural boundaries, i.e., fields of width n octets are placed at an
`i ntege r mul t i p l e o f n octets fr om the star t o f
`t h e header, f o r n = 1 ,
`2, 4, or 8.
`
`A full implementation of IPv6 includes implementa t ion of the
`fol l owi ng exten s i o n h eade r s:
`
`Hop-by-Hop Options
`Routing (Type 0)
`Fragment
`Destination Options
`Authe ntication
`Encapsul at i ng Securi ty Payl oad
`
`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 t h e same packe t , it is
`recommended that t h ose headers appear in t h e following order:
`
`IPv6 header
`Hop-by-Hop Options header
`Destination Options header (n ote 1)
`Ro uting he a de r
`Fra gment he a der
`
`De e r i n g & Hinden
`
`Sta ndards Trac k
`
`[Page 7]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 7 of 39
`
`

`

`RFC 2460
`
`IPv6 Specification
`
`December 1998
`
`Authentication header (note 2)
`Encapsulating Security Payload header (no t e 2)
`Destination Options header (note 3)
`upper-layer header
`
`note 1: for options to be processed by t h e firs t destina tion
`that appears in the I Pv6 Destination Address field
`plus subsequen t dest i nati ons listed in the Rout i ng
`header.
`
`note 2: additional recommenda t ions regarding t h e rela t ive
`order of the Authentication and Encapsulating
`Security Payload headers are given in [RFC-2406].
`
`note 3: for options to be processed only by the f inal
`destination of the packet.
`
`Each extension header should occur at most once, except fo r 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
`bei ng tun nel ed over o r e n capsul ated in IPv6), i t may be foll owed by
`i t s own ext ension h eaders, which are separa t ely subject to the same
`ordering recommendations.
`
`I f and when other extens i on heade r s a r e def ined, the ir orderi ng
`constraints r elative to the above lis t ed headers must be s p eci f ied.
`
`IPv6 nodes must accept and attempt to p r ocess extension headers in
`any order and occurring any number of times in the same p a cke t ,
`except for the Hop-by-Hop Options header wh ich is rest r icted to
`appe ar imme diate ly afte r an IPv6 h e ade r only. None the l e ss, i t is
`str ongl y advi sed t h at sou r ces of IPv6 packe t s adh e r e to the above
`recommended order until and unless subsequent specifica t i o ns revise
`that recommendation.
`
`De e r i n g & Hinden
`
`Stand ards Trac k
`
`[Page 8]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`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 Op t ions header -- carry a variable
`number of type-length-value (TLV) encoded "options", of the following
`format:
`
`-
`-
`-
`-
`-
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -
`Opt Data Len I Option Data
`Option Type
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
`
`Option Type
`
`8-bit identifier of the type of option.
`
`Opt Data Len
`
`Option Data
`
`8-bit unsigned integer. Length of the Option
`Data field of this option, in octets.
`
`Variable-length field. Option-Type-specific
`data.
`
`The sequence of options within a header mus t 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
`opt i on a nd p r ocess that opt i on prior t o processing all preceding
`ones.
`
`The Option Type identifiers are internally encoded such that their
`highest-order two b i ts speci fy the ac tion that must be t aken if the
`processing IPv6 node does not recognize the Option Type:
`
`00 - skip over this option and con t inue processing the header.
`
`01 - discard the packet.
`
`10 - d i sca r d the packet and, regardless of whe the r o r 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 unr ecognized Op tion Type.
`
`11 - discard the packet and, only if the packe t '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-o r der b i t of the Op tion Type specifies whethe r o r
`not the Option Data of that option can change en-route to the
`packet's final destination. When an Authentication header is present
`
`Dee ring & Hinden
`
`Standards Track
`
`[Page 9]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`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 trea t ed 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 Op t ions header. However,
`t he
`specification of a particular option may restrict its use to only one
`of those two headers.
`
`Individual options may have specific alignment requirements, t o
`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 t he Op t ion Type must
`appear at an intege r multiple of x octets from t h e start o f the
`header, plus y octets. For example:
`
`means any 2-octet offset from the start of the header.
`2n
`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 mu ltiple
`of 8 octets in length. These padding options mus t be recognized by
`all IPv6 impl ementations:
`
`Padl o ption
`
`(alignment requirement: none)
`
`+-+-+-+-+-+-+-+-+
`o
`I
`I
`+-+-+-+-+-+-+-+-+
`
`NOTE! the format of the Padl option is a special case -- it does
`not have length and value fields.
`
`The Padl option is used to ins e r t on e oc t et of padding into the
`Options a r ea of a header.
`I f more than on e octet of padding is
`required, the PadN option, described next , should be used, rather
`than multiple Padl options.
`
`Dee ring & Hinden
`
`Standards Track
`
`[Page 10]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 10 of 39
`
`

`

`RFC 2460
`
`IPv6 Specification
`
`December 1998
`
`PadN option
`
`(alignment requirement: none)
`
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
`I Option Data
`!
`Opt Data Len
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
`
`The PadN option is used to insert t wo or more octets of padding
`i nto the Opt i ons area of a h eader. For N octe t s 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 op t ional information
`that must be examined by every node along a packe t '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 forma t :
`
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`I
`I
`I Next Header
`I Hdr Ext Len
`+
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`Options
`
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`Next Header
`
`Hdr Ext Len
`
`Options
`
`Identifies t he type of header
`8-bit selector.
`immediately following the Hop-by-Hop Options
`h e ade r. Uses the same values as the IPv4
`Protocol fi e l d
`[RFC-1700 et seq.].
`
`8-bit unsigned integer. Length of the Hop-by(cid:173)
`Hop Option s header in 8-octe t units, not
`including the first 8 octets.
`
`Variable-l ength field, of length such that the
`complete Hop-by-Hop Options heade r is a n integer
`multiple of 8 oc t ets long. Contains one or more
`TLV-encoded options, as described in sec t ion
`4. 2 .
`
`The only hop- by- hop options defined in this d o cument are the Padl and
`PadN o ptio ns s pec ified in section 4.2.
`
`Dee r i n g & Hinden
`
`Standards Trac k
`
`[Page 11]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`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 h eader, and h as the
`fol l owi ng fo r mat:
`
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`I
`I Segments Lef t
`Next Header
`Hdr Ext Len
`Routing Type
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`I
`
`type-speci f ic data
`
`+- +- + - +- +- + - +- +- + - +- +- + - +- +- + - +- +- + - +- +- + - +- +- + - +- +- + - +- +- + - +- +- +
`
`Next Header
`
`Hdr Ext Len
`
`Routing Type
`
`Segments Left
`
`type-specific data
`
`Identifies t he type of header
`8-bit selector.
`immediately following the Routing header. Uses
`the same values as the IPv4 Protocol field
`[RFC- 1 700 et seq.].
`
`8-bit unsigned intege r . Length of the Routing
`header in 8-octe t units, not including the fi rs t
`8 octets.
`
`8-bit iden tifier of a particula r Routing h e ade r
`variant.
`
`8-bit unsigned intege r . Number of route
`s e gme nt s r emaining, i. e ., numbe r of e xplicitly
`listed intermedi ate nodes st i l l to be v i s i ted
`before reaching the final destination.
`
`Vari a ble-len gth field, of fo r ma t determined by
`the Routing Type, a nd of length s u ch tha t the
`complete Routing header is an integer multiple
`o f 8 octets l o ng.
`
`If, while processing a received packe t , a node encounters a Rou ting
`header with an unrecognized Routing Type value, the required b ehavior
`of the node depends on t h e v alu e of the Segments Left fi e l d , as
`follows:
`
`De e r ing & Hinden
`
`Standards T r ack
`
`[Page 1 2 ]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 12 of 39
`
`

`

`RFC 2460
`
`IPv6 Specification
`
`December 1998
`
`If Segments Left is zero, t h e 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 pac ket's
`Source Address, pointing to the unrecognized Routing Type.
`
`If, after processing a Routing header of a received pac ket, an
`intermediate node determines t h at the packe t is to be forwarded onto
`a link whose link MTU is less than the size of t h e packet, t he node
`must discard the packet and send an ICMP Packet Too Big message to
`the packet's Source Address.
`
`De e r ing & Hinden
`
`Stand ards Trac k
`
`[Page 13]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 13 of 39
`
`

`

`RFC 2460
`
`IPv6 Specification
`
`Dec ember 1 99 8
`
`The Type O Routing header h as the following forma t :
`
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`Next Header
`Hdr Ext Len
`I Routing Type=OI Segments Left
`I
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`Rese rved
`+- +-+-+- +-+- +- +-+-+- +-+-+- +-+-+- +-+- +- +-+-+- +-+- +- +-+- +- +-+- +- +-+
`
`+
`I
`+
`
`Address[l]
`
`+
`
`+
`
`+
`+
`I
`I
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+
`
`+
`I
`+
`
`Address[ 2 ]
`
`+
`I
`+
`
`+
`+
`I
`I
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`+
`I
`+
`
`Address[n]
`
`+
`I
`+
`
`+
`+
`I
`I
`+-+-+ - +- +- +-+-+-+-+-+-+-+- +-+ - +- +- +-+-+-+-+-+-+-+- +-+ - +- +- + - +-+-+
`
`Next He a der
`
`Hdr Ext Len
`
`Iden tifies the typ e o f header
`8-bi t selector .
`immediatel y following t h e Routing heade r. Uses
`the same values as t he IPv4 Pr o t ocol fi e ld
`[RFC-1700 et seq.].
`
`8-bi t unsi gn e d integer. Length o f the Rou ting
`header in 8-o cte t units, no t inclu ding the fi r st
`8 o c tet s .
`Fo r
`t h e Type O Rout i ng h e ade r , Hdr
`Ext Len is equal t o t wo times the n umbe r of
`addr esses i n the heade r .
`
`Routing Type
`
`0.
`
`De e r i n g & Hi nde n
`
`Standard s Tr ack
`
`[Page 14]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`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 t he final destination.
`
`Reserved
`
`Initialized to zero for
`32-bit reserved field.
`transmission; ignored on reception.
`
`Address[l .. n]
`
`Vector of 128-bit addresses, numbered 1 ton.
`
`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.
`I n 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:
`
`Dee ring & Hinden
`
`Standards Track
`
`[Page 15]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`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 Source
`Address, pointing to the Hdr Ext Len field, and discard the
`packet
`
`else
`compute n, the number of addresses in the Routing header, by
`dividing Hdr Ext Len by 2
`
`if Segments Left is greater than n {
`send an ICMP Parameter Problem, Code 0, message to the Source
`Address, pointing to the Segmen t s Lef t field, and discard the
`packet
`
`else {
`decrement Segments Left by 1;
`compute i, t h e index of the next address to be visited in
`the address vector, by subtracting Segments Left from n
`
`if Address [i] or the IPv6 Destination Address is multicas t
`discard the packet
`
`e l se {
`swap the IPv6 Destination Address and Address[i]
`
`if the IPv6 Hop Limit is less than or equal to 1
`send an ICMP Time Exceeded -- Hop Limit Exceeded in
`Transit message to the Source Address and discard the
`packe t
`
`else {
`decrement the Hop Limit by 1
`
`resubmit the packet to the IPv6 module for t ransmission
`to the new destination
`
`Dee r ing & Hinden
`
`Standards Trac k
`
`[Page 1 6]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 16 of 39
`
`

`

`RFC 2460
`
`IPv6 Specification
`
`December 1998
`
`As an example of t h e effects of the above algorithm, consider the
`case of a source node S sending a pac ket to destination node D, using
`a Routing header to cause the packet t o be routed via intermediate
`nodes Il, I2, and I3. The values of t he relevant IPv6 header and
`Routing header fields on each segment of the delivery path would be
`as follows:
`
`As the packet trave l s from S to I l :
`
`Source Address= S
`Destination Address
`
`I1
`
`As the packet travels from Il to I2:
`
`Source Address = S
`Destination Address
`
`I2
`
`As the packet travels from I2 t o I3:
`
`Source Address= S
`Dest i nat i on Address
`
`I3
`
`As the packet travels from I3 to D:
`
`Source Address= S
`Destination Address
`
`D
`
`Hdr Ext Len= 6
`Segments Left= 3
`Address [1]
`I2
`Address [ 2]
`I3
`Address[3]
`D
`
`Hdr Ext Len = 6
`Segments Left= 2
`Address [ 1 l
`I1
`Address[2]
`I3
`Address[3]
`D
`
`Hdr Ext Len= 6
`Segments Left= 1
`Address [ 1]
`I1
`Address[2]
`I2
`Address[3]
`D
`
`Hdr Ext Len= 6
`Segments Left = 0
`Address[l]
`I1
`Address[2]
`I2
`Address [3]
`I3
`
`Dee ring & Hinden
`
`Stand ards Track
`
`[Page 17]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 17 of 39
`
`

`

`RFC 2460
`
`IPv6 Specification
`
`December 1998
`
`4.5 Fragment Header
`
`The Fragment header is used by an IPv6 source to send a packet larger
`than would fit in the path MTU to its destination.
`(No t e: unlike
`IPv4, fragmentation in IPv6 is performed only by source nodes, not by
`routers along a packet's delivery path -- see sec t ion 5.) The
`Fragment header is identified by a Next Header value of 44 in the
`i mmediate l y p r eceding heade r , and has the fol l owing format:
`
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`Next Header
`Reserved
`Fragment Offset
`IReslMI
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`I
`Identification
`I
`+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`Next Header
`
`Identifies the initial header
`8-bit selector.
`type of the Fragmentable Par t of the original
`packet (defined below). Uses the same values as
`the IPv4 Protocol field [RFC-1700 et seq.].
`
`Reserved
`
`Initialized to zero for
`8-bit reserved field.
`transmission; ignored on reception.
`
`Fragment Offset
`
`13-bit unsigned integer. The offset, in 8-octet
`units, of the data following this header,
`relative to the start of the Fragmentable Part
`of the original packet.
`
`Res
`
`Initialized to zero for
`2-bit r e served field.
`transmission; ignored on reception.
`
`M flag
`
`1 = more fragments; 0 = last fragment.
`
`Identification
`
`32 b i ts. See descript i on be l ow.
`
`In order to send a packet that is too large to fit in the MTU of the
`path to its destination, a source node may divide the packet i n to
`fragments and send each fragment as a separate packet, t o be
`reassembled at the receiver.
`
`For every packet that is to be fragmented, the source node generates
`an Identification value. The Identification must be different than
`that of any other fragmented packet sent recently* with the same
`Source Addr ess and Destination Address.
`If a Rou ting header is
`present, the Destination Address of concern is that of the final
`destination.
`
`Dee r ing & Hinden
`
`Standards Track
`
`[Page 18]
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 18 of 39
`
`

`

`RFC 2460
`
`IPv6 Specification
`
`Dec ember 1 99 8
`
`* " r ecently" means within t h e maximum li kely lifetime of a p acke t ,
`including tran sit time from sour ce to desti n ation and time spent
`awaiting reassembly with oth er fragme nts o f the s ame pac ket.
`However, it is n ot r equired that a sou rce node know the maximum
`packet lifetime. Rath er, it is assumed that the r equirement can
`be met by maintainin g the Ide ntification val ue as a simple, 32-
`bit, "wrap-aroun d" cou nter, incremented each time a packet mus t
`be fra gmen ted.
`I t
`i s an i mpl e menta t i on c ho i ce wh e the r to
`main tain a sin gle coun ter for t h e node or mu ltiple c o unt e rs,
`e.g., one for each of the node's p o ssible source addr ess e s, or
`one for each active (source addr ess, destina t ion addr ess )
`combination.
`
`The initial, large, u nfragmented packet is refer r ed to as the
`"original packet", a n d it is conside r ed to consis t of two parts, as
`illustrated:
`
`original packet:
`
`+------------------+----------------------!!-----------------------+
`I Unfr agmentable
`Fra gmenta ble
`I
`I
`Part
`Pa r t
`I
`I
`I
`+------------------+---------------------- // -----------------------+
`
`The Un f r agmentable Par t consists of the IPv 6 h eader p lus any
`extension header s that must be processed by no des e n route to t he
`dest ination ,
`t h at i s, al l h eader