octets or greater.  On any link that cannot convey a 1280-octet   packet in one piece, link-specific fragmentation and reassembly must   be provided at a layer below IPv6.   Links that have a configurable MTU (for example, PPP links [RFC-   1661]) must be configured to have an MTU of at least 1280 octets; it   is recommended that they be configured with an MTU of 1500 octets or   greater, to accommodate possible encapsulations (i.e., tunneling)   without incurring IPv6-layer fragmentation.   From each link to which a node is directly attached, the node must be   able to accept packets as large as that link's MTU.   It is strongly recommended that IPv6 nodes implement Path MTU   Discovery [RFC-1981], in order to discover and take advantage of path   MTUs greater than 1280 octets.  However, a minimal IPv6   implementation (e.g., in a boot ROM) may simply restrict itself to   sending packets no larger than 1280 octets, and omit implementation   of Path MTU Discovery.   In order to send a packet larger than a path's MTU, a node may use   the IPv6 Fragment header to fragment the packet at the source and   have it reassembled at the destination(s).  However, the use of such   fragmentation is discouraged in any application that is able to   adjust its packets to fit the measured path MTU (i.e., down to 1280   octets).Deering & Hinden            Standards Track                    [Page 24]RFC 2460                   IPv6 Specification              December 1998   A node must be able to accept a fragmented packet that, after   reassembly, is as large as 1500 octets.  A node is permitted to   accept fragmented packets that reassemble to more than 1500 octets.   An upper-layer protocol or application that depends on IPv6   fragmentation to send packets larger than the MTU of a path should   not send packets larger than 1500 octets unless it has assurance that   the destination is capable of reassembling packets of that larger   size.   In response to an IPv6 packet that is sent to an IPv4 destination   (i.e., a packet that undergoes translation from IPv6 to IPv4), the   originating IPv6 node may receive an ICMP Packet Too Big message   reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node   is not required to reduce the size of subsequent packets to less than   1280, but must include a Fragment header in those packets so that the   IPv6-to-IPv4 translating router can obtain a suitable Identification   value to use in resulting IPv4 fragments.  Note that this means the   payload may have to be reduced to 1232 octets (1280 minus 40 for the   IPv6 header and 8 for the Fragment header), and smaller still if   additional extension headers are used.6.  Flow Labels   The 20-bit Flow Label field in the IPv6 header may be used by a   source to label sequences of packets for which it requests special   handling by the IPv6 routers, such as non-default quality of service   or "real-time" service.  This aspect of IPv6 is, at the time of   writing, still experimental and subject to change as the requirements   for flow support in the Internet become clearer.  Hosts or routers   that do not support the functions of the Flow Label field are   required to set the field to zero when originating a packet, pass the   field on unchanged when forwarding a packet, and ignore the field   when receiving a packet.   Appendix A describes the current intended semantics and usage of the   Flow Label field.7.  Traffic Classes   The 8-bit Traffic Class field in the IPv6 header is available for use   by originating nodes and/or forwarding routers to identify and   distinguish between different classes or priorities of IPv6 packets.   At the point in time at which this specification is being written,   there are a number of experiments underway in the use of the IPv4   Type of Service and/or Precedence bits to provide various forms of   "differentiated service" for IP packets, other than through the use   of explicit flow set-up.  The Traffic Class field in the IPv6 header   is intended to allow similar functionality to be supported in IPv6.Deering & Hinden            Standards Track                    [Page 25]RFC 2460                   IPv6 Specification              December 1998   It is hoped that those experiments will eventually lead to agreement   on what sorts of traffic classifications are most useful for IP   packets.  Detailed definitions of the syntax and semantics of all or   some of the IPv6 Traffic Class bits, whether experimental or intended   for eventual standardization, are to be provided in separate   documents.   The following general requirements apply to the Traffic Class field:      o  The service interface to the IPv6 service within a node must         provide a means for an upper-layer protocol to supply the value         of the Traffic Class bits in packets originated by that upper-         layer protocol.  The default value must be zero for all 8 bits.      o  Nodes that support a specific (experimental or eventual         standard) use of some or all of the Traffic Class bits are         permitted to change the value of those bits in packets that         they originate, forward, or receive, as required for that         specific use.  Nodes should ignore and leave unchanged any bits         of the Traffic Class field for which they do not support a         specific use.      o  An upper-layer protocol must not assume that the value of the         Traffic Class bits in a received packet are the same as the         value sent by the packet's source.Deering & Hinden            Standards Track                    [Page 26]RFC 2460                   IPv6 Specification              December 19988. Upper-Layer Protocol Issues8.1 Upper-Layer Checksums   Any transport or other upper-layer protocol that includes the   addresses from the IP header in its checksum computation must be   modified for use over IPv6, to include the 128-bit IPv6 addresses   instead of 32-bit IPv4 addresses.  In particular, the following   illustration shows the TCP and UDP "pseudo-header" for IPv6:   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                                                               |   +                                                               +   |                                                               |   +                         Source Address                        +   |                                                               |   +                                                               +   |                                                               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                                                               |   +                                                               +   |                                                               |   +                      Destination Address                      +   |                                                               |   +                                                               +   |                                                               |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                   Upper-Layer Packet Length                   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                      zero                     |  Next Header  |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      o  If the IPv6 packet contains a Routing header, the Destination         Address used in the pseudo-header is that of the final         destination.  At the originating node, that address will be in         the last element of the Routing header; at the recipient(s),         that address will be in the Destination Address field of the         IPv6 header.      o  The Next Header value in the pseudo-header identifies the         upper-layer protocol (e.g., 6 for TCP, or 17 for UDP).  It will         differ from the Next Header value in the IPv6 header if there         are extension headers between the IPv6 header and the upper-         layer header.      o  The Upper-Layer Packet Length in the pseudo-header is the         length of the upper-layer header and data (e.g., TCP header         plus TCP data).  Some upper-layer protocols carry their ownDeering & Hinden            Standards Track                    [Page 27]RFC 2460                   IPv6 Specification              December 1998         length information (e.g., the Length field in the UDP header);         for such protocols, that is the length used in the pseudo-         header.  Other protocols (such as TCP) do not carry their own         length information, in which case the length used in the         pseudo-header is the Payload Length from the IPv6 header, minus         the length of any extension headers present between the IPv6         header and the upper-layer header.      o  Unlike IPv4, when UDP packets are originated by an IPv6 node,         the UDP checksum is not optional.  That is, whenever         originating a UDP packet, an IPv6 node must compute a UDP         checksum over the packet and the pseudo-header, and, if that         computation yields a result of zero, it must be changed to hex         FFFF for placement in the UDP header.  IPv6 receivers must         discard UDP packets containing a zero checksum, and should log         the error.   The IPv6 version of ICMP [ICMPv6] includes the above pseudo-header in   its checksum computation; this is a change from the IPv4 version of   ICMP, which does not include a pseudo-header in its checksum.  The   reason for the change is to protect ICMP from misdelivery or   corruption of those fields of the IPv6 header on which it depends,   which, unlike IPv4, are not covered by an internet-layer checksum.   The Next Header field in the pseudo-header for ICMP contains the   value 58, which identifies the IPv6 version of ICMP.8.2 Maximum Packet Lifetime   Unlike IPv4, IPv6 nodes are not required to enforce maximum packet   lifetime.  That is the reason the IPv4 "Time to Live" field was   renamed "Hop Limit" in IPv6.  In practice, very few, if any, IPv4   implementations conform to the requirement that they limit packet   lifetime, so this is not a change in practice.  Any upper-layer   protocol that relies on the internet layer (whether IPv4 or IPv6) to   limit packet lifetime ought to be upgraded to provide its own   mechanisms for detecting and discarding obsolete packets.8.3 Maximum Upper-Layer Payload Size   When computing the maximum payload size available for upper-layer   data, an upper-layer protocol must take into account the larger size   of the IPv6 header relative to the IPv4 header.  For example, in   IPv4, TCP's MSS option is computed as the maximum packet size (a   default value or a value learned through Path MTU Discovery) minus 40   octets (20 octets for the minimum-length IPv4 header and 20 octets   for the minimum-length TCP header).  When using TCP over IPv6, the   MSS must be computed as the maximum packet size minus 60 octets,Deering & Hinden            Standards Track                    [Page 28]RFC 2460                   IPv6 Specification              December 1998   because the minimum-length IPv6 header (i.e., an IPv6 header with no   extension headers) is 20 octets longer than a minimum-length IPv4   header.8.4 Responding to Packets Carrying Routing Headers   When an upper-layer protocol sends one or more packets in response to   a received packet that included a Routing header, the response   packet(s) must not include a Routing header that was automatically   derived by "reversing" the received Routing header UNLESS the   integrity and authenticity of the received Source Address and Routing   header have been verified (e.g., via the use of an Authentication   header in the received packet).  In other words, only the following   kinds of packets are permitted in response to a received packet   bearing a Routing header:      o  Response packets that do not carry Routing headers.      o  Response packets that carry Routing headers that were NOT         derived by reversing the Routing header of the received packet         (for example, a Routing header supplied by local         configuration).      o  Response packets that carry Routing headers that were derived         by reversing the Routing header of the received packet IF AND         ONLY IF the integrity and authenticity of the Source Address         and Routing header from the received packet have been verified         by the responder.Deering & Hinden            Standards Track                    [Page 29]RFC 2460                   IPv6 Specification              December 1998Appendix A. Semantics and Usage of the Flow Label Field   A flow is a sequence of packets sent from a particular source to a   particular (unicast or multicast) destination for which the source   desires special handling by the intervening routers.  The nature of   that special handling might be conveyed to the routers by a control   protocol, such as a resource reservation protocol, or by information   within the flow's packets themselves, e.g., in a hop-by-hop option.   The details of such control protocols or options are beyond the scope   of this document.   There may be multiple active flows from a source to a destination, as   well as traffic that is not associated with any flow.  A flow is   uniquely identified by the combination of a source address and a   non-zero