`ÿ
`
`
`
`ÿÿÿ !ÿ ÿ"#$%&'(ÿ"#)*#(+ÿ,&%$#((%&ÿ +ÿ+-#ÿ.+#&.#+ÿ/&$-01#ÿÿ! 2#ÿ+-0(ÿ'#$3 & +0%.ÿ
`%4ÿ!5ÿ%6.ÿ7#&(%. 3ÿ2.%63#'8#ÿ
`ÿ9ÿ:-#ÿ.+#&.#+ÿ/&$-01#ÿ0(ÿ ÿ6#;(0+#ÿ+- +ÿ7&%10'#(ÿ $$#((ÿ+%ÿ ÿ'080+ 3ÿ30;& &5ÿ%4ÿ.+#&.#+ÿ
`(0+#(ÿ .'ÿ%+-#&ÿ$*3+*& 3ÿ &+04 $+(ÿ0.ÿ'080+ 3ÿ4%&!ÿ<02#ÿ ÿ7 7#&ÿ30;& &5=ÿ6#ÿ7&%10'#ÿ
`4&##ÿ $$#((ÿ+%ÿ&#(# &$-#&(=ÿ-0(+%&0 .(=ÿ($-%3 &(=ÿ .'ÿ+-#ÿ8#.#& 3ÿ7*;30$ÿ:-#ÿ.+#&.#+ÿ
`/&$-01#ÿ- (ÿ7 &+.#&#'ÿ60+-ÿ .'ÿ&#$#01#(ÿ(*77%&+ÿ4&%!ÿ1 &0%*(ÿ0.(+0+*+0%.(=ÿ
`0.$3*'0.8ÿ+-#ÿ<0;& &5ÿ%4ÿ>%.8&#((ÿ
`ÿ?ÿ:-#ÿ.+#&.#+ÿ/&$-01#ÿ- (ÿ$&# +#'ÿ ÿ(#&10$#ÿ2.%6.ÿ (ÿ+-#ÿ@ 5; $2ÿA $-0.#ÿ:-#ÿ
`@ 5; $2ÿA $-0.#ÿ! 2#(ÿ0+ÿ7%((0;3#ÿ+%ÿ;&%6(#ÿ!%&#ÿ+- .ÿBCDÿ;0330%.ÿ7 8#(ÿ(+%&#'ÿ
`0.ÿ+-#ÿ.+#&.#+ÿ/&$-01#E(ÿ6#;ÿ &$-01#ÿF0(0+%&(ÿ+%ÿ+-#ÿ@ 5; $2ÿA $-0.#ÿ$ .ÿ(# &$-ÿ
` &$-01#(ÿ;5ÿG"<ÿH0#=ÿ ÿ6#;(0+#ÿ ''&#((Iÿÿ4ÿ &$-01#'ÿ&#$%&'(ÿ4%&ÿ ÿG"<ÿ &#ÿ
` 1 03 ;3#=ÿ+-#ÿ10(0+%&ÿ6033ÿ;#ÿ7&#(#.+#'ÿ60+-ÿ ÿ'0(73 5ÿ%4ÿ 1 03 ;3#ÿ' +#(ÿÿ:-#ÿ10(0+%&ÿ
`! 5ÿ(#3#$+ÿ%.#ÿ%4ÿ+-%(#ÿ' +#(=ÿ .'ÿ;#80.ÿ;&%6(0.8ÿ .ÿ &$-01#'ÿ1#&(0%.ÿ%4ÿ+-#ÿ@#;ÿ
`<0.2(ÿ%.ÿ &$-01#'ÿ403#(ÿ0.ÿ+-#ÿ@ 5; $2ÿA $-0.#ÿ7%0.+ÿ+%ÿ%+-#&ÿ &$-01#'ÿ403#(ÿ
`H6-#+-#&ÿJ:A<ÿ7 8#(ÿ%&ÿ%+-#&ÿ403#ÿ+57#(I=ÿ04ÿ .5ÿ &#ÿ4%*.'ÿ4%&ÿ+-#ÿG"<ÿ0.'0$ +#'ÿ
`;5ÿ ÿ801#.ÿ30.2ÿK%&ÿ0.(+ .$#=ÿ+-#ÿ@ 5; $2ÿA $-0.#ÿ0(ÿ'#(08.#'ÿ(*$-ÿ+- +ÿ6-#.ÿ ÿ
`10(0+%&ÿ$30$2(ÿ%.ÿ ÿ-57#&30.2ÿ%.ÿ .ÿ &$-01#'ÿ7 8#ÿ+- +ÿ7%0.+(ÿ+%ÿ .%+-#&ÿG"<=ÿ+-#ÿ
`LMNMOPQÿSMTTÿUVÿNVQLVWÿOXVÿYQZXMLVWÿ[MTVÿ[P\]Wÿ[PQÿOXVÿX^_VQTM]`aNÿbcdÿSMOXÿOXVÿ
`$3%(#(+ÿ 1 03 ;3#ÿ' +#ÿ+%ÿ+-#ÿ0.0+0 3ÿ403#ÿ$%.+ 0.0.8ÿ+-#ÿ-57#&30.2ÿ
`ÿBÿ:-#ÿ &$-01#'ÿ' + ÿ! '#ÿ10#6 ;3#ÿ .'ÿ;&%6( ;3#ÿ;5ÿ+-#ÿ@ 5; $2ÿA $-0.#ÿ0(ÿ
`%;+ 0.#'ÿ;5ÿ*(#ÿ%4ÿ6#;ÿ &$-010.8ÿ(%4+6 &#ÿ+- +ÿ *+%! +0$ 335ÿ(+%&#(ÿ$%70#(ÿ%4ÿ403#(ÿ
` 1 03 ;3#ÿ10 ÿ+-#ÿ.+#&.#+=ÿ# $-ÿ403#ÿ7&#(#&1#'ÿ (ÿ0+ÿ#e0(+#'ÿ +ÿ ÿ7 &+0$*3 &ÿ7%0.+ÿ0.ÿ
`+0!#ÿ
`ÿCÿ:-#ÿ.+#&.#+ÿ/&$-01#ÿ ((08.(ÿ ÿG"<ÿ%.ÿ0+(ÿ(0+#ÿ+%ÿ+-#ÿ &$-01#'ÿ403#(ÿ0.ÿ+-#ÿ4%&! +ÿ
`-++7fgg6#; &$-01#%&8g6#;ghi# &ÿ0.ÿ5555jhA%.+-ÿ0.ÿ!!jhk 5ÿ0.ÿ''jh:0!#ÿ$%'#ÿ0.ÿ
`XXlmmlNNnopqQZXMLVWÿbcdnÿY`YÿY]ÿrVsOV]WVWÿbcdtuÿÿ:-*(=ÿ+-#ÿ#e+#.'#'ÿG"<ÿ
`-++7fgg6#; &$-01#%&8g6#;gvvwD9xDBCy9yg-++7fgg666 &$-01#%&8gÿ6%*3'ÿ;#ÿ+-#ÿ
`G"<ÿ4%&ÿ+-#ÿ&#$%&'ÿ%4ÿ+-#ÿ.+#&.#+ÿ/&$-01#ÿ-%!#ÿ7 8#ÿJ:A<ÿ403#ÿ
`H-++7fgg666 &$-01#%&8gIÿ &$-01#'ÿ%.ÿz .* &5ÿ9x=ÿvvwÿ +ÿBfCyÿ !ÿ .'ÿ9yÿ
`(#$%.'(ÿHvvwgDg9xÿ +ÿDBfCyf9yIÿ:-#ÿ' +#ÿ0.'0$ +#'ÿ;5ÿ .ÿ#e+#.'#'ÿG"<ÿ 7730#(ÿ
`+%ÿ ÿ7&#(#&1#'ÿ0.(+ .$#ÿ%4ÿ ÿ403#ÿ4%&ÿ ÿ801#.ÿG"<=ÿ;*+ÿ.%+ÿ.#$#(( &035ÿ+%ÿ .5ÿ%+-#&ÿ
`403#(ÿ30.2#'ÿ+-#�.ÿ:-*(=ÿ0.ÿ+-#ÿ$ (#ÿ%4ÿ ÿ7 8#ÿ$%.(+0+*+#'ÿ;5ÿ ÿ7&0! &5ÿJ:A<ÿ403#ÿ
` .'ÿ%+-#&ÿ(#7 & +#ÿ403#(ÿH#8=ÿ403#(ÿ60+-ÿ0! 8#(=ÿ *'0%=ÿ!*3+0!#'0 =ÿ'#(08.ÿ
`#3#!#.+(=ÿ%&ÿ%+-#&ÿ#!;#''#'ÿ$%.+#.+Iÿ30.2#'ÿ60+-0.ÿ+- +ÿ7&0! &5ÿJ:A<ÿ403#=ÿ+-#ÿ
`7&0! &5ÿJ:A<ÿ403#ÿ .'ÿ+-#ÿ%+-#&ÿ403#(ÿ6033ÿ# $-ÿ- 1#ÿ+-#0&ÿ%6.ÿ&#(7#$+01#ÿ#e+#.'#'ÿ
`G"<(ÿ .'ÿ! 5ÿ.%+ÿ- 1#ÿ;##.ÿ &$-01#'ÿ%.ÿ+-#ÿ( !#ÿ' +#(ÿ
`ÿ
`
`Petitioner’s Ex. 1012, Page 1
`
`
`
`ÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿ
`ÿ
`
`
`
`ÿ!ÿÿ#ÿ!%ÿ!ÿÿ&'(ÿÿÿÿ !ÿÿÿ!%%)*ÿ
`%
`+%ÿ&'(ÿ
`,,-ÿ .//)
`
`ÿ1
`>?@A?BCDEÿGH?BIJKAC@D
`ÿÿÿ9:.ÿ444444444444444444444444ÿ
`LMNOPNOMOO QRSTUSÿUSSÿTWWTXYSZ
`444444444444444444444444ÿ
`;%ÿÿ+<5=ÿ
`ÿ
`ÿ[RRÿQ\]^_US
`ÿ`\]TWÿa_]b
`ÿa_]ÿTZZcWc_dTR
`ÿe_WT]fÿghSdWU
`
`Petitioner’s Ex. 1012, Page 2
`
`
`
` ÿ
`
`
` ÿÿÿÿÿÿÿ ÿÿ! ÿÿÿ"ÿÿÿ"!"ÿ#ÿ "ÿ
`ÿ"ÿÿ#ÿ ÿÿ ÿ"$ÿ"ÿÿÿ $ÿ$ÿÿ!"ÿÿÿ
`"%
`}~
`&'(')ÿ+,ÿÿ................ÿÿ0ÿ
`123456ÿ27ÿ888888888888888888888880ÿ
`9:;ÿ=>?;@>AB@ÿABCD?EF;BDÿGHCÿCEICJ?AI;KÿHBKÿCG>?BÿI;=>?;ÿF;ÿD:ACÿLMNOÿPQÿ
`RRRRRRRRRRRRRSÿITÿRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
`
`ÿ
`mnopÿrstuvouwÿuxtÿyupÿurÿsrworzÿrstuvo{utosr|
``abcdefÿhijkl
`U>DH?TVCÿWA@BHDE?;RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
` ÿÿ
`X;@ACD?HDA>BÿU>YZÿRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
`[>FFACCA>Bÿ\]^A?HDA>Bÿ_HD;ZRRRRRRRRRRRÿ
`
`Petitioner’s Ex. 1012, Page 3
`
`
`
`
`
`
`EXHIBIT B
`EXHIBIT B
`
`
`
`
`
`Petitioner's Ex. 1012, Page 4
`
`Petitioner’s Ex. 1012, Page 4
`
`
`
`Network Working Group
`Request for Comments: 792
`
`Updates: RFCs 777, 760
`Updates: IENs 109, 128
`
`J. Postel
`ISI
`
`September 1981
`
`INTERNET CONTROL MESSAGE PROTOCOL
`
`DARPA INTERNET PROGRAM
`PROTOCOL SPECIFICATION
`
`Introduction
`
` The Internet Protocol (IP) [1] is used for host-to-host datagram
` service in a system of interconnected networks called the
` Catenet [2]. The network connecting devices are called Gateways.
` These gateways communicate between themselves for control purposes
` via a Gateway to Gateway Protocol (GGP) [3,4]. Occasionally a
` gateway or destination host will communicate with a source host, for
` example, to report an error in datagram processing. For such
` purposes this protocol, the Internet Control Message Protocol (ICMP),
` is used. ICMP, uses the basic support of IP as if it were a higher
` level protocol, however, ICMP is actually an integral part of IP, and
` must be implemented by every IP module.
`
` ICMP messages are sent in several situations: for example, when a
` datagram cannot reach its destination, when the gateway does not have
` the buffering capacity to forward a datagram, and when the gateway
` can direct the host to send traffic on a shorter route.
`
` The Internet Protocol is not designed to be absolutely reliable. The
` purpose of these control messages is to provide feedback about
` problems in the communication environment, not to make IP reliable.
` There are still no guarantees that a datagram will be delivered or a
` control message will be returned. Some datagrams may still be
` undelivered without any report of their loss. The higher level
` protocols that use IP must implement their own reliability procedures
` if reliable communication is required.
`
` The ICMP messages typically report errors in the processing of
` datagrams. To avoid the infinite regress of messages about messages
` etc., no ICMP messages are sent about ICMP messages. Also ICMP
` messages are only sent about errors in handling fragment zero of
` fragemented datagrams. (Fragment zero has the fragment offeset equal
` zero).
`
`Petitioner’s Ex. 1012, Page 5
`
`
`
`[Page 1]
`
`September 1981
`
`RFC 792
`
`Message Formats
`
` ICMP messages are sent using the basic IP header. The first octet of
` the data portion of the datagram is a ICMP type field; the value of
` this field determines the format of the remaining data. Any field
` labeled "unused" is reserved for later extensions and must be zero
` when sent, but receivers should not use these fields (except to
` include them in the checksum). Unless otherwise noted under the
` individual format descriptions, the values of the internet header
` fields are as follows:
`
` Version
`
` 4
`
` IHL
`
` Internet header length in 32-bit words.
`
` Type of Service
`
` 0
`
` Total Length
`
` Length of internet header and data in octets.
`
` Identification, Flags, Fragment Offset
`
` Used in fragmentation, see [1].
`
` Time to Live
`
` Time to live in seconds; as this field is decremented at each
` machine in which the datagram is processed, the value in this
` field should be at least as great as the number of gateways which
` this datagram will traverse.
`
` Protocol
`
` ICMP = 1
`
` Header Checksum
`
`Petitioner’s Ex. 1012, Page 6
`
`
`
` The 16 bit one's complement of the one's complement sum of all 16
` bit words in the header. For computing the checksum, the checksum
` field should be zero. This checksum may be replaced in the
` future.
`
`[Page 2]
`
`September 1981
`RFC 792
`
` Source Address
`
` The address of the gateway or host that composes the ICMP message.
` Unless otherwise noted, this can be any of a gateway's addresses.
`
` Destination Address
`
` The address of the gateway or host to which the message should be
` sent.
`
`Petitioner’s Ex. 1012, Page 7
`
`
`
`[Page 3]
`
`September 1981
`
`RFC 792
`
`Destination Unreachable Message
`
` 0 1 2 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Type | Code | Checksum |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | unused |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Internet Header + 64 bits of Original Data Datagram |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` IP Fields:
`
` Destination Address
`
` The source network and address from the original datagram's data.
`
` ICMP Fields:
`
` Type
`
` 3
`
` Code
`
` 0 = net unreachable;
`
` 1 = host unreachable;
`
` 2 = protocol unreachable;
`
` 3 = port unreachable;
`
` 4 = fragmentation needed and DF set;
`
`Petitioner’s Ex. 1012, Page 8
`
`
`
` 5 = source route failed.
`
` Checksum
`
` The checksum is the 16-bit ones's complement of the one's
` complement sum of the ICMP message starting with the ICMP Type.
` For computing the checksum , the checksum field should be zero.
` This checksum may be replaced in the future.
`
` Internet Header + 64 bits of Data Datagram
`
` The internet header plus the first 64 bits of the original
`
`[Page 4]
`
`September 1981
`RFC 792
`
` datagram's data. This data is used by the host to match the
` message to the appropriate process. If a higher level protocol
` uses port numbers, they are assumed to be in the first 64 data
` bits of the original datagram's data.
`
` Description
`
` If, according to the information in the gateway's routing tables,
` the network specified in the internet destination field of a
` datagram is unreachable, e.g., the distance to the network is
` infinity, the gateway may send a destination unreachable message
` to the internet source host of the datagram. In addition, in some
` networks, the gateway may be able to determine if the internet
` destination host is unreachable. Gateways in these networks may
` send destination unreachable messages to the source host when the
` destination host is unreachable.
`
` If, in the destination host, the IP module cannot deliver the
` datagram because the indicated protocol module or process port is
` not active, the destination host may send a destination
` unreachable message to the source host.
`
` Another case is when a datagram must be fragmented to be forwarded
` by a gateway yet the Don't Fragment flag is on. In this case the
` gateway must discard the datagram and may return a destination
` unreachable message.
`
` Codes 0, 1, 4, and 5 may be received from a gateway. Codes 2 and
` 3 may be received from a host.
`
`Petitioner’s Ex. 1012, Page 9
`
`
`
`[Page 5]
`
`September 1981
`
`RFC 792
`
`Time Exceeded Message
`
` 0 1 2 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Type | Code | Checksum |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | unused |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Internet Header + 64 bits of Original Data Datagram |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` IP Fields:
`
` Destination Address
`
` The source network and address from the original datagram's data.
`
` ICMP Fields:
`
` Type
`
` 11
`
` Code
`
` 0 = time to live exceeded in transit;
`
`Petitioner’s Ex. 1012, Page 10
`
`
`
` 1 = fragment reassembly time exceeded.
`
` Checksum
`
` The checksum is the 16-bit ones's complement of the one's
` complement sum of the ICMP message starting with the ICMP Type.
` For computing the checksum , the checksum field should be zero.
` This checksum may be replaced in the future.
`
` Internet Header + 64 bits of Data Datagram
`
` The internet header plus the first 64 bits of the original
` datagram's data. This data is used by the host to match the
` message to the appropriate process. If a higher level protocol
` uses port numbers, they are assumed to be in the first 64 data
` bits of the original datagram's data.
`
` Description
`
` If the gateway processing a datagram finds the time to live field
`
`[Page 6]
`
`September 1981
`RFC 792
`
` is zero it must discard the datagram. The gateway may also notify
` the source host via the time exceeded message.
`
` If a host reassembling a fragmented datagram cannot complete the
` reassembly due to missing fragments within its time limit it
` discards the datagram, and it may send a time exceeded message.
`
` If fragment zero is not available then no time exceeded need be
` sent at all.
`
` Code 0 may be received from a gateway. Code 1 may be received
` from a host.
`
`Petitioner’s Ex. 1012, Page 11
`
`
`
`[Page 7]
`
`September 1981
`
`RFC 792
`
`Parameter Problem Message
`
` 0 1 2 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Type | Code | Checksum |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Pointer | unused |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Internet Header + 64 bits of Original Data Datagram |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` IP Fields:
`
` Destination Address
`
` The source network and address from the original datagram's data.
`
` ICMP Fields:
`
`Petitioner’s Ex. 1012, Page 12
`
`
`
` Type
`
` 12
`
` Code
`
` 0 = pointer indicates the error.
`
` Checksum
`
` The checksum is the 16-bit ones's complement of the one's
` complement sum of the ICMP message starting with the ICMP Type.
` For computing the checksum , the checksum field should be zero.
` This checksum may be replaced in the future.
`
` Pointer
`
` If code = 0, identifies the octet where an error was detected.
`
` Internet Header + 64 bits of Data Datagram
`
` The internet header plus the first 64 bits of the original
` datagram's data. This data is used by the host to match the
` message to the appropriate process. If a higher level protocol
` uses port numbers, they are assumed to be in the first 64 data
` bits of the original datagram's data.
`
`[Page 8]
`
`September 1981
`RFC 792
`
` Description
`
` If the gateway or host processing a datagram finds a problem with
` the header parameters such that it cannot complete processing the
` datagram it must discard the datagram. One potential source of
` such a problem is with incorrect arguments in an option. The
` gateway or host may also notify the source host via the parameter
` problem message. This message is only sent if the error caused
` the datagram to be discarded.
`
` The pointer identifies the octet of the original datagram's header
` where the error was detected (it may be in the middle of an
` option). For example, 1 indicates something is wrong with the
` Type of Service, and (if there are options present) 20 indicates
` something is wrong with the type code of the first option.
`
`Petitioner’s Ex. 1012, Page 13
`
`
`
` Code 0 may be received from a gateway or a host.
`
`[Page 9]
`
`September 1981
`
`RFC 792
`
`Source Quench Message
`
` 0 1 2 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Type | Code | Checksum |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | unused |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Internet Header + 64 bits of Original Data Datagram |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`Petitioner’s Ex. 1012, Page 14
`
`
`
` IP Fields:
`
` Destination Address
`
` The source network and address of the original datagram's data.
`
` ICMP Fields:
`
` Type
`
` 4
`
` Code
`
` 0
`
` Checksum
`
` The checksum is the 16-bit ones's complement of the one's
` complement sum of the ICMP message starting with the ICMP Type.
` For computing the checksum , the checksum field should be zero.
` This checksum may be replaced in the future.
`
` Internet Header + 64 bits of Data Datagram
`
` The internet header plus the first 64 bits of the original
` datagram's data. This data is used by the host to match the
` message to the appropriate process. If a higher level protocol
` uses port numbers, they are assumed to be in the first 64 data
` bits of the original datagram's data.
`
` Description
`
` A gateway may discard internet datagrams if it does not have the
` buffer space needed to queue the datagrams for output to the next
` network on the route to the destination network. If a gateway
`
`[Page 10]
`
`September 1981
`RFC 792
`
` discards a datagram, it may send a source quench message to the
` internet source host of the datagram. A destination host may also
` send a source quench message if datagrams arrive too fast to be
` processed. The source quench message is a request to the host to
` cut back the rate at which it is sending traffic to the internet
` destination. The gateway may send a source quench message for
` every message that it discards. On receipt of a source quench
` message, the source host should cut back the rate at which it is
`
`Petitioner’s Ex. 1012, Page 15
`
`
`
` sending traffic to the specified destination until it no longer
` receives source quench messages from the gateway. The source host
` can then gradually increase the rate at which it sends traffic to
` the destination until it again receives source quench messages.
`
` The gateway or host may send the source quench message when it
` approaches its capacity limit rather than waiting until the
` capacity is exceeded. This means that the data datagram which
` triggered the source quench message may be delivered.
`
` Code 0 may be received from a gateway or a host.
`
`[Page 11]
`
`September 1981
`
`RFC 792
`
`Redirect Message
`
` 0 1 2 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
`
`Petitioner’s Ex. 1012, Page 16
`
`
`
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Type | Code | Checksum |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Gateway Internet Address
`|
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Internet Header + 64 bits of Original Data Datagram |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` IP Fields:
`
` Destination Address
`
` The source network and address of the original datagram's data.
`
` ICMP Fields:
`
` Type
`
` 5
`
` Code
`
` 0 = Redirect datagrams for the Network.
`
` 1 = Redirect datagrams for the Host.
`
` 2 = Redirect datagrams for the Type of Service and Network.
`
` 3 = Redirect datagrams for the Type of Service and Host.
`
` Checksum
`
` The checksum is the 16-bit ones's complement of the one's
` complement sum of the ICMP message starting with the ICMP Type.
` For computing the checksum , the checksum field should be zero.
` This checksum may be replaced in the future.
`
` Gateway Internet Address
`
` Address of the gateway to which traffic for the network specified
` in the internet destination network field of the original
` datagram's data should be sent.
`
`[Page 12]
`
`September 1981
`RFC 792
`
`Petitioner’s Ex. 1012, Page 17
`
`
`
` Internet Header + 64 bits of Data Datagram
`
` The internet header plus the first 64 bits of the original
` datagram's data. This data is used by the host to match the
` message to the appropriate process. If a higher level protocol
` uses port numbers, they are assumed to be in the first 64 data
` bits of the original datagram's data.
`
` Description
`
` The gateway sends a redirect message to a host in the following
` situation. A gateway, G1, receives an internet datagram from a
` host on a network to which the gateway is attached. The gateway,
` G1, checks its routing table and obtains the address of the next
` gateway, G2, on the route to the datagram's internet destination
` network, X. If G2 and the host identified by the internet source
` address of the datagram are on the same network, a redirect
` message is sent to the host. The redirect message advises the
` host to send its traffic for network X directly to gateway G2 as
` this is a shorter path to the destination. The gateway forwards
` the original datagram's data to its internet destination.
`
` For datagrams with the IP source route options and the gateway
` address in the destination address field, a redirect message is
` not sent even if there is a better route to the ultimate
` destination than the next address in the source route.
`
` Codes 0, 1, 2, and 3 may be received from a gateway.
`
`[Page 13]
`
`September 1981
`
`Petitioner’s Ex. 1012, Page 18
`
`
`
`RFC 792
`
`Echo or Echo Reply Message
`
` 0 1 2 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Type | Code | Checksum |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Identifier | Sequence Number |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Data ...
` +-+-+-+-+-
`
` IP Fields:
`
` Addresses
`
` The address of the source in an echo message will be the
` destination of the echo reply message. To form an echo reply
` message, the source and destination addresses are simply reversed,
` the type code changed to 0, and the checksum recomputed.
`
` IP Fields:
`
` Type
`
` 8 for echo message;
`
` 0 for echo reply message.
`
` Code
`
` 0
`
` Checksum
`
` The checksum is the 16-bit ones's complement of the one's
` complement sum of the ICMP message starting with the ICMP Type.
` For computing the checksum , the checksum field should be zero.
` If the total length is odd, the received data is padded with one
` octet of zeros for computing the checksum. This checksum may be
` replaced in the future.
`
` Identifier
`
` If code = 0, an identifier to aid in matching echos and replies,
` may be zero.
`
` Sequence Number
`
`Petitioner’s Ex. 1012, Page 19
`
`
`
`[Page 14]
`
`September 1981
`RFC 792
`
` If code = 0, a sequence number to aid in matching echos and
` replies, may be zero.
`
` Description
`
` The data received in the echo message must be returned in the echo
` reply message.
`
` The identifier and sequence number may be used by the echo sender
` to aid in matching the replies with the echo requests. For
` example, the identifier might be used like a port in TCP or UDP to
` identify a session, and the sequence number might be incremented
` on each echo request sent. The echoer returns these same values
` in the echo reply.
`
` Code 0 may be received from a gateway or a host.
`
`Petitioner’s Ex. 1012, Page 20
`
`
`
`[Page 15]
`
`September 1981
`
`RFC 792
`
`Timestamp or Timestamp Reply Message
`
` 0 1 2 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Type | Code | Checksum |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Identifier | Sequence Number |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Originate Timestamp
`|
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Receive Timestamp
`|
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Transmit Timestamp
`|
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` IP Fields:
`
` Addresses
`
` The address of the source in a timestamp message will be the
` destination of the timestamp reply message. To form a timestamp
` reply message, the source and destination addresses are simply
` reversed, the type code changed to 14, and the checksum
` recomputed.
`
` IP Fields:
`
` Type
`
` 13 for timestamp message;
`
` 14 for timestamp reply message.
`
` Code
`
` 0
`
` Checksum
`
` The checksum is the 16-bit ones's complement of the one's
` complement sum of the ICMP message starting with the ICMP Type.
`
`Petitioner’s Ex. 1012, Page 21
`
`
`
` For computing the checksum , the checksum field should be zero.
` This checksum may be replaced in the future.
`
` Identifier
`
`[Page 16]
`
`September 1981
`RFC 792
`
` If code = 0, an identifier to aid in matching timestamp and
` replies, may be zero.
`
` Sequence Number
`
` If code = 0, a sequence number to aid in matching timestamp and
` replies, may be zero.
`
` Description
`
` The data received (a timestamp) in the message is returned in the
` reply together with an additional timestamp. The timestamp is 32
` bits of milliseconds since midnight UT. One use of these
` timestamps is described by Mills [5].
`
` The Originate Timestamp is the time the sender last touched the
` message before sending it, the Receive Timestamp is the time the
` echoer first touched it on receipt, and the Transmit Timestamp is
` the time the echoer last touched the message on sending it.
`
` If the time is not available in miliseconds or cannot be provided
` with respect to midnight UT then any time can be inserted in a
` timestamp provided the high order bit of the timestamp is also set
` to indicate this non-standard value.
`
` The identifier and sequence number may be used by the echo sender
` to aid in matching the replies with the requests. For example,
` the identifier might be used like a port in TCP or UDP to identify
` a session, and the sequence number might be incremented on each
` request sent. The destination returns these same values in the
` reply.
`
` Code 0 may be received from a gateway or a host.
`
`Petitioner’s Ex. 1012, Page 22
`
`
`
`[Page 17]
`
`September 1981
`
`RFC 792
`
`Information Request or Information Reply Message
`
` 0 1 2 3
` 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Type | Code | Checksum |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Identifier | Sequence Number |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
` IP Fields:
`
` Addresses
`
` The address of the source in a information request message will be
` the destination of the information reply message. To form a
` information reply message, the source and destination addresses
` are simply reversed, the type code changed to 16, and the checksum
` recomputed.
`
` IP Fields:
`
` Type
`
` 15 for information request message;
`
` 16 for information reply message.
`
` Code
`
` 0
`
` Checksum
`
`Petitioner’s Ex. 1012, Page 23
`
`
`
` The checksum is the 16-bit ones's complement of the one's
` complement sum of the ICMP message starting with the ICMP Type.
` For computing the checksum , the checksum field should be zero.
` This checksum may be replaced in the future.
`
` Identifier
`
` If code = 0, an identifier to aid in matching request and replies,
` may be zero.
`
` Sequence Number
`
` If code = 0, a sequence number to aid in matching request and
` replies, may be zero.
`
`[Page 18]
`
`September 1981
`RFC 792
`
` Description
`
` This message may be sent with the source network in the IP header
` source and destination address fields zero (which means "this"
` network). The replying IP module should send the reply with the
` addresses fully specified. This message is a way for a host to
` find out the number of the network it is on.
`
` The identifier and sequence number may be used by the echo sender
` to aid in matching the replies with the requests. For example,
` the identifier might be used like a port in TCP or UDP to identify
` a session, and the sequence number might be incremented on each
` request sent. The destination returns these same values in the
` reply.
`
` Code 0 may be received from a gateway or a host.
`
`Petitioner’s Ex. 1012, Page 24
`
`
`
`[Page 19]
`
`September 1981
`
`RFC 792
`
`Summary of Message Types
`
` 0 Echo Reply
`
` 3 Destination Unreachable
`
` 4 Source Quench
`
` 5 Redirect
`
` 8 Echo
`
` 11 Time Exceeded
`
` 12 Parameter Problem
`
` 13 Timestamp
`
` 14 Timestamp Reply
`
` 15 Information Request
`
` 16 Information Reply
`
`Petitioner’s Ex. 1012, Page 25
`
`
`
`[Page 20]
`
`September 1981
`RFC 792
`
`References
`
`[1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program
`Protocol Specification," RFC 791, USC/Information Sciences
`Institute, September 1981.
`
`[2] Cerf, V., "The Catenet Model for Internetworking," IEN 48,
`Information Processing Techniques Office, Defense Advanced
`Research Projects Agency, July 1978.
`
`[3] Strazisar, V., "Gateway Routing: An Implementation
`Specification", IEN 30, Bolt Beranek and Newman, April 1979.
`
`[4] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek
`and Newman, August 1979.
`
`[5] Mills, D., "DCNET Internet Clock Service," RFC 778, COMSAT
`Laboratories, April 1981.
`
`Petitioner’s Ex. 1012, Page 26
`
`
`
`[Page 21]
`[Page 21]
`
`Petitioner's Ex. 1012, Page 27
`
`Petitioner’s Ex. 1012, Page 27
`
`