IPv6 packet

Last updated

An IPv6 packet is the smallest message entity exchanged using Internet Protocol version 6 (IPv6). Packets consist of control information for addressing and routing and a payload of user data. The control information in IPv6 packets is subdivided into a mandatory fixed header and optional extension headers. The payload of an IPv6 packet is typically a datagram or segment of the higher-level transport layer protocol, but may be data for an internet layer (e.g., ICMPv6) or link layer (e.g., OSPF) instead.

Contents

IPv6 packets are typically transmitted over the link layer (i.e., over Ethernet or Wi-Fi), which encapsulates each packet in a frame. Packets may also be transported over a higher-layer tunneling protocol, such as IPv4 when using 6to4 or Teredo transition technologies.

In contrast to IPv4, routers do not fragment IPv6 packets larger than the maximum transmission unit (MTU), it is the sole responsibility of the originating node. A minimum MTU of 1,280 octets is mandated by IPv6, but hosts are "strongly recommended" to use Path MTU Discovery to take advantage of MTUs greater than the minimum. [1]

Since July 2017, the Internet Assigned Numbers Authority (IANA) has been responsible for registering all IPv6 parameters that are used in IPv6 packet headers. [1]

Fixed header

The fixed header starts an IPv6 packet and has a size of 40 octets (320 bits). [1] The bytes of the multi-byte fields are in the network byte order.

Fixed header format
Offset Octet 0123
Octet Bit 012345678910111213141516171819202122232425262728293031
00VersionTraffic classFlow label
432Payload lengthNext headerHop limit
864Source address
1296
16128
20160
24192Destination address
28224
32256
36288
Version: 4 bits:The constant 6 (bit sequence 0110).
Traffic Class: 6+2 bits:The bits of this field hold two values. The six most-significant bits hold the differentiated services field (DS field), which is used to classify packets. [2] [3] Currently, all standard DS fields end with a '0' bit. Any DS field that ends with two '1' bits is intended for local or experimental use. [4] The remaining two bits are used for Explicit Congestion Notification (ECN); [5] priority values subdivide into ranges: traffic where the source provides congestion control and non-congestion control traffic.
Flow Label: 20 bits:A high-entropy identifier of a flow of packets between a source and destination. A flow is a group of packets, e.g., a TCP session or a media stream. The special flow label 0 means the packet does not belong to any flow (using this scheme). An older scheme identifies flow by source address and port, destination address and port, protocol (value of the last Next Header field). [6] It has further been suggested that the flow label be used to help detect spoofed packets. [7]
Payload Length: 16 bits:The size of the payload in octets, including any extension headers. The length is set to zero when a Hop-by-Hop extension header carries a Jumbo Payload option. [8]
Next Header: 8 bits:Specifies the type of the next header. This field usually specifies the transport layer protocol used by a packet's payload. When extension headers are present in the packet this field indicates which extension header follows. The values are shared with those used for the IPv4 protocol field, as both fields have the same function (see List of IP protocol numbers ).
Hop Limit: 8 bits:Replaces the time to live field in IPv4. This value is decremented by one at each forwarding node and the packet is discarded if it becomes 0. However, the destination node should process the packet normally even if received with a hop limit of 0.
Source Address: 128 bits:The unicast IPv6 address of the sending node.
Destination Address: 128 bits:The IPv6 unicast or multicast address of the destination node(s).

In order to increase performance, and since current link layer technology and transport layer protocols are assumed to provide sufficient error detection, [9] the header has no checksum to protect it. [1]

Extension headers

Extension headers carry optional internet layer information and are placed between the fixed header and the upper-layer protocol header. [1] Extension headers form a chain, using the Next Header fields. The Next Header field in the fixed header indicates the type of the first extension header; the Next Header field of the last extension header indicates the type of the upper-layer protocol header in the payload of the packet. All extension headers are a multiple of 8 octets in size; some extension headers require internal padding to meet this requirement.

There are several extension headers defined, and new extension headers may be defined in the future. Most extension headers are examined and processed at the packet's destination. Hop-by-Hop Options can be processed and modified by intermediate nodes and, if present, must be the first extension. All extension headers are optional and should appear at most once, except for the Destination Options header extension, which may appear twice. [1]

If a node does not recognize a specific extension header, it should discard the packet and send a Parameter Problem message (ICMPv6 type 4, code 1). [1]

