`
`
`Network Working Group
`
`
`
`Request for Comments:
`Obsoletes: 1883
`
`
`
`
`Category: Standards Track
`
`2460
`
`
`
`
`
`
`
`S. Deering
`Cisco
`
`R. Hinden
`
`
`Nokia
`
`December 1998
`
`
`
` Internet Protocol, Version 6
`
`
`
`
`Specification
`
`
`
`
`(IPv6)
`
`
`
`Status of this Memo
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`This decument specifies an Internet standards track protocol for the
`
`
`
`
`
`
`
`
`Tnternet community,
`and requests discussion and suggestions for
`to the current edition of the "Internet
`
`
`
`
`
`
`
`
`
`
`
`improvements.
`Please refer
`Official Protocol Standards"
`
`
`
`
`
`
`
`
`
`(STD 1)
`for the standardization state
`Distribution of this memo is unlimited.
`
`
`
`
`
`
`
`
`
`
`and status of this protocol.
`
`
`
`
`
`
`Copyright Notice
`
`
`
`
`Copyright
`
`
`
`
`
`
`
`
`(C) The Internet Society (1998). All Rights Reserved.
`
`
`
`Abstract
`
`
`
`
`
`
`
`
`
`
`
`
`This document specifies version 6 of the Internet Protocol
`
`
`
`
`
`
`
`
`
`
`
`also sometimes referred to as IP Next Generation or IPng.
`
`(TPv6),
`
`
`
`Table of Contents
`
`
`
`
`
`TL. Introduction. ccc cc ee eee eee eee eee ees 2
`
`
`
`
`
`
`Ze TSrmine logy « 22.2 ys ee oe Ee EES GLE 22 ES ESS RRL 2 ee eS Ree 2 ee 3
`3. TRVG Header Porta towware =
`2 ss Gs SRS So 2 ES GS ORES! So EE eG & See =o 4
`5
`
`
`
`
`
`
`A. TPO ExXtensPOn Headers... se. vas eee ee ee ee ee ee ee eee ee oe 6
`
`
`
`
`
`4.1, Extenstzon: Header Order. «
`a we ow 7
` wmceer cee eae wr eee 8
`
`
`
`
`
`
`
`
`4.2 OPCIONS.. ccc eee ee ee ee eee ee eee eee eee enn eens 9
`
`
`
`
`
`4.3 Hop-by-Hop Options Header... cccee 11
`
`
`
`
`4 oA, Routing HeaGe racers s vv go eS SQUIRE & EE GY YS OURS EEE eB YS BEE ee 12
`
`
`
`
`4.5 PRAGMETE: H6ddehyewe 224 vx x ee Be x eX REE Be ee x aS eee Ze 18
`
`
`
`
`
`4.6 Destination Options Header...es 23
`4A.P N@ M@zE AGRGGT ces: o ae ee om eee: woo ot em fo
`fe ECE: of et em De Hee oo 24
`
`
`
`
`
`5. Packet Size ISSUES... ee ee ee eee 24
`
`
`
`
`
`6. Flow Labels... .le eee 25
`
`
`
`
`‘he TEaific Classess gs seuwae =o 2 ss 6% SSI So 2 SG & ORS Eo ES eG & OE ee 25
`
`
`
`
`
`
`
`
`
`
`&. Uppér-Layer ProtvteGol TPSSUES),
`5 sees 6 eos eae Be Ee ee eae BEER © 27
`
`
`
`
`
`Bul, UPPEE “Layer GHECKSUMSs ow x munwemeomn eon ne we ROOM an ee we ORR A 27
`8.2 Maximum Packet Lifetime... . ee et ee ees 28
`
`
`
`
`
`
`
`
`
`
`
`8.3 Maximum Upper-Layer Payload Size... ce ee 28
`
`
`
`
`
`
`
`
`8.4 Responding to Packets Carrying Routing Headers.......... 29
`
`
`
`
`
`Deering & Hinden
`
`
`
`Standards Track
`
`
`
`
`[Page 1]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page 1 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 1 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 Specification
`
`
`
`
`December 1998
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Appendix A. Semantics and Usage of the Flow Label Field......... 30
`
`
`
`
`
`
`
`Appendix B. Formatting Guidelines for OptClonS..... eee eee eee 32
`
`
`
`Security Considerations... cee ee eee eee eee eee ees 35
`
`
`Acknowledgment 2... cccee 36
`Authors’ AddrESSES.. 1. eee ee eee eee eens 35
`
`
`
`RETErEGNGGSeacee ©
`2 oy 3 Ge RORSIDTE!
`2 Be FG @ ORES 2 Be 2 Go REREAD eGo RR 2 35
`2
`
`
`
`
`
`
`GhANGEeS SanGe RECHLGS Gace «= ee ek a PURO Ee ee Gu A ROE oe eS eS BREE oe 36
`
`
`
`
`Pill, COBYELONE SPaPSMST Came:
`o soo eee mcm oe ww ee RU oe ee OU 39
`
`1.
`
`
`
`Introduction
`
`
`
` TP 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
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`TPv6 increases the IP address size from 32 bits to 128 bits,
`
`
`
`
`
`
`
`
`
`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.
`
`
`
`
`ta
`
`
`
`
`
`
`
`
`o Header Format Simplification
`
`
`
`
`
`
`
`
`
`
`
`
`
`to
`Some IPv4 header fields have been dropped or made opticnal,
`
`
`
`
`
`
`
`
`
`reduce the common-case processing cost of packet handling and
`to limit the bandwidth cost of the IPv6 header.
`
`
`
`
`
`
`
`
`
`
`
`
`
`co
`
`
`
`
`
`
`
`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]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page 2 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 2 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 Specification
`
`
`
`
`December 1998
`
`
`
`
`
`
`
`o Authentication and Privacy Capabilities
`
`
`
`
`
`
`
`
`
`Extensions to support authentication, data integrity, and
`
`
`
`
`
`
`
`(optional) data confidentiality are specified for IPw6.
`
`
`
`
`
`
`
`
`
`
`
`
`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 ITPv6 on upper-layer protocols.
`The format and
`
`
`
`
`
`
`
`
`
`semantics of IPvé addresses are specified separately in [ADDRARCH].
`
`
`
`
`
`
`
`
`
`
`The IPv6 version of ICMP, which all IPv6 implementations are required
`
`
`
`
`
`
`to include,
`is specified in [ICMPv6].
`
`
`
`
`
`
`
`Terminology
`
`
`
`node
`
`
`
`router
`
`
`
`
`
`
`
`- a device that implements IPv6.
`
`
`
`
`
`
`
`
`
`
`
`
`- 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].
`
`
`
`
`
`
`
`
`
`
`
`
`
`Examples are
`upper layer - a protocol layer immediately above IPv6.
`
`
`
`
`
`
`
`
`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.6., encapsulated in)
`IPv6é such as IPX,
`
`
`
`
`AppleTalk, or IPv6é itself.
`
`
`
`Link
`
`
`
`neighbors
`
`interface
`
`
`
`
`
`address
`
`
`
`
`
`
`
`
`
`
`
`- 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, cr ATM
`
`
`
`
`
`
`networks; and internet
`(or higher)
`layer "tunnels",
`such as tunnels over IPv4 or IPv6 itself.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`- nodes attached te the same link,
`
`
`
`- a node’s attachment to a Link.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`- an IPv6-layer identifier for an interface or a set of
`interfaces.
`
`
`
`
`packet
`
`
`
`
`
`
`
`- an IPv6 header plus payload.
`
`
`
`
`
`link MTU
`
`
`
`
`
`
`
`i.¢é., maximum packet
`- the maximum transmission unit,
`
`
`
`
`
`
`
`
`
`
`size in octets,
`that can be conveyed over a link.
`
`
`
`
`
`Deering & Hinden
`
`
`
`
`Standards Track
`
`
`
`
`[Page 3]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page 3 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 3 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 Specification
`
`
`
`
`December 1998
`
`
`
`
`
`path MTU
`
`
`
`
`
`
`
`
`
`
`
`- the minimum link MTU of all the links in a path between
`a source node and a destination node.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`for a device with multiple
`though unusual,
`Note: it is possible,
`
`
`
`
`
`
`
`
`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
`
`
`
`
`
`
`
`
`
`(forwarding)
`interfaces.
`It must obey the protocol
`former
`
`
`
`
`
`
`
`
`requirements for hosts when receiving packets from, and interacting
`
`
`
`
`
`
`
`with neighbors over,
`the latter (non-forwarding)
`interfaces.
`
`
`
`
`
`3.
`
`
`
`IPv6é Header Format
`
`
`
`
`popota—fafatotat-f-totaotapatato ta tatatatetatetitatat-t-t-4-t-t-4t-
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Flow Label
`Version| Traffic Class |
`tafa+-4-t-tot-t-totatatetetatatatatetatotatatetatetet-t-t-t-4+-+
`
`
`
`
`
`
`
`
`
`|
`Payload Length
`| Next Header
`Hop Limit
`p—+—+-+4+—-4-4+-4+-4+-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4+-4+-4-4+-4-4-4+-4-
`
`
`
`
`+
`
`
`
`ea
`
`
`
`
`
`
`
`
`+
`
`Destination Address
`
`
`
`
`+
`
`
`
`
`
`
`
`
`
`
`
`
`+
`
`+
`
`Seurce Address
`
`
`
`
`+
`
`+
`
`toto ta tt ata toto ta toto ta toto ta totita ttt ttota ttt t-t-+-4-4
`
`Version
`
`
`
`4-bit Internet Protocol version number = 6.
`
`
`
`
`
`
`
`
`Traffic Class
`
`
`
`
`8-bit traffic class field.
`
`
`
`
`
`
`See section 7.
`
`
`
`
`
`Flow Label
`
`
`
`
`
`Payload Length
`
`
`
`See section 6.
`Z0-bit flow label.
`
`
`
`
`
`
`
`
`
`
`
`
`
`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]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page4 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 4 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 Specification
`
`
`
`
`December 1998
`
`
`
`
`Next Header
`
`
`
`
`Hop Limit
`
`
`
`
`
`
`
`
`
`extension headers [section 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 the 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
`
`
`
`
`
`
`
`
`
`
`126-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]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page 5 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 5 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 Specification
`
`
`
`
`December 1998
`
`
`
`4,
`
`
`
`IPvé Extension Headers
`
`
`
`
`
` n
`
`
`
`
`
`
`
`
`
`
`
`
`
`internet-layer information is encoded in separate
`IPv6, optional
`
`
`
`
`
`
`
`
`
`
`
`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:
`
`
`
`
`
`
`
`
`
`+ em nih mn pha alm emf qm uml panko tag: sm eh
`
`TPv6 header
`TCP header + data
`
`
`
`
`
`
`Next Header =
`
`TCP
`
`
`
`
`
`
`
`
`
`
`
`IPv6 header
`Routing header
`
`Next Header =
`Next Header =
`
`
`
`
`
`
`TCP
`Routing
`
`
`
`
`
`
`
`
`
`
`
` IPv6 header
`
`
`
`
`
`
`|
`|
`
`
`
`
`Next Header = | Next Header =
`Next Header =
`
`
`
`Fragment
`Routing
`|
`TEP
`f---------------4---------------- $----------------- $-----------------
`
`
`Routing header
`
`
`
`
`Fragment header
`
`
`
`
`
`
`
`fragment of TCP
`header + data
`
`
`
`
`
`|
`|
`|
`
`
`
`
`
`
`
`
`
`
`
`
`
`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]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page6 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 6 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 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
`
`
`
`
`
`
`
`
`
`
`including
`and processed by every node along a packet’s delivery path,
`
`
`
`
`
`
`
`
`
`the source and destination nodes.
`The Hop-by-Hop Options header,
`
`
`
`
`
`
`
`
`
`when present, must
`immediately follow the IPv6 header.
`Its presence
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ils indicated by the value zero in the Next Header field of the IPv6
`header.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Tf, 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 nede, 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 cffset 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.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`in
`Bach extension header is an integer multiple of 8 octets long,
`
`
`
`
`
`
`
`
`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,
`
`
`
`
`Z, 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 last two are
`The first four are specified in this document;
`
`
`
`
`
`
`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
`
`
`Routing header
`
`
`Fragment header
`
`
`
`
`(note 1)
`
`
`
`
`
`Deering & Hinden
`
`
`
`
`
`Standards Track
`
`
`[Page 7]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page7 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 7 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 Specification
`
`
`
`
`December 1998
`
`
`
`
`
`
`
`Authentication header {note 2}
`
`
`
`Encapsulating Security Payload header
`
`
`
`
`
`Destination Options header
`(note 3)
`
`
`upper-layer header
`
`
`
`
`(note 2)
`
`
`
`
`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).
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`(in the case of IPv6
`If the upper-layer header is another IPv6 header
`
`
`
`
`
`
`
`
`
`
`
`
`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.
`
`
`
`
`
`
`
`
`
`
`
`
`
`their ordering
`Tf and when other extension headers are defined,
`
`
`
`
`
`
`
`
`
`constraints relative to the above listed headers must be specified.
`
`
`
` TPv6 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 Cptions 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]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page8 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 8 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 Specification
`
`
`
`
`December 1998
`
`
`
`
`4.2 Options
`
`
`
`
`
`
`
`
`
`
`
`Two of the currently-defined extension headers -- the Hop-by-Hop
`
`
`
`
`
`
`
`
`
`Options header and the Destination Opticns header -- carry a variable
`
`
`
`
`
`
`
`
`number of type-length-value (TLV) encoded "options", of the following
`format:
`
`
`
`
`
`to4-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4- - - - - - = eH
`
`
`
`
`
`
`
`
`| Option Type
`| Opt Data Len | Option Data
`to4-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4- - - - - - =
`
`
`Option Type
`
`
`
`
`
`
`
`
`
`8-bit identifier of the type of option.
`
`
`
`
`
`Opt Data Len
`
`
`
`
`Option Data
`
`
`
`
`
`
`
`
`
`Length of the Option
`8-bit unsigned integer.
`
`
`
`
`
`
`
`in octets.
`Data field of this option,
`
`
`
`
`
`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 cption 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]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page 9 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 9 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 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.
`
`
`
`
`
`
`
`
`
`Q - 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 Opticns 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 xnt+ty, meaning the Opticn 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
`
`
`
`
`
`
`
`
`
`
`
`
`cf & octets in length.
`These padding opticns must be recognized by
`
`
`
`all IPv6 implementations:
`
`
`
`
`Padl option
`
`
`
`
`
`(alignment requirement: none)
`
`
`
`+-+-4+-+-4-4+-+-4-4
`
`
`
`
`|
`0
`|
`+-4+-4+-+-4+-4-+-4-4
`
`
`
`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 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 Padl options.
`
`
`
`
`
`Deering & Hinden
`
`
`
`
`Standards Track
`
`
`
`
`[Page 10]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page 10 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 10 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 Specification
`
`
`
`
`December 1998
`
`
`
`
`PadN option
`
`
`
`
`
`(alignment requirement: none)
`
`
`
`to fofot-f-f-4-f-t-t-¢-t-t-t-t-4-4- - = ee ee
`
`
`
`
`
`
`
`| Opt Data Len | Option Data
`1
`
`opopatatatatototatotatetitetetete oo ee
`
`|p
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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 ITPv6 header, and has the following format:
`
`
`
`
`
`foto ttt n tf-tn ttt ttt tototo to titn to t-t-t-t-4-t-4-4-4-4-4-4
`
`
`
`
`
`
`
`
`
`
`|
`Next Header
`| Hdr Ext Len
`|1
`
`—4+-4-4-4-4-4+-4-4-4-4-4-4-+-4+-4+-4
`
`
`
`+ |
`
`|
`
`|
`|
`$ototitatatatotatatatatatatot ota tatatatitotpatetitatatatta4-+-t-4+
`
`
`
`Options
`
`
`
`
`Next Header
`
`
`
`
`
`Hdr Ext Len
`
`
`
`Options
`
`
`
`
`
`
`
`
`
`Identifies the type of header
`8-bit selector.
`
`
`
`
`
`immediately following the Hop-by-Hop Options
`header. Uses the same values as the IPv4
`
`
`
`
`
`
`
`
`
`
`
`
`
`Protocol field [RFC-1700 et seq.].
`
`
`
`
`
`
`
`
`
`Length of the Hop-by-
`8-bit unsigned integer.
`
`
`
`
`
`
`
`Hop Options header in 8-octet units, not
`
`
`
`
`
`including the first 8 octets.
`
`
`
`
`
`
`
`
`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 Padl and
`
`
`
`
`
`
`PadN options specified in section 4.2.
`
`
`
`
`
`Deering & Hinden
`
`
`
`
`
`Standards Track
`
`
`[Page 11]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page 11 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 11 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 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:
`
`
`
`+-+-4-4+-+-4-4-+-4-4-4-4-4-4-4-4-4-4-4-4-4$-4-4-4-4-4-4-t-+-4-t-t-+
`
`
`
`
`
`
`
`
`
`
`
`
`|
`| Routing Type | Segments Left
`| Hdr Ext Len
`| Next Header
`+-+-4-4+-4+-4-4-4+-4-4-4-4-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4+-4+-4-t-4+-+
`
`
`|
`
`
`
`|
`
`
`type-specific data
`
`
`
`|
`|
`
`+-t-4+-4-t-4-4-4-4-4-4-4-4-t-t-t-tatot-totototodititititit4t-t-4-+
`
`
`
`
`Next Header
`
`
`
`
`
`Hdr Ext Len
`
`
`
`
`
`Routing Type
`
`
`Segments Left
`
`
`
`
`
`
`
`
`
`
`Identifies the type of header
`8-bit selector.
`
`
`
`
`
`immediately following the Routing header. Uses
`the same values as the IPv4 Protocol field
`
`
`
`
`
`
`
`
`
`
`
`[RFC-1700 et seq.].
`
`
`
`
`
`
`
`
`
`
`Length of the Routing
`86-bit unsigned integer.
`
`
`
`
`
`
`
`
`header in 8-octet units, not including the first
`8 octets.
`
`
`
`
`
`
`
`
`
`
`8-bit identifier of a particular Routing header
`variant.
`
`
`
`
`
`
`
`
`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]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page 12 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 12 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 Specification
`
`
`
`
`December 1998
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`the node must ignore the Routing header
`Tf Segments Left is zero,
`
`
`
`
`
`
`
`
`
`
`
`
`and proceed to process the next header in the packet, whose type
`
`
`
`
`
`
`
`
`
`
`
`is identified by the Next Header field in the Routing header.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`the node must discard the packet and
`Tf Segments Left is non-zero,
`
`
`
`
`
`
`
`
`
`
`
`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 ta
`
`
`
`
`the packet’s Source Address.
`
`
`
`
`
`Deering & Hinden
`
`
`
`
`
`Standards Track
`
`
`[Page 13]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page 13 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 13 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 Specification
`
`
`
`
`December 1998
`
`
`
`
`
`
`
`
`
`
`
`The Type 0 Routing header has the following format:
`
`
`
`fata toto ta toto t tte titi tattoo tot-t-t-t- ttt t-4-4-4
`
`
`
`
`
`
`
`
`
`
`
`|
`| Routing Type=0| Segments Left
`| Hdr Ext Len
`Next Header
`—t-4-4-4-4-4-4-4-4-4-4-4-4-4-4$-$-4-4-$-4-t-t-4-$-$-4-4-4-4-4-4-4+
`
`|
`Reserved
`4oto4t-4t-4-4-4-4$-4-4-F 4-4-4 4-4 ta tata tat tata tat-t-t-t-4-4-4-4
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`|
`
`+ |
`
`+ |
`
`+ |
`
`+
`
`
`
`
`+
`
`Address([1]
`
`
`
`+
`
`
`
`
`
`fo+—+—t—+—4$-t—t—t-t-ta tata t atta fp ata tata tate tet atate tata ta tata tat
`
`
`|
`
`+ |
`
`
`
`
`
`+ |
`
`+ |
`
`+
`
`
`
`
`+
`
`Address [2]
`
`
`
`+
`
`
`
`
`
`—4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-+-4-4-4-4-4-4-4-4-4$-4-4-4-4-4-4-4+
`
`
`po$—t—f—4—4-f-4-f-t— ttt tif ott
`
`toto
`
`ti
`
`tated ota tatatatititot
`
`
`
`ad
`
`
`
`
`+
`
`Address [n]
`
`
`
`+
`
`
`
`
`
`+-+-4-4+-+-4-4-4+-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-t-4+-4-t-t-+
`
`
`|
`
`+ |
`
`
`
`
`
`+ |
`
`+ |
`
`
`
`Next Header
`
`
`
`Hdr Ext Len
`
`
`
`
`
`
`
`
`
`
`Identifies the type of header
`8-bit selector.
`
`
`
`
`
`immediately following the Routing header. Uses
`the same values as the IPv4 Protocol field
`
`
`
`
`
`
`
`
`
`
`
`[RFC-1700 et seq.].
`
`
`
`
`
`
`
`
`
`
`Length of the Routing
`8-bit unsigned integer.
`
`
`
`
`
`
`
`header in 8-octet units, not including the first
`
`
`
`
`
`
`
`
`
`8 octets.
`For the Type 0 Routing header, Hdr
`
`
`
`
`
`
`
`
`
`
`Ext Len is equal te two times the number of
`addresses in the header.
`
`
`
`
`
`
`
`
`Routing Type
`
`
`
`Q.
`
`
`
`
`
`
`Deering & Hinden
`
`
`Standards Track
`
`
`
`
`[Page 14]
`
`
`
`Exhibit 1008
`Cisco v. Orckit — IPR2023-00554
`Page 14 of 39
`
`Exhibit 1008
`Cisco v. Orckit – IPR2023-00554
`Page 14 of 39
`
`

`

`
`RFC 2460
`
`
`
`
`TPv6 Specification
`
`
`
`
`December 1998
`
`
`
`
`Segments Left
`
`
`
`
`
`
`
`
`
`8-bit unsigned integer. Number of route
`
`
`
`
`
`segments remaining, i.¢., number of explicitly
`listed intermediate nodes still to be visited
`
`
`
`
`
`
`
`
`
`
`
`
`before reaching the final destination.
`
`
`
`Reserved
`
`
`
`Initialized to zero for
`32-bit reserved field.
`
`
`
`
`
`
`
`
`
`
`transmission;
`ignored on reception.
`
`
`
`
`
`Address[1..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 IPvé header.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`In that node, dispatching on the Next Header field of the immediately
`
`
`
`
`
`
`
`
`
`
`preceding header causes the Routing header module toe be invoked,
`
`
`
`
`
`
`
`
`
`
`
`in the case of Routing Type 0, performs the following
`which,
`
`algorithm:
`
`
`
`
`
`Deeri