Editing IPv6 (section)

==Comparison with IPv4==
On the Internet, data is transmitted in the form of [[network packet]]s. IPv6 specifies a new [[IPv6 packet|packet format]], designed to minimize packet header processing by routers.{{Ref RFC|2460}}{{Ref RFC|1726}} Because the headers of IPv4 packets and IPv6 packets are significantly different, the two protocols are not interoperable. However, most transport and application-layer protocols need little or no change to operate over IPv6; exceptions are application protocols that embed Internet-layer addresses, such as [[File Transfer Protocol]] (FTP) and [[Network Time Protocol]] (NTP), where the new address format may cause conflicts with existing protocol syntax.

===Larger address space===
The main advantage of IPv6 over IPv4 is its larger address space. The size of an IPv6 address is 128 bits, compared to 32 bits in IPv4.<ref name=rfc2460/> The address space therefore has 2<sup>128</sup>=340,282,366,920,938,463,463,374,607,431,768,211,456 addresses (340 [[undecillion]], approximately {{val|3.4|e=38}}). Some blocks of this space and some specific addresses are [[reserved IP addresses|reserved for special uses]].

While this address space is very large, it was not the intent of the designers of IPv6 to assure geographical saturation with usable addresses. Rather, the longer addresses simplify allocation of addresses, enable efficient [[route aggregation]], and allow implementation of special addressing features. In IPv4, complex [[Classless Inter-Domain Routing]] (CIDR) methods were developed to make the best use of the small address space. The standard size of a subnet in IPv6 is 2<sup>64</sup> addresses, about four billion times the size of the entire IPv4 address space. Thus, actual address space utilization will be small in IPv6, but network management and routing efficiency are improved by the large subnet space and hierarchical route aggregation.

===Multicasting===
[[File:IPv6 multicast address stracture-en.svg|thumb|Multicast structure in IPv6]]
[[Multicast]]ing, the transmission of a packet to multiple destinations in a single send operation, is part of the base specification in IPv6. In IPv4 this is an optional (although commonly implemented) feature.{{Ref RFC|1112}} IPv6 multicast addressing has features and protocols in common with IPv4 multicast, but also provides changes and improvements by eliminating the need for certain protocols. IPv6 does not implement traditional [[Broadcast IP address|IP broadcast]], i.e. the transmission of a packet to all hosts on the attached link using a special ''broadcast address'', and therefore does not define broadcast addresses. In IPv6, the same result is achieved by sending a packet to the link-local ''all nodes'' multicast group at address {{IPaddr|ff02::1}}, which is analogous to IPv4 multicasting to address {{IPaddr|224.0.0.1}}. IPv6 also provides for new multicast implementations, including embedding rendezvous point addresses in an IPv6 multicast group address, which simplifies the deployment of inter-domain solutions.{{Ref RFC|3956}}

In IPv4 it is very difficult for an organization to get even one globally routable multicast group assignment, and the implementation of inter-domain solutions is arcane.{{Ref RFC|2908}} Unicast address assignments by a [[local Internet registry]] for IPv6 have at least a 64-bit routing prefix, yielding the smallest subnet size available in IPv6 (also 64 bits). With such an assignment it is possible to embed the unicast address prefix into the IPv6 multicast address format, while still providing a 32-bit block, the least significant bits of the address, or approximately 4.2 billion multicast group identifiers. Thus each user of an IPv6 subnet automatically has available a set of globally routable source-specific multicast groups for multicast applications.{{Ref RFC|3306}}