The defined extension headers below are listed in the preferred order for the case where there is more than one extension header following the fixed header.

Extension header Next Header field value Description
Hop-by-Hop Options 0Options that need to be examined by all devices on the path
Routing 43Methods to specify the route for a datagram (used with Mobile IPv6)
Fragment 44Contains parameters for fragmentation of datagrams
Authentication Header (AH) 51Contains information used to verify the authenticity of most parts of the packet
Encapsulating Security Payload (ESP) 50Carries encrypted data for secure communication
Destination Options (before upper-layer header)60Options that need to be examined only by the destination of the packet
Mobility (currently without upper-layer header)135Parameters used with Mobile IPv6
Host Identity Protocol139Used for Host Identity Protocol version 2 (HIPv2) [10]
Shim6 Protocol140Used for Shim6 [11]
Reserved253Used for experimentation and testing [12] [4]
Reserved254Used for experimentation and testing [12] [4]

Value 59 (No Next Header) in the Next Header field indicates that there is no next header whatsoever following this one, not even a header of an upper-layer protocol. It means that, from the header's point of view, the IPv6 packet ends right after it: the payload should be empty. There could, however, still be data in the payload if the payload length in the first header of the packet is greater than the length of all extension headers in the packet. This data should be ignored by hosts, but passed unaltered by routers. [1] : 4.7 

Hop-by-hop options and destination options

The Hop-by-Hop Options extension header may be examined and altered by all nodes on the packet's path, including sending and receiving nodes. (For authentication, option values that may change along the path are ignored.) The Destination Options extension header needs to be examined by the destination node(s) only. The extension headers are both at least 8 octets in size; if more options are present than will fit in that space, blocks of 8 octets, containing options and padding, are added to the header repeatedly until all options are represented.

Hop-by-Hop Options and Destination Options extension header format
Offset Octet 0123
Octet Bit 012345678910111213141516171819202122232425262728293031
00Next headerHeader extension lengthOptions and padding
432Options and padding
864Optional: more Options and padding
1296
⋮⋮
Next Header: 8 bits:Specifies the type of the next header.
Header extension length: 8 bits:Length of this header in 8-octet units, not including the first 8 octets.
Options and padding: variable:Contains one or more options, and optional padding fields to align options and to make the total header length a multiple of 8 octets. Options are TLV -coded.

Routing

The Routing extension header is used to direct a packet to one or more intermediate nodes before being sent to its destination. The header is at least 8 octets in size; if more Type-specific Data is needed than will fit in 4 octets, blocks of 8 octets are added to the header repeatedly, until all Type-specific Data is placed. [1]

Routing extension header format
Offset Octet 0123
Octet Bit 012345678910111213141516171819202122232425262728293031
00Next headerHeader extension lengthRouting typeSegments left
432Type-specific data
864Optional: more type-specific data...
1296
⋮⋮
Next header: 8 bits:Indicates the type of the next header.
Header extension length: 8 bits:The length of this header, in multiples of 8 octets, not including the first 8 octets.
Routing type: 8 bits:A value between 0 and 255, as assigned by IANA . [13]
TypeStatusComment
0DeprecatedDue to the fact that with Routing Header type 0 a simple but effective denial-of-service attack could be launched, [14] this header was deprecated in 2007 and host and routers are required to ignore these headers. [15]
1DeprecatedUsed for the Nimrod project [16] funded by DARPA. It was deprecated in 2009.
2AllowedA limited version of type 0 and is used for Mobile IPv6, where it can hold the home address of the mobile node.
3AllowedRPL Source Route Header [17] for low-power and lossy networks.
4AllowedSegment Routing Header (SRH). [18]
253Private useMay be used for testing, not for actual implementations. RFC3692-style Experiment 1. [12]
254Private useMay be used for testing, not for actual implementations. RFC3692-style Experiment 2. [12]
Segments Left: 8 bits:Number of nodes this packet still has to visit before reaching its final destination.
Type-specific Data: variable:Data that belongs to this type of routing header.

Fragment

In order to send a packet that is larger than the path MTU, the sending node splits the packet into fragments. The Fragment extension header carries the information necessary to reassemble the original (unfragmented) packet. [1]

Fragment extension header format
Offset Octet 0123
Octet Bit 012345678910111213141516171819202122232425262728293031
00Next HeaderReservedFragment offsetResM
432Identification
Next header: 8 bits:Identifies the type of the next header.
Reserved: 8 bits; Reserved == 0:Initialized to all zeroes.
Fragment offset: 13 bits:Offset, in 8-octet units, relative to the start of the fragmentable part of the original packet.
Reserved2 (Res): 2 bits; Res == 0:Reserved; initialized to zeroes.
M Flag (M): 1 bit:1 means more fragments follow; 0 means last fragment.
Identification: 32 bits:Packet identification value, generated by the source node. Needed for reassembly of the original packet.

Authentication Header (AH) and Encapsulating Security Payload (ESP)

The Authentication Header and the Encapsulating Security Payload are part of IPsec and are used identically in IPv6 and in IPv4. [19] [20]

Payload

The fixed and optional IPv6 headers are followed by the upper-layer payload, the data provided by the transport layer, for example a TCP segment or a UDP datagram. The Next Header field of the last IPv6 header indicates what type of payload is contained in this packet.

Standard payload length

The payload length field of IPv6 (and IPv4) has a size of 16 bits, capable of specifying a maximum length of 65535 octets for the payload. In practice, hosts determine the maximum usable payload length using Path MTU Discovery (yielding the minimum MTU along the path from sender to receiver), to avoid having to fragment packets. Most link-layer protocols have MTUs considerably smaller than 65535 octets.

Jumbogram

An optional feature of IPv6, the jumbo payload option in a Hop-By-Hop Options extension header, [8] allows the exchange of packets with payloads of up to one octet less than 4  GB (232 − 1 = 4294967295 octets), by making use of a 32-bit length field. Packets with such payloads are called jumbograms.

Since both TCP and UDP include fields limited to 16 bits (length, urgent data pointer), support for IPv6 jumbograms requires modifications to the transport layer protocol implementation. [8] Jumbograms are only relevant for links that have a MTU larger than 65583 octets (more than 65535 octets for the payload, plus 40 octets for the fixed header, plus 8 octets for the Hop-by-Hop extension header). Only a few link-layer protocols can process packets larger than 65535 octets.[ citation needed ]

Fragmentation

Unlike in IPv4, IPv6 routers never fragment IPv6 packets. Packets exceeding the size of the maximum transmission unit (MTU) of the destination link are dropped and this condition is signaled by a Packet too big ICMPv6 message to the originating node, similarly to the IPv4 method when the Don't Fragment bit is set. [1] End nodes in IPv6 are expected to perform Path MTU Discovery to determine the maximum size of packets to send, and the upper-layer protocol is expected to limit the payload size. If the upper-layer protocol is unable to do so, the sending host may use the Fragment extension header instead.

Any data link layer conveying IPv6 data must be capable of transmitting an IP packet containing up to 1,280 bytes, thus the sending endpoint may limit its packets to 1,280 bytes and avoid any need for fragmentation or Path MTU Discovery.

Fragmenting

A packet containing the first fragment of an original (larger) packet consists of five parts: the per-fragment headers (the crucial original headers that are repeatedly used in each fragment), followed by the Fragment extension header containing a zero Offset, then all the remaining original extension headers, then the original upper-layer header (alternatively the ESP header), and a piece of the original payload. [1] Each subsequent packet consists of three parts: the per-fragment headers, followed by the Fragment extension header, and by a part of the original payload as identified by a Fragment Offset.

The per-fragment headers are determined based on whether the original contains Routing or Hop-by-Hop extension header. If neither exists, the per-fragment part is just the fixed header. If the Routing extension header exists, the per-fragment headers include the fixed header and all the extension headers up to and including the Routing one. If the Hop-by-Hop extension header exists, the per-fragment headers consist of only the fixed header and the Hop-by-Hop extension header.

In any case, the last header of the per-fragment part has its Next Header value set to 44 to indicate that a Fragment extension header follows. Each Fragment extension header has its M flag set to 1 (indicating more fragments follow), except the last, whose flag is set to 0. Each fragment's length is a multiple of 8 octets, except, potentially, the last fragment.

The per-fragment headers were historically called the "unfragmentable part", referring to pre-2014 possibility of fragmenting the rest of the header. Now no headers are actually fragmentable. [21]

Reassembly