===Stateless address autoconfiguration (SLAAC)===
{{See also|IPv6 address#Stateless address autoconfiguration (SLAAC)|l1=IPv6 address § Stateless address autoconfiguration}}

IPv6 hosts configure themselves automatically. Every interface has a self-generated link-local address and, when connected to a network, conflict resolution is performed and routers provide network prefixes via router advertisements.{{Ref RFC|4862}} Stateless configuration of routers can be achieved with a special router renumbering protocol.{{Ref RFC|2894}} When necessary, hosts may configure additional stateful addresses via [[DHCPv6|Dynamic Host Configuration Protocol version 6]] (DHCPv6) or static addresses manually.

Like IPv4, IPv6 supports globally unique [[IP address]]es. The design of IPv6 intended to re-emphasize the end-to-end principle of network design that was originally conceived during the establishment of the early Internet by rendering [[network address translation]] obsolete. Therefore, every device on the network is globally addressable directly from any other device.

A stable, unique, globally addressable IP address would facilitate tracking a device across networks. Therefore, such addresses are a particular privacy concern for mobile devices, such as laptops and cell phones.<ref>{{cite web|url=https://www.internetsociety.org/resources/deploy360/2014/privacy-extensions-for-ipv6-slaac/|title=Privacy Extensions for Stateless Address Autoconfiguration in IPv6|author=T. Narten|author2=R. Draves|author3=S. Krishnan|date=September 2007|website=www.ietf.org|access-date=13 March 2017}}</ref> To address these privacy concerns, the SLAAC protocol includes what are typically called "privacy addresses" or, more correctly, "temporary addresses".{{Ref RFC|8981}} Temporary addresses are random and unstable. A typical consumer device generates a new temporary address daily and will ignore traffic addressed to an old address after one week. Temporary addresses are used by default by Windows since XP SP1,<ref>{{Cite web |title=Overview of the Advanced Networking Pack for Windows XP |url=http://support.microsoft.com/kb/817778 |url-status=dead |archive-url=https://web.archive.org/web/20170907013704/https://support.microsoft.com/en-us/help/817778/overview-of-the-advanced-networking-pack-for-windows-xp |archive-date=7 September 2017 |access-date=15 April 2019 |publisher=[[Microsoft]] }}</ref> macOS since (Mac&nbsp;OS&nbsp;X) 10.7, Android since 4.0, and iOS since version 4.3. Use of temporary addresses by Linux distributions varies.<ref>{{Cite web |date=8 August 2014 |title=Privacy Extensions for IPv6 SLAAC |url=https://www.internetsociety.org/resources/deploy360/2014/privacy-extensions-for-ipv6-slaac |url-status=live |archive-url=https://web.archive.org/web/20231023063407/https://www.internetsociety.org/resources/deploy360/2014/privacy-extensions-for-ipv6-slaac/ |archive-date=23 October 2023 |access-date=17 January 2020 |publisher=[[Internet Society]] }}</ref>

Renumbering an existing network for a new connectivity provider with different routing prefixes is a major effort with IPv4.<ref>{{Cite web |last1=Ferguson |first1=P. |last2=Berkowitz |first2=H. |date=January 1997 |title=Network Renumbering Overview: Why would I want it and what is it anyway? |url=https://datatracker.ietf.org/doc/html/rfc2071 |url-status=live |archive-url=https://web.archive.org/web/20240107145323/https://datatracker.ietf.org/doc/html/rfc2071 |archive-date=7 January 2024 |publisher=[[IETF]] |doi=10.17487/RFC2071 |rfc=2071 }}</ref><ref>{{Cite web |last=Berkowitz |first=H. |date=January 1997 |title=Router Renumbering Guide |url=https://datatracker.ietf.org/doc/html/rfc2072 |url-status=live |archive-url=https://web.archive.org/web/20230608094931/https://datatracker.ietf.org/doc/html/rfc2072 |archive-date=8 June 2023 |publisher=[[IETF]] |doi=10.17487/RFC2072 |rfc=2072 }}</ref> With IPv6, however, changing the prefix announced by a few routers can in principle renumber an entire network, since the host identifiers (the least-significant 64 bits of an address) can be independently self-configured by a host.{{Ref RFC|4862}}

The SLAAC address generation method is implementation-dependent. IETF recommends that addresses be deterministic but semantically opaque.<ref>{{Cite IETF|rfc=8064|title=Recommendation on Stable IPv6 Interface Identifiers|first1=Alissa|last1=Cooper|first2=Fernando|last2=Gont|first3=Dave|last3=Thaler}}</ref>

===IPsec===
[[Internet Protocol Security]] (IPsec) was originally developed for IPv6, but found widespread deployment first in IPv4, for which it was re-engineered. IPsec was a mandatory part of all IPv6 protocol implementations,<ref name=rfc2460/> and [[Internet Key Exchange]] (IKE) was recommended, but with RFC 6434 the inclusion of IPsec in IPv6 implementations was downgraded to a recommendation because it was considered impractical to require full IPsec implementation for all types of devices that may use IPv6.{{ref RFC|6434|quote=Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE.  This document updates that recommendation by making support of the IPsec Architecture RFC4301 a SHOULD for all IPv6 nodes. |p=17}} However, as of RFC 4301 IPv6 protocol implementations that do implement IPsec need to implement IKEv2 and need to support a minimum set of [[Cryptography|cryptographic algorithms]]. This requirement will help to make IPsec implementations more interoperable between devices from different vendors. The IPsec Authentication Header (AH) and the Encapsulating Security Payload header (ESP) are implemented as IPv6 extension headers.<ref>{{Cite book|title=IPv6 Essentials: Integrating IPv6 into Your IPv4 Network|author=Silvia Hagen|publisher=O'Reilly Media|year=2014|isbn=978-1-4493-3526-7|page=196|edition=3rd|location=Sebastopol, CA|oclc=881832733}}</ref>

===Simplified processing by routers===
The packet header in IPv6 is simpler than the IPv4 header. Many rarely used fields have been moved to optional header extensions. The IPv6 packet header has simplified the process of packet forwarding by [[Router (computing)|routers]]. Although IPv6 packet headers are at least twice the size of IPv4 packet headers, processing of packets that only contain the base IPv6 header by routers may, in some cases, be more efficient, because less processing is required in routers due to the headers being aligned to match common [[Word (computer architecture)|word sizes]].<ref name=rfc2460/><ref name=rfc1726/> However, many devices implement IPv6 support in software (as opposed to hardware), thus resulting in very bad packet processing performance.<ref>{{cite web|title=IPv6 Security Assessment and Benchmarking|first=E.|last=Zack|date=July 2013|url=http://www.ipv6hackers.org/meetings/ipv6-hackers-1}}</ref> Additionally, for many implementations, the use of Extension Headers causes packets to be processed by a router's CPU, leading to poor performance or even security issues.<ref name="draft-gont-v6ops-ipv6-ehs-packet-drops-03">{{Cite web |last=Gont |first=F. |date=March 2016 |title=Operational Implications of IPv6 Packets with Extension Headers |url=https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03 |url-status=live |archive-url=https://web.archive.org/web/20231027170015/https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03 |archive-date=27 October 2023 |publisher=[[IETF]] }}</ref>

Moreover, an IPv6 header does not include a checksum. The [[IPv4 header checksum]] is calculated for the IPv4 header, and has to be recalculated by routers every time the [[time to live]] (called [[hop limit]] in the IPv6 protocol) is reduced by one. The absence of a checksum in the IPv6 header furthers the [[end-to-end principle]] of Internet design, which envisioned that most processing in the network occurs in the leaf nodes. Integrity protection for the data that is encapsulated in the IPv6 packet is assumed to be assured by both the [[link layer]] or error detection in higher-layer protocols, namely the [[Transmission Control Protocol]] (TCP) and the [[User Datagram Protocol]] (UDP) on the [[transport layer]]. Thus, while IPv4 allowed UDP datagram headers to have no checksum (indicated by 0 in the header field), IPv6 requires a checksum in UDP headers.

IPv6 routers do not perform [[IP fragmentation]]. IPv6 hosts are required to do one of the following: perform [[Path MTU Discovery]], perform end-to-end fragmentation, or send packets no larger than the default [[maximum transmission unit]] (MTU), which is 1280 [[octet (computing)|octets]].

===Mobility===
Unlike mobile IPv4, [[mobile IPv6]] avoids [[triangular routing]] and is therefore as efficient as native IPv6. IPv6 routers may also allow entire subnets to move to a new router connection point without renumbering.{{Ref RFC|3963}}

===Extension headers===
[[File:IPv6 headers sequence-en.svg|thumb|Several examples of IPv6 extension headers]]

The IPv6 packet header has a minimum size of 40 octets (320 bits). Options are implemented as extensions. This provides the opportunity to extend the protocol in the future without affecting the core packet structure.<ref name="rfc2460"/> However, RFC 7872 notes that some network operators drop IPv6 packets with extension headers when they traverse transit [[Autonomous system (Internet)|autonomous systems]].

====Jumbograms====
IPv4 limits packets to 65,535 {{nowrap|(2<sup>16</sup> − 1)}} octets of payload. An IPv6 node can optionally handle packets over this limit, referred to as [[jumbogram]]s, which can be as large as 4,294,967,295 {{nowrap|(2<sup>32</sup> − 1)}} octets. The use of jumbograms may improve performance over high-[[Maximum transmission unit|MTU]] links. The use of jumbograms is indicated by the Jumbo Payload Option extension header.{{Ref RFC|2675}}