The original packet is reassembled by the receiving node by collecting all fragments and placing each fragment at its indicated offset and discarding the Fragment extension headers of the packets that carried them. Packets containing fragments need not arrive in sequence; they will be rearranged by the receiving node.

If not all fragments are received within 60 seconds after receiving the first packet with a fragment, reassembly of the original packet is abandoned and all fragments are discarded. If the first fragment was received (which contains the fixed header) and one or more others are missing, a Time Exceeded message (ICMPv6 type 3, code 1) is returned to the node originating the fragmented packet.

When reassembling node detects a fragment that overlaps with another fragment, the reassembly of the original packet is aborted and all fragments are dropped. A node may optionally ignore the exact duplicates of a fragment instead of treating exact duplicates as overlapping each other. [1]

Receiving hosts must make a best-effort attempt to reassemble fragmented IP datagrams that, after reassembly, contain up to 1500 bytes. Hosts are permitted to make an attempt to reassemble fragmented datagrams larger than 1,500 bytes, but they are also permitted to silently discard any datagram after it becomes apparent that the reassembled packet would be larger than 1,500 bytes. Therefore, senders should avoid sending fragmented IP datagrams with a total reassembled size larger than 1,500 bytes, unless they have knowledge that the receiver is capable of reassembling such large datagrams.

Security

Research has shown that the use of fragmentation can be leveraged to evade network security controls. As a result, in 2014 the earlier allowance for overflowing the IPv6 header chain beyond the first fragment became forbidden in order to avoid some very pathological fragmentation cases. [21] Additionally, as a result of research on the evasion of Router Advertisement Guard, [22] the use of fragmentation with Neighbor Discovery is deprecated, and the use of fragmentation with Secure Neighbor Discovery (SEND) is discouraged. [23]

Related Research Articles

The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating success or failure when communicating with another IP address. For example, an error is indicated when a requested service is not available or that a host or router could not be reached. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications.

<span class="mw-page-title-main">IPv4</span> Fourth version of the Internet Protocol

Internet Protocol version 4 (IPv4) is the first version of the Internet Protocol (IP) as a standalone specification. It is one of the core protocols of standards-based internetworking methods in the Internet and other packet-switched networks. IPv4 was the first version deployed for production on SATNET in 1982 and on the ARPANET in January 1983. It is still used to route most Internet traffic today, even with the ongoing deployment of Internet Protocol version 6 (IPv6), its successor.

<span class="mw-page-title-main">IPv6</span> Version 6 of the Internet Protocol

Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion, and was intended to replace IPv4. In December 1998, IPv6 became a Draft Standard for the IETF, which subsequently ratified it as an Internet Standard on 14 July 2017.

The Internet Protocol (IP) is the network layer communications protocol in the Internet protocol suite for relaying datagrams across network boundaries. Its routing function enables internetworking, and essentially establishes the Internet.

In computer networking, the maximum transmission unit (MTU) is the size of the largest protocol data unit (PDU) that can be communicated in a single network layer transaction. The MTU relates to, but is not identical to the maximum frame size that can be transported on the data link layer, e.g., Ethernet frame.

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.

In computer networking, the User Datagram Protocol (UDP) is one of the core communication protocols of the Internet protocol suite used to send messages to other hosts on an Internet Protocol (IP) network. Within an IP network, UDP does not require prior communication to set up communication channels or data paths.

In computing, Internet Protocol Security (IPsec) is a secure network protocol suite that authenticates and encrypts packets of data to provide secure encrypted communication between two computers over an Internet Protocol network. It is used in virtual private networks (VPNs).

<span class="mw-page-title-main">IP fragmentation</span> Process that breaks IP packets into smaller pieces

IP fragmentation is an Internet Protocol (IP) process that breaks packets into smaller pieces (fragments), so that the resulting pieces can pass through a link with a smaller maximum transmission unit (MTU) than the original packet size. The fragments are reassembled by the receiving host.

The maximum segment size (MSS) is a parameter of the Options field of the TCP header that specifies the largest amount of data, specified in bytes, that a computer or communications device can receive in a single TCP segment. It does not count the TCP header or the IP header. The IP datagram containing a TCP segment may be self-contained within a single packet, or it may be reconstructed from several fragmented pieces; either way, the MSS limit applies to the total amount of data contained in the final, reconstructed TCP segment.

The Neighbor Discovery Protocol (NDP), or simply Neighbor Discovery (ND), is a protocol of the Internet protocol suite used with Internet Protocol Version 6 (IPv6). It operates at the internet layer of the Internet model, and is responsible for gathering various information required for network communication, including the configuration of local connections and the domain name servers and gateways.

A ping of death is a type of attack on a computer system that involves sending a malformed or otherwise malicious ping to a computer. In this attack, a host sends hundreds of ping requests with a packet size that is large or illegal to another host to try to take it offline or to keep it preoccupied responding with ICMP Echo replies.

In packet-switched computer networks, a jumbogram is an internet-layer packet exceeding the standard maximum transmission unit (MTU) of the underlying network technology. In contrast, large packets for link-layer technologies are referred to as jumbo frames.

Internet Control Message Protocol version 6 (ICMPv6) is the implementation of the Internet Control Message Protocol (ICMP) for Internet Protocol version 6 (IPv6). ICMPv6 is an integral part of IPv6 and performs error reporting and diagnostic functions.

6LoWPAN was a working group of the Internet Engineering Task Force (IETF). It was created with the intention of applying the Internet Protocol (IP) even to the smallest devices, enabling low-power devices with limited processing capabilities to participate in the Internet of Things.

Path MTU Discovery (PMTUD) is a standardized technique in computer networking for determining the maximum transmission unit (MTU) size on the network path between two Internet Protocol (IP) hosts, usually with the goal of avoiding IP fragmentation. PMTUD was originally intended for routers in Internet Protocol Version 4 (IPv4). However, all modern operating systems use it on endpoints. In IPv6, this function has been explicitly delegated to the end points of a communications session. As an extension to the standard path MTU discovery, a technique called Packetization Layer Path MTU Discovery works without support from ICMP.

The internet layer is a group of internetworking methods, protocols, and specifications in the Internet protocol suite that are used to transport network packets from the originating host across network boundaries; if necessary, to the destination host specified by an IP address. The internet layer derives its name from its function facilitating internetworking, which is the concept of connecting multiple networks with each other through gateways.

The Internet checksum, also called the IPv4 header checksum is a checksum used in version 4 of the Internet Protocol (IPv4) to detect corruption in the header of IPv4 packets. It is carried in the IP packet header, and represents the 16-bit result of summation of the header words.

IP in IP is an IP tunneling protocol that encapsulates one IP packet in another IP packet. To encapsulate an IP packet in another IP packet, an outer header is added with Source IP, the entry point of the tunnel, and Destination IP, the exit point of the tunnel. While doing this, the inner packet is unmodified. The Don't Fragment and the Type Of Service fields should be copied to the outer packet. If the packet size, including the outer header, is greater than the Path MTU, the encapsulator fragments the packet. The decapsulator will reassemble the packet.

IPv4 Residual Deployment (4rd) is an IPv6 transition mechanism for Internet service providers for deployment of Internet Protocol version 6 (IPv6), while maintaining IPv4 service to customers. The protocol and sample applications are specified in RFC 7600.

References

  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 S. Deering; R. Hinden (July 2017). Internet Protocol, Version 6 (IPv6) Specification. IETF. doi: 10.17487/RFC8200 . STD 86. RFC 8200.Internet Standard 86. Obsoletes RFC  2460.
  2. ↑ K. Nichols; S. Blake; F. Baker; D. Black (December 1998). Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. Network Working Group. doi: 10.17487/RFC2474 . RFC 2474.Proposed Standard. Obsoletes RFC  1455 and 1349. Updated by RFC  3168, 3260 and 8436.
  3. ↑ D. Grossman (April 2002). New Terminology and Clarifications for DiffServ. doi: 10.17487/RFC3260 . RFC 3260.Informational. Updates RFC  2474, 2475 and 2597.
  4. 1 2 3 B. Fenner (November 2006). Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers. Network Working Group. doi: 10.17487/RFC4727 . RFC 4727.Proposed Standard.
  5. ↑ K. Ramakrishnan; S. Floyd; D. Black (September 2001). The Addition of Explicit Congestion Notification (ECN) to IP. Network Working Group. doi: 10.17487/RFC3168 . RFC 3168.Proposed Standard. Obsoletes RFC  2481. Updates RFC  2474, 2401 and 793. Updated by RFC  4301, 6040 and 8311.
  6. ↑ S. Amante; B. Carpenter; S. Jiang; J. Rajahalme (November 2011). IPv6 Flow Label Specification. IETF. doi: 10.17487/RFC6437 . ISSN   2070-1721. RFC 6437.Proposed Standard. Obsoletes RFC  3697. Updates RFC  2205 and 2460.
  7. ↑ Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks
  8. 1 2 3 D. Borman; S. Deering; R. Hinden (August 1999). IPv6 Jumbograms. Network Working Group. doi: 10.17487/RFC2675 . RFC 2675.Proposed Standard. Obsoletes RFC  2147.
  9. ↑ C. Partridge; F. Kastenholz (December 1994). Technical Criteria for Choosing IP The Next Generation (IPng). Network Working Group. doi: 10.17487/RFC1726 . RFC 1726.Informational. sec. 2.6.
  10. ↑ T. Heer; P. Jokela; T. Henderson (April 2015). R. Moskowitz (ed.). Host Identity Protocol Version 2 (HIPv2). Internet Engineering Task Force (IETF). doi: 10.17487/RFC7401 . ISSN   2070-1721. RFC 7401.Proposed Standard. Obsoletes RFC  5201. Updated by RFC  8002 and 9374.
  11. ↑ E. Nordmark; M. Bagnulo (June 2009). Shim6: Level 3 Multihoming Shim Protocol for IPv6. Networking Working Group. doi: 10.17487/RFC5533 . RFC 5533.Proposed Standard.
  12. 1 2 3 4 T. Narten (January 2004). Assigning Experimental and Testing Numbers Considered Useful. Network Working Group. doi: 10.17487/RFC3692 . BCP 82. RFC 3692.Best Common Practice. Updates RFC  2434.
  13. ↑ "Internet Protocol Version 6 (IPv6) Parameters: Routing Types". IANA . Retrieved 2021-10-15.
  14. ↑ Philippe Biondi, Arnoud Ebalard (April 2007). "IPv6 Routing Header Security" (PDF). EADS . Retrieved 3 December 2010. Type 0: the evil mechanism...
  15. ↑ J. Abley; P. Savola; G. Neville-Neil (December 2007). Deprecation of Type 0 Routing Headers in IPv6. doi: 10.17487/RFC5095 . RFC 5095.Draft Standard. Updates RFC  2460 and 4294.
  16. ↑ I. Castineyra; N. Chiappa; M. Steenstrup (August 1996). The Nimrod Routing Architecture. doi: 10.17487/RFC1992 . RFC 1992.Informational.
  17. ↑ J. Hui; JP. Vasseur; D. Culler; V. Manral (March 2012). An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL). Internet Engineering Task Force. doi: 10.17487/RFC6554 . RFC 6554.Proposed Standard.
  18. ↑ S. Previdi; J. Leddy; S. Matsushima; D. Voyer (March 2020). C. Filsfils; D. Dukes (eds.). IPv6 Segment Routing Header (SRH). Internet Engineering Task Force (IETF). doi: 10.17487/RFC8754 . ISSN   2070-1721. RFC 8754.Proposed Standard.
  19. ↑ S. Kent (December 2005). IP Authentication Header. Network Working Group. doi: 10.17487/RFC4302 . RFC 4302.Proposed Standard. Obsoletes RFC  2402.
  20. ↑ S. Kent (December 2005). IP Encapsulating Security Payload. Network Working Group. doi: 10.17487/RFC4303 . RFC 4303.Proposed Standard. Obsoletes RFC  2406.
  21. 1 2 F. Gont; V. Manral; R. Bonica (January 2014). Implications of Oversized IPv6 Header Chains. Internet Engineering Task Force (IETF). doi: 10.17487/RFC7112 . ISSN   2070-1721. RFC 7112.Proposed Standard. Updates RFC  2460.
  22. ↑ F. Gont (February 2014). Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard). Internet Engineering Task Force (IETF). doi: 10.17487/RFC7113 . ISSN   2070-1721. RFC 7113.Informational. Updates RFC  6105.
  23. ↑ F. Gont (August 2013). Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery. Internet Engineering Task Force (IETF). doi: 10.17487/RFC6980 . ISSN   2070-1721. RFC 6980.Proposed Standard. Updates RFC  3971 and 4861.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.