IPv6

from Wikipedia, the free encyclopedia
IPv6 in the TCP / IP protocol stack :
application HTTP IMAP SMTP DNS ...
transport TCP UDP
Internet IPv6
Network access Ethernet Token
bus 		Token
ring 		FDDI ...

The Internet Protocol Version 6 ( IPv6 ), formerly also called Internet Protocol Next Generation (IPng), is a method for the transmission of data in packet-switching computer networks , especially the Internet, standardized by the Internet Engineering Task Force (IETF) since 1998 . In these networks, the data are sent in packets in which, according to a layer model, control information from various network protocols is interleaved and transmitted around the actual user data . IPv6 is a protocol of the network layer (layer 3 of the OSI model as part of) the Internet protocol family is a valid across subnets across 128- bit - addressing of the participating network elements ( hosts or routers ) ago. It also uses these addresses to regulate the packet forwarding process between subnetworks ( routing ). The subnetworks can be operated with different protocols of the lower layers, which take their different physical and administrative conditions into account.

In the course of time, IPv6 is to completely replace version 4 of the Internet Protocol on the Internet , as it offers a significantly larger number of possible addresses that are in danger of being exhausted with IPv4. Critics fear that anonymity on the Internet will be pushed back by the more stable and more extensive public addressing that is now possible. Proponents criticize the hesitant introduction of IPv6 in view of the expired IPv4 address allocation in all continents except Africa . Access to Google by users from Germany used IPv6 in around 52% in December 2019.

Reasons for a New Internet Protocol

Number of available IPv4 address blocks between 1995 and 2015
Daily assigned IPv4 addresses according to RIRs (Regional Internet Registries)

In theory, IPv4 would offer an address space of just over four billion IP addresses (2 32 = 256 4 = 4,294,967,296), which the IANA divides into 256/8 networks, of which 221 are largely released for use, i.e. assigned to RIRs, for example were. The remaining 35/8 networks were reserved for special purposes (e.g. 127/8 for loopback) or for the future, which mathematically reduces the available area to 3,707,764,736. However, after some sub-areas (such as 100.64.0.0/10) of the / 8 networks that are actually released have been reserved for other purposes, this inventory is reduced by a further 5.506.830 IP addresses, so that the actually usable address range, e.g. B. Addressing computers and other devices directly, ultimately drops to 3,702,257,906 IP addresses. In the early days of the Internet , when there were only a few computers that needed an IP address, this was perfectly adequate. You even had larger address ranges u. a. reserved for large organizations, leaving even fewer free addresses for private individuals.

In the course of time, however, the Internet became more and more widespread and the world population has long been larger than the number of available IPv4 addresses. In addition, a website , among other things, already permanently occupies one or more addresses. So a better system was needed that could provide many more addresses without technical makeshifts. For more information see Address Scarcity of IPv4 .

As a result of short-sighted allocation practice, there is strong fragmentation in the IPv4 address space . With IPv6, however, a more far-sighted practice was used.

For these reasons, the IETF began work on IPv6 as early as 1995. In December 1998, IPv6 was officially named the successor to IPv4 with the publication of RFC 2460 on the Standards Track . In July 2017, the IETF published RFC 8200 , which replaces the original version.

The main new features of IPv6 include:

The main motivation for increasing the address space is to maintain the end-to-end principle , which is a central design principle of the Internet: Only the end nodes of the network should carry out active protocol operations, the network between the end nodes is only for forwarding the data packets responsible. (The Internet here differs significantly from other digital data transmission networks such as GSM .) For this it is necessary that every network node can be uniquely addressed globally.

Common methods today such as Network Address Translation (NAT), which currently circumvent the shortage of IPv4 addresses, violate the end-to-end principle. They only enable the computers connected in this way to establish outgoing connections. However, they cannot easily be contacted from the Internet. Also rely IPsec or protocols on higher layers such. B. FTP and SIP partly on the end-to-end principle and are only functional with NAT to a limited extent or with additional solutions.

For home users in particular, IPv6 means a paradigm shift: Instead of being assigned a single IP address by the provider and connecting several devices to the Internet via NAT, the globally unique IP address space is made available for an entire subnet so that each of its Devices can obtain an IP address from this. This makes it easier for end users to actively participate in the network by offering services. In addition, the problems that arise with NAT due to address rewriting are eliminated.

When choosing the address length and thus the size of the available address space, several factors had to be taken into account. On the one hand, the source and destination IP addresses must also be transmitted for each data packet. Longer IP addresses lead to increased protocol overhead, i. H. the ratio between the actual user data and the protocol data required for the transfer decreases. On the other hand, the future growth of the Internet should be taken into account. In addition, to prevent fragmentation of the address space, it should be possible to only have to assign address space to an organization once. In order to simplify the process of auto-configuration , renumbering and multihoming , it was also desirable to reserve a fixed part of the address for the network-independent, unique identification of a network node. The last 64 bits of the address therefore usually consist of the EUI-64 of the network interface of the node.

Address structure of IPv6

IPv6 addresses are 128  bits long (IPv4: 32 bits). The first 64 bits constitute the so-called prefix , the last 64 bits make up on particular cases, one for the network interface ( English network interface ) unique interface identifier . A network interface can be reached under several IP addresses; This is usually done by means of its link-local address and a globally unique address . The same interface identifier can thus be part of several IPv6 addresses that are linked to the same network interface with different prefixes. In particular, this also applies to prefixes that may be from different Internet providers; this simplifies the multihoming process.

Since the generation of the interface identifier from the globally unique MAC address enables the tracking of users, the privacy extensions (PEX, RFC 4941 ) were developed to remove this permanent link between the user identity and the IPv6 addresses. By generating the interface identifier randomly and changing regularly, part of the anonymity of IPv4 is to be restored.

Since in the private sector in the IPv6 address both the interface identifier and the prefix alone can safely identify a user, for reasons of data protection in connection with the privacy extensions, a dynamically assigned by the provider, e.g. B. A daily changing prefix is ​​desirable. (A static address assignment is usually accompanied by an entry in the public Whois database.) As described above, it is basically possible to use both IPv6 addresses from dynamic and from permanently assigned prefixes in parallel on the same network interface. In Germany, the German IPv6 Council has formulated data protection guidelines that also provide for the dynamic assignment of IPv6 prefixes.

Address notation

The textual notation of IPv6 addresses is described in section 2.2 of RFC 4291 :

  1. IPv6 addresses are usually noted in hexadecimal (IPv4: decimal ), with the number divided into eight blocks of 16 bits each (4 hexadecimal digits). These blocks are separated by colons: listed separately (IPv4 points) 2001:0db8:85a3:08d3:1319:8a2e:0370:7344.
  2. Leading zeros within a block can be left out: 2001:0db8:0000:08d3:0000:8a2e:0070:7344is synonymous with 2001:db8:0:8d3:0:8a2e:70:7344.
  3. One or more consecutive blocks with a value of 0 (or 0000 ) may be omitted. This is indicated by two consecutive colons: 2001:db8:0:0:0:0:1428:57abis synonymous with 2001:db8::1428:57ab.
  4. The reduction by rule 3 may only be carried out once, that is, at most one contiguous group of zero blocks may be replaced in the address. The address 2001:0db8:0:0:8d3:0:0:0may therefore either be reduced 2001:db8:0:0:8d3::or 2001:db8::8d3:0:0:0abbreviated; 2001:db8::8d3::is not allowed because this is ambiguous and wrongly z. B. could also be 2001:db8:0:0:0:8d3:0:0interpreted as. The reduction must not be carried out multiple times even if the result would be unambiguous because exactly one single 0 was shortened in each case. It is advisable to shorten the group with the most zero blocks.
  5. The conventional decimal notation with dots as separators can also be used for the last two blocks (four bytes , i.e. 32 bits) of the address. So is ::ffff:127.0.0.1an alternate spelling for ::ffff:7f00:1. This notation is mainly used when the IPv4 address space is embedded in the IPv6 address space.

URL notation of IPv6 addresses

In a URL , the IPv6 address is enclosed in square brackets, e.g. B .:

  • http://[2001:0db8:85a3:08d3::0370:7344]/

This notation prevents the wrong interpretation of port numbers as part of the IPv6 address:

  • http://[2001:0db8:85a3:08d3::0370:7344]:8080/

Net notation

IPv6 networks are written in CIDR notation. To do this, the first address (or the network address) and the length of the prefix in bits are noted, separated by a slash. For example stands 2001:0db8:1234::/48for the network with addresses 2001:0db8:1234:0000:0000:0000:0000:0000to 2001:0db8:1234:ffff:ffff:ffff:ffff:ffff. The size of an IPv6 network (or subnet) in terms of the number of assignable addresses in this network must therefore be a power of two. Since a single host can also be viewed as a network with a 128-bit prefix, host addresses are sometimes written with an appended “/ 128”.

Division of the IPv6 address space

Address assignment

Typically, an Internet provider (ISP) receives the first 32 bits (or less) as a network from a Regional Internet Registry (RIR). This area is further divided into subnets by the provider . The length of the allocation to end customers is left to the ISP; the minimum allocation of a / 64 network is required. Older documents (e.g. RFC 3177 ) suggest the allocation of / 48 networks to end customers; In exceptional cases, networks larger than / 48 or several / 48 networks can be allocated to an end customer. Information about the allocation of IPv6 networks can be obtained from the Whois services of the respective RIRs. In their RPSL databases there are inet6num and route6 objects and in many other object types attributes for multi-protocol extension (mp) with specification of the address family (afi) for specifying the new protocol.

A 64-bit prefix is ​​usually assigned to an individual network segment , which then forms the address together with a 64-bit interface identifier. The interface identifier can either be created from the MAC address of the network interface or otherwise uniquely assigned; the exact procedure is described in RFC 4291 , Appendix A.

Has z. B. a network device has the IPv6 address

2001:0db8:85a3:08d3:1319:8a2e:0370:7347/64,

that's the prefix

2001: 0db8: 85a3: 08d3 :: / 64

and the interface identifier

1319: 8a2e: 0370: 7347 .

The provider probably got the network from the RIR

2001: 0db8 :: / 32

assigned and the end customer from the provider possibly the network

2001: 0db8: 85a3 :: / 48 ,

or just

2001: 0db8: 85a3: 0800 :: / 56 .

Address ranges

There are different IPv6 address ranges with special tasks and different properties. These are usually already signaled by the first bits of the address. Unless otherwise specified, the areas are defined in RFC 4291 and RFC 5156 . Unicast addresses characterize communication between a network node and exactly one other network node; One-to-many communication is mapped using multicast addresses.

Special addresses

  • ::/128or in the written variant 0:0:0:0:0:0:0:0/128, is the unspecified address. It must not be assigned to a host, but rather indicates the absence of an address. It is used, for example, by an initializing host as the sender address in IPv6 packets as long as it has not yet received its own address. However, by specifying this address, server programs can also cause them to listen to all addresses of the host. This corresponds to 0.0.0.0/32under IPv4.
  • ::/0or in the written variant 0:0:0:0:0:0:0:0/0denotes the standard route (default route) which is used if no entry is found in the routing table. This corresponds to 0.0.0.0/0under IPv4.
  • ::1/128or in the written variant 0:0:0:0:0:0:0:1/128, is the address of your own location ( loopback address, which is usually linked to localhost ). For this purpose, IPv4 is used almost exclusively 127.0.0.1/32from the address space 127.0.0.0–127.255.255.255, even though not just an IP address, but an entire / 8 subnet is reserved for the loopback network.

Link-local unicast addresses

Link-local addresses are only valid within closed network segments. A network segment is a local network, formed with switches or hubs , up to the first router. The area " fe80::/10" is reserved for this . These 10 bits are followed by 54 bits with the value 0, so that the link-local addresses always have the prefix " fe80::/64":

10 bits 54 bits 64 bits
1111111010 0 Interface ID

Link-local addresses are used to address nodes in closed network segments as well as for auto-configuration or neighbor discovery. This means that there is no need to configure a DHCP server for automatic address assignment in a network segment. Link-local addresses are comparable to APIPA addresses in the network 169.254.0.0/16.

If a device is to communicate using one of these addresses, the zone ID must also be specified, since a link-local address can exist more than once on a device. For a single network interface, an address would look something like this: or . fe80::7645:6de2:ff:1%1fe80::7645:6de2:ff:1%eth0

Site Local Unicast (deprecated)

fec0::/10( fec0…bis feff…), also site local addresses , were the successors of the private IP addresses (for example 192.168.x.x). They were only allowed to be routed within the same organization. The choice of the address space used within fec0::/10was arbitrary for an organization. When merging formerly separate organizations or when a VPN connection was established between actually separate networks numbered with Site Local Addresses, the address spaces at the different locations could therefore overlap. For this and other reasons, Site Local Addresses according to RFC 3879 have been deprecated since September 2004 and will disappear from future standards. New implementations must treat this address range as a global unicast address. The successor to the site-local addresses are the Unique Local Addresses , which are described in the next section.

Unique local unicast

fc00::/7( fc00…until fdff…). For private addresses there are the Unique Local Addresses (ULA), described in RFC 4193 . Currently only the prefix fdfor locally generated ULA is intended. The prefix fcis reserved for globally assigned, unique ULAs. The prefix is ​​then followed by 40 bits that act as a unique site ID. This site ID is to be generated randomly with the ULA with the prefix fd and is therefore only very likely to be unique. In the case of the globally assigned ULA, however, it is definitely unique ( RFC 4193 does not specify any concrete implementation of the assignment of globally unique site IDs). The site ID is followed by a 16-bit subnet ID, which specifies a network within the site.

An example ULA would be fd9e:21a7:a92c:2323::1. Here is fdthe prefix for locally generated ULAs, 9e:21a7:a92ca one-time randomly generated 40-bit value and 2323an arbitrarily selected subnet ID.

The use of likely unique site IDs has the advantage that, for example, when setting up a tunnel between separately configured networks, address collisions are very unlikely. Furthermore, it is achieved that packets which are sent to an unreachable site are very likely to end up in vain instead of being sent to a local host that happens to have the same address.

If only ULA addresses are used in a dual stack with IPv4 in a private network, the majority of clients prefer the IPv4 address with a DNS resolution, even if an AAAA record exists, since it can be assumed that with a ULA address the public IPv6 address space can never be reached. In practice, this means that in private networks (especially when using NAT6) in the dual stack, ULA addresses are not recommended.

There is a proposed standard that describes guidelines for registrars (IANA, RIR), specifically their operation and address allocation rules. However, such a "ULA-Central" has not yet been established.

Both RFC 4193 and the proposed standard are identical with regard to the address format and the above-mentioned generation algorithm.

Multicast

ff00::/8( ff…) stand for multicast addresses. The multicast prefix is ​​followed by 4 bits for flags and 4 bits for the scope.

The following combinations are currently valid for the flags:

  • 0: Permanently defined, well-known multicast addresses (assigned by the IANA )
  • 1: (T bit set) Transient (temporarily) or dynamically assigned multicast addresses
  • 3: (P-bit set, forces the T-bit) Unicast-Prefix-based multicast addresses ( RFC 3306 )
  • 7: (R bit set, forces P and T bit) Multicast addresses which contain the address of the rendezvous point ( RFC 3956 )

The following areas of validity are defined:

  • 1: interface-local, these packets never leave the interface . ( Loopback )
  • 2: link-local, are never forwarded by routers and can therefore not leave the subnet.
  • 4: admin local, the smallest area whose delimitation has to be specially administered in the routers.
  • 5: sitelocal, may be routed, but not by border routers .
  • 8: local to the organization, the packets may also be forwarded by border routers, but remain "in the company" (the routing protocol must take appropriate precautions for this).
  • e: global multicast that can be routed anywhere.
  • 0, 3, f: Reserved areas
  • the remaining areas are not assigned and may be used by administrators to define further multicast regions.

Examples of well-known multicast addresses:

  • ff01::1, ff02::1: All Nodes addresses. Corresponds to the broadcast.
  • ff01::2, ff02::2, ff05::2: All router addresses, addresses all routers in an area.

Global unicast

All other addresses are considered global unicast addresses. Of these, however, only the following areas have so far been assigned:

  • ::/96(96 0 bits) stood for IPv4 compatibility addresses, which contained the IPv4 address in the last 32 bits (this only applied to global IPv4 unicast addresses). These were defined for the transition, but declared deprecated in RFC 4291 of February 2006 .
  • 0:0:0:0:0:ffff::/96(80 0 bits, followed by 16 1 bits) stands for IPv4 mapped (shown) IPv6 addresses. The last 32 bits contain the IPv4 address. A suitable router can convert these packets between IPv4 and IPv6 and thus connect the new world with the old.
  • 2000::/3( 2000…to 3fff…; which corresponds to the binary prefix 001) stand for the global unicast addresses assigned by the IANA , i.e. routable and globally unique addresses.
  • 2001-Addresses are given to providers who distribute them to their customers.
  • Addresses from 2001::/32(i.e. starting with 2001:0:) are used for the Teredo tunnel mechanism .
  • Addresses from 2001:db8::/32are used for documentation purposes, for example in this article, and do not designate actual network users.
  • 2002-Prefixes indicate addresses of the 6to4 tunnel mechanism .
  • With 2003, 240, 260, 261, 262, 280, 2a0, 2b0and 2c0starting addresses of Regional Internet Registries awarded (RIRs); these address ranges are z. In some 2001::/16cases, however, not yet allocated to the share as is the case with.
  • 3ffe::/16-Addresses were used for the test network 6Bone ; this address range was returned to the IANA in accordance with RFC 3701 .

Functionality

Auto configuration

Using Stateless Address Autoconfiguration (SLAAC, specified in RFC 4862 ), a host can automatically set up a functioning Internet connection. To do this, he communicates with the routers responsible for his network segment in order to determine the necessary configuration.

procedure

For the initial communication with the router, the host assigns itself a link-local address which, in the case of an Ethernet interface, can be calculated from its hardware address, for example. This means that a device can use the Neighbor Discovery Protocol (NDP, see also ICMPv6 functionality ) to search for the routers in its network segment. This is done by sending a request to the multicast address ff02::2via which all routers in a segment can be reached ( router solicitation ).

In response to such a request, a router sends information about available prefixes , i.e. information about the address ranges from which a device is allowed to assign unicast addresses to itself . The packets that carry this information are called router advertisements . They have ICMPv6 type 134 (0x86) and have information about the lifetime, the MTU and the prefix of the network. The host appends the interface identifier also used for the link-local address to such a prefix.

In order to prevent the duplicate assignment of an address, the mechanism Duplicate Address Detection (DAD - recognition of doubly assigned addresses) is provided. A device may only select unassigned addresses during auto configuration. The DAD process also runs without user intervention via NDP.

Validity information

When assigning address prefixes, routers can specify limited validity times: Valid Lifetime and Preferred Lifetime . The specified prefix may be used for communication within the valid lifetime; Within the Preferred Lifetime, this prefix should be preferred to another whose Preferred Lifetime has already expired (but whose Valid Lifetime has not yet expired). Routers regularly send router advertisements to all hosts in a network segment for which they are responsible, by means of which the prefix validity times are refreshed; by changing the advertisements, hosts can be renumbered. If the router advertisements are not authenticated via IPsec, it is not possible to reduce the validity of a prefix already known to a host to less than two hours.

Relationship between auto configuration and DHCPv6

The IPv6 autoconfiguration differs conceptually from DHCP or DHCPv6 . While the address assignment by DHCPv6 (defined in RFC 3315 ) is referred to as " Stateful Address Configuration" (analogously: logged address assignment, for example by a DHCP server), the auto-configuration is a " Stateless Address (Auto) Configuration", since the devices themselves assign an address yourself and this assignment is not logged.

Using the auto-configuration, no information on host names, domain names, DNS, NTP servers, etc. can be communicated to clients unless they support specific extensions of NDP. The additional use of a DHCPv6 server has established itself as an alternative; this provides the required additional information, but does not take care of the address assignment. In this case, one speaks of stateless DHCPv6 (see RFC 3736 ). The client can use the managed flag in the response to an NDP router solicitation to indicate that it should make a DHCPv6 request and thus obtain the additional information.

Renumbering and multihoming

Under IPv4, renumbering (changing the IP address range) is problematic for networks of a certain size, even if mechanisms such as DHCP help. In particular, the transition from one provider to the next without a "hard" switchover at a fixed point in time is difficult, as this is only possible if the network is multihomed for a certain period of time, i.e. a network from more than one provider with Internet access at the same time. Connection and IP address ranges is supplied. Bypassing renumbering under IPv4 using the Border Gateway Protocol (BGP) leads to fragmentation of the address space. So many, comparatively small networks get into the routing tables in the core area of ​​the Internet, and the routers there must be designed accordingly.

The process of renumbering, however, was taken into account when designing IPv6; it is dealt with in RFC 4076 . Mechanisms such as IPv6 auto-configuration help with this. The parallel operation of several IP address ranges is also easier under IPv6 than under IPv4, as described in the Address Structure section above. In RFC 3484 it is specified how the selection of the source and destination addresses should take place during communication and how they can be influenced if several are available. In addition, this selection may also be made at the application level or by those that have yet to be created, e.g. B. the connection quality taking into account mechanisms. The aim is, among other things, to enable the operator of a network to easily switch between providers or even to permanently operate several providers in parallel in order to promote competition, increase reliability or to distribute data traffic over lines from several providers.

Mobile IPv6

Mobile IP was integrated into IPv6 as an extension of the IPv6 standard under the name "Mobile IPv6" ( RFC 6275 ). Communication always takes place virtually regardless of the current position of the nodes. Mobile IP end devices can thus be reached under the same IP address everywhere, for example in the home network and at a conference. Routing tables would normally have to be changed in a laborious manner. Instead, Mobile IPv6 uses a shadow computer (“ home agent ”) that represents the mobile device in its home network. Incoming packets are tunneled to the current address (“care-of-address”) of the mobile device by this shadow computer. The home agent receives the current care-of-address of the mobile device via “binding updates”, which the device sends to the home agent as soon as it has received a new address in the foreign network being visited. Mobile IP is also specified for IPv4; In contrast to this specification, however, Mobile IPv6 does not require a foreign agent to register the presence of mobile devices in the foreign network.

Header format

The header area of ​​an IPv6 packet

In contrast to IPv4, the IP header data area ( header ) in IPv6 has a fixed length of 40 bytes (320 bits). Optional, rarely used information in so-called extension headers (ger .: Extension headers (Engl.) Between the IPv6 header area and the actual payload Payload ) embedded. According to RFC 2460 , the header data area of ​​an IPv6 packet consists of the following fields:

field length content
version 4 bit IP version number (6)
Traffic class 8 bit Quality of Service : Bits 0–5 are used for DSCP , bits 6–7 for ECN . According to IANA , the same allocation applies as for IPv4 ToS .
Flow label 20 bits Value also used for QoS or real-time applications. Parcels with the same flow label are treated equally.
Payload Length 16 bit Length of the IPv6 packet content (without header data area, but including the extension header data) in bytes
Next header 8 bit Identifies the type of the next header data area . This can either designate an extension header data area (see next table) or a protocol of a higher layer (English: Upper Layer Protocol ), such as B. TCP (type 6) or UDP (type 17).
Hop limit 8 bit Maximum number of intermediate steps via router that a packet can travel; is decreased by one when going through a router ("hop"). Packets with zero as the hop limit are discarded. It corresponds to the Time to Live (TTL) field in IPv4.
Source Address 128 bit Sender address
Destination Address 128 bit address of the recipient

As referred to in the Next Header field, some extension headers and a placeholder are defined:

Surname Type size description RFCs
Hop-by-hop options 0 variable Contains options that must be observed by all IPv6 devices that the packet traverses. Is z. B. used for jumbograms . RFC 2460 , RFC 2675
Routing 43 variable The route of the packet through the network can be influenced by this header; it is used, among other things, for Mobile IPv6 . RFC 2460 , RFC 6275 , RFC 5095
fragment 44 64 bit The parameters of a fragmentation can be specified in this header . RFC 2460
Authentication Header (AH) 51 variable Contains data that can ensure the confidentiality of the packet (see IPsec ). RFC 4302
Encapsulating Security Payload (ESP) 50 variable Contains data for the encryption of the packet (see IPsec ). RFC 4303
Destination Options 60 variable Contains options that only have to be taken into account by the target computer of the package. RFC 2460
Mobility 135 variable Contains data for Mobile IPv6 . RFC 6275
No next header 59 empty This type is just a placeholder to indicate the end of a header stack. RFC 2460

Most IPv6 packets should do without extension headers ; apart from the Destination Options header , these can only appear once in each packet. If there is a routing extension header in the packet, another Destination Options header may be placed in front of it . The sequence in a chaining is that of the table with the exception mentioned. All Extension Headers contain a Next-Header field in which the next Extension Header or the Upper Layer Protocol is named.

The sizes of these headers are always multiples of 64 bits, and most of the fields in the header data areas are aligned to 64-bit boundaries in order to speed up memory access in the router. In addition (in contrast to IPv4 ), checksums are no longer calculated over the IP header data, only the error correction in layers 2 and 4 is used.

Package sizes

The Maximum Transmission Unit (MTU) in an IPv6 network must not be less than 1280 bytes. The Path MTU (PMTU) does not fall below this value either, and packets up to this size can be guaranteed to be transmitted without fragmentation . Minimal IPv6 implementations rely on this case.

An IPv6-capable computer must be able to receive packets composed of fragments with a size of at least 1500 bytes. For IPv4 this value is only 576 bytes. At the other extreme, an IPv6 packet, even fragmented according to the payload length field in the IPv6 header, must not exceed the size of 65,575 bytes including header data, as this field is 16 bits long (2 16  - 1 bytes plus 40 bytes header data). However, RFC 2675 provides the option of the hop-by-hop extension header to create packets with sizes of up to 4,294,967,335 bytes, so-called jumbograms . However, this requires adjustments in higher-level protocols, such as B. TCP or UDP , as these often only define 16 bits for size fields. In addition, the payload length must be set to 0 in the IPv6 header for every packet that contains a jumbogram .

Extended ICMP functionality

ICMPv6 ( protocol type 58 ) provides essential functions for the functioning of IPv6. Prohibiting all ICMPv6 packets in an IPv6 network using filters is therefore normally not feasible.

In particular, the Address Resolution Protocol (ARP) is being replaced by the Neighbor Discovery Protocol (NDP), which is based on ICMPv6. This makes intensive use of link-local unicast addresses and multicast , which must be mastered by every host. As part of the NDP, the automatic address assignment and the automatic assignment of one or more default routes are also handled via ICMPv6, so it provides most of the functions that were explained above under IPv6 auto-configuration . NDP can refer to the possibility of further configuration through DHCPv6 , which however uses UDP packets.

The router no longer fragments long IPv6 packets ; instead, ICMPv6 messages prompt the sender to send smaller packets, also using the fragment extension header (see Maximum Transmission Unit (MTU) in this context ) . Ideally, an IPv6 host or an application should perform a Path MTU Discovery in accordance with RFC 1981 before sending a large number of IPv6 packets , in order to be able to send packets with the maximum possible size.

IPv6 and DNS

Because of the length of the IP addresses, which places higher demands on human memory than IPv4 addresses, IPv6 is particularly dependent on a functioning Domain Name System (DNS). RFC 3596 defines the resource record (RR) type AAAA (pronounced: Quad-A ), which, like an A resource record for IPv4, resolves a name into an IPv6 address. The reverse lookup , i.e. the resolution of an IP address into a name, still works via the RR type PTR , only for IPv6 the reverse domain is no longer IN-ADDR.ARPA as for IPv4, but IP6.ARPA and the Delegation of subdomains is no longer done on 8-bit but on 4-bit borders.

An IPv6-capable computer usually searches for a name using DNS first for the RR type AAAA, then for the RR type A. According to the Default Policy Table in RFC 3484 , communication via IPv6 is preferred over IPv4 if it is found that both protocols are available for a connection. The order of application of the protocols is mostly also in the operating system and on the application level, e.g. B. in the browser , adjustable.

All thirteen root name servers and at least two name servers of most top-level domains can be reached via IPv6. The transmitted protocol is independent of the transmitted information. In particular, you can ask a name server for AAAA RRs via IPv4. However, providers of large portal sites are thinking about only answering DNS queries that are made via IPv6 with AAAA resource records in order to avoid problems with incorrectly programmed software.

Transition Mechanisms

IPv6 transition mechanisms
4in6 Tunneling from IPv4 to IPv6
6in4 Tunneling from IPv6 to IPv4
6over4 Transport of IPv6 data packets between dual-stack nodes over an IPv4 network
6to4 Transport of IPv6 data packets over an IPv4 network (obsolete)
AYIYA Anything In Anything
Dual stack Network nodes with IPv4 and IPv6 in parallel operation
Dual-Stack Lite (DS-Lite) Like dual stack, but with global IPv6 and carrier NAT IPv4
6rd IPv6 rapid deployment
ISATAP Intra-Site Automatic Tunnel Addressing Protocol (deprecated)
Teredo Encapsulation of IPv6 packets in IPv4 UDP -Datenpaketen
NAT64 Translation of IPv4 addresses into IPv6 addresses
464XLAT Translation from IPv4 to IPv6 to IPv4 addresses
SIIT Stateless IP / ICMP translation

IPv4 and IPv6 can be operated in parallel on the same infrastructure, especially on the Internet . As a rule, no new lines, network cards or devices are required for the transition, provided that suitable operating systems are available. There are currently hardly any devices that can handle IPv6 but not IPv4 at the same time. However, so that devices that are exclusively connected via IPv4 can also communicate with devices that are exclusively connected via IPv6, they need translation procedures .

Various mechanisms have been developed to enable a simple transition from IPv4 to IPv6 communication on the Internet. IPv6 is usually switched on without switching off IPv4. A basic distinction is made between the following three mechanisms:

  • Parallel operation ( dual stack )
  • Tunnel mechanisms
  • Translation process

Parallel operation and tunnel mechanisms require that the operating systems of the connected computers can handle both protocols.

There are already areas of the Internet that can only be reached via IPv6, other parts that are connected via both protocols and large parts that rely exclusively on IPv4. In the following, the first two areas are collectively referred to as IPv6 Internet.

Dual stack

With this procedure, all interfaces involved are assigned at least one IPv6 address in addition to the IPv4 address and the necessary routing information is assigned to the computers. The computers can then communicate independently using both protocols, i. H. Exchange data with both IPv4 and IPv6-capable systems. This procedure should be the rule, it currently fails because some routers (mostly the access servers of the Internet provider or the home routers of the customers) on the way to the IPv6 Internet have not yet activated or support IPv6 forwarding .

Dual-Stack Lite (DS-Lite)

DS-Lite

Because of the scarce IPv4 addresses, the IETF has developed the “Dual-Stack Lite” ( RFC 6333 ) mechanism . The customer is only provided with globally routable IP addresses via IPv6. (Both IPv6 and IPv4 are provided in regular dual-stack operation.)

Private IPv4 addresses are used in the customer's LAN (analogous to the NAT procedure ). Instead of a NAT translation, the IPv4 packets are then encapsulated in IPv6 packets by the Customer Premises Equipment (CPE) . The CPE uses its global IPv6 connection to transport the packets into the carrier-grade NAT (CGN) of the Internet service provider , which has global IPv4 addresses. Here the IPv6 packet is unpacked and the original IPv4 packet is restored. Then the IPv4 packet is converted to a public IP address with NAT and routed to the public IPv4 Internet. The carrier-grade NAT uniquely identifies sessions by recording the public IPv6 address of the CPE, the private IPv4 address and TCP or UDP port numbers.

However, this DS-Lite implementation leads to problems for the end customer: On the one hand, IPv4-based port releases are no longer possible with port-based protocols (e.g. TCP, UDP), since the packets to the public IP address are already filtered out by the provider . Services that are offered on a DS-Lite connection cannot be reached by devices that cannot establish IPv6 connections. The CGN gateway only understands and forwards certain protocols , which makes the use of other IP-based protocols difficult or even impossible.

Tunnel mechanisms

Protocol 41: IPv6 packets are packed directly into IPv4 packets, which are then sent to a special tunnel server

In order to bridge routers that do not forward IPv6 on their way to the IPv6 Internet, there are a number of tunnel mechanisms . In doing so, IPv6 packets in the user data of other protocols, mostly IPv4, are transmitted to a tunnel remote station located in the IPv6 Internet. There the IPv6 packets are extracted and transmitted to the destination via IPv6 routing. The way back works analogously. Each tunnel method is dependent on the quality of the tunneling protocol: the route of the packets to the destination is usually not optimal because of the detour via the tunnel remote end and the possible payload decreases because more header data has to be transmitted.

The classic way is to apply for such a remote station for private use free of charge from a so-called tunnel broker . This remote station remains fixed and the same IPv6 address range is always assigned via the tunnel. For example, 6in4 uses protocol type 41 to encapsulate IPv6 directly in IPv4. For Linux , such a tunnel can be created using the interface configuration tools. With Windows this is no longer possible since Windows 10 April 2018 (1803). The 6over4 or ISATAP procedures are more complicated .

The 6to4 mechanism does not require any agreement with a remote station, because it uses ( anycast ) IPv4 addresses defined in the Internet , and the tunneled packets are delivered to the nearest remote station and processed there. The connected computer then has an IPv6 address range available, which is calculated from its public IPv4 address. Such a tunnel can also be set up on current Linux computers with a public IPv4 address in a few simple steps.

If a computer is in a private IPv4 address range and NAT takes place when connecting to the Internet , mechanisms such as AYIYA or Teredo can help. These protocols usually encapsulate IPv6 packets as user data in UDP packets. If an administrator allows these protocols, network security can quickly be endangered if the packet filter cannot interpret the user data as IPv6 packets and thus other packet filter rules may be circumvented.

It is also possible to transport IPv6 using more general tunneling methods such as GRE , L2TP or MPLS , especially if routing protocols such as IS-IS have to be transmitted in parallel.

Translation process

If IPv6 cannot be activated on a device or if there are no longer enough IPv4 addresses available, methods such as Network Address Translation / Protocol Translation (NAT-PT, RFC 2766 ; now deprecated) or Transport Relay Translation (TRT, RFC 3142 ) can be used. become necessary to translate between the two protocols. Proxy servers also offer the possibility of communication between the two worlds for some higher-layer protocols.

The NAT64 method offers a quite satisfactory solution as long as the main requirement is to forward connections initiated by IPv6 hosts to IPv4 hosts.

Technical implementation

The RFC 6434 (IPv6 Node Requirements) provides an overview of features that should implement all IPv6 devices to ensure maximum interoperability. Reference is made in this document to the respective specifications.

Operating systems

Many operating systems now support IPv6, an overview follows. The support provided by the firmware or the operating systems on the (DSL) routers at end customers and the access servers at the providers is also decisive for a tunnel-free connection . Systems (e.g. CDN ) for load distribution , as they are e.g. B. are used for large websites, were and will be supplemented piece by piece by IPv6.

AIX
IPv6 has been implemented since AIX 4 Version 4.3, and Mobile IPv6 has also been implemented since AIX 5L Version 5.2.
Android
Android supports IPv6 since version 2.1, but not via the 3GPP interface. IPv6 APN have been supported since 2.3.4. Most of the end devices lacked support in the UMTS chipset (or firmware). From version 4.0 Ice Cream Sandwich, Privacy Extensions are activated by default.
BSD variants
IPv6 has been supported by the BSDs for a very long time and very comprehensively (for example at FreeBSD since March 2000, at NetBSD since December 2000 and at OpenBSD since mid-2000). The support is largely thanks to the KAME project , which had been developing a free protocol stack for IPv6 and IPsec for BSD operating systems since 1998 .
Cisco
IPv6 is supported experimentally from IOS version 12.2T, and productively from versions 12.3 and 12.4. On older devices and cards, however, due to the hardware configuration, IPv6 forwarding is only possible in software, i.e. with the help of the main processor, which significantly reduces the performance compared to IPv4.
HP-UX
IPv6 has been part of the basic system since version 11iv2, earlier 11.x versions can be made IPv6-capable with TOUR (Transport Optional Upgrade Release).
iOS (Apple iPhone, iPad, iPod Touch, Apple TV)
Apple devices with iOS version 4 or higher support IPv6 in dual-stack mode. Privacy extensions are only supported from version 4.3.
Juniper
The manufacturer supports IPv6 on its routers in the JunOS operating system from version 5.1. IPv6 forwarding happened early on in hardware, i.e. without burdening the routing engine (the main processor). For firewall systems, both on the ScreenOS series (ScreenOS <6.x) and the SRX series (JunOS <10.x), IPv6 is supported.
Linux
The kernel since version 2.6 offers a productive usable IPv6 support on a similar level as the BSD derivatives. The 2.4 kernel offers support for IPv6 that has been shown to be experimental, but it lacks important properties such as IPSec and data protection extensions (Privacy Extensions, RFC 4941 ). Most Linux distributions have the privacy extensions switched on in the delivery state with kernels from version 3.x, but these can be deactivated manually. An experimental IPv6 implementation is also included in kernel version 2.2.
Mac OS X
Since version 10.2, Mac OS X also includes support for IPv6 based on KAME . Only since version 10.3 can IPv6 be configured via the GUI . IPv6 is enabled by default and supports DNS AAAA records. The Airport Extreme consumer routers belonging to the Apple product family set up a 6to4 tunnel as standard and function as IPv6 routers. The privacy extensions have been activated by default since 10.7 (Lion) .
OpenVMS
With HP TCP / IP Services for OpenVMS Version 5.5, HP OpenVMS (Version 8.2 or higher) supports IPv6.
Solaris
Since version 8, support for IPv6 has also been included in a limited form in the operating system from Sun Microsystems (implementation and large parts of the operating system applications still require IPv4 to be configured), which is available for SPARC and i386 computer architectures . The configuration is analogous to the Linux and xBSD systems.
Symbian OS
IPv6 has been an integral part of the system since version 7.0. There are only a few parameters to configure via the GUI .
Windows
Since Windows XP Service Pack 1, Windows has brought a protocol stack for IPv6 with it. Since then, support for IPv6 has been steadily expanded by Microsoft and adapted to current developments. Since Windows 8, IPv6 has been used as the preferred protocol if the host is connected to a dual-stack network.
Windows Server
As of Windows Server 2003, Windows Server includes a “Production Quality” protocol stack. Support for IPv6 has been continuously expanded by Microsoft in the versions of Windows Server that have been released since then.
Windows Phone
Windows Phone 7 and 7.5 do not support IPv6. An IPv6 stack is only integrated in version 8 and higher.
z / OS
IBM z / OS has fully supported IPv6 since September 2002, and in 1998 there was an experimental stack for its predecessor, OS / 390.

Routing

While static routing for IPv6 can be set up in the same way as IPv4, there are some changes for the dynamic routing protocols . The Border Gateway Protocol with the Multiprotocol Extensions (defined in RFC 4760 ) is used between autonomous systems . As interior gateway protocol are OSPF version 3, IS-IS with the support of IPv6 TLVs and RIPng as open standards. Most manufacturers support multi-topology routing for IS-IS , i.e. simultaneous routing for both address families even if the IPv4 and IPv6 network do not exactly overlap. OSPFv3 implements this in a very new standard ( RFC 5838 ) via different instances for the different protocols, but was originally only intended for IPv6. Another way is to use different routing protocols for the two topologies , e.g. OSPFv2 for IPv4 and IS-IS for IPv6.

One or more default routes can be transferred to end systems via auto-configuration or DHCPv6. With DHCPv6-PD ( Prefix Delegation ), prefixes can also be distributed for the purpose of further routing, for example to customer routers.

Since neither RSVP nor LDP are sufficiently standardized for IPv6, MPLS networks must continue to rely on signaling using IPv4, but can, depending on the implementation, transport IPv6 traffic. PIM is suitable for IPv6 multicast routing .

Packet filters and firewalls

For IPv6, all filter rules in firewalls and packet filters must be recreated. Depending on whether the filtering process is processing the IPv6 data traffic at all and depending on its default policy, a firewall can let IPv6 through unhindered. Some antivirus programs also have add-ons that block the traffic e.g. B. Search for signatures on certain TCP ports. For Linux, the filtering of IPv6 can be configured with the program ip6tables (since version 3.13 of the Linux kernel also nft / nftables ).

Significant changes in the structure of the filters compared to IPv4 can result if they deal with ICMP or ICMPv6 , as its protocol number , type and code assignments and functionality change.

The Next Header field in the IPv6 header is not suitable for identifying higher-layer protocols in the same way as the Protocol field in the IPv4 header, because when extension headers are used, their value changes, for example in the event of fragmentation.

Some aspects of NAT were often seen in the past as a security function; In IPv6, NAT is only provided in exceptional cases, however. RFC 4864 describes procedures that map these aspects of NAT with IPv6 techniques; For example, the existing NAT function in some implementations of not forwarding new incoming connections to computers in the home network can be replaced by a stateful packet filter in the router. This can generally reject incoming connections or only allow them for certain areas of the home network.

Application software

For applications such as web browsers or e-mail programs, changes to the programming are necessary so that they can communicate via IPv6. This has already happened for the most important programs that are supplied with current operating systems, but not for less frequently used applications.

In most cases only minor changes are necessary, since the applications are based on higher-layer protocols and these hardly change. In many operating systems, however, the programming interfaces required the application to explicitly request sockets for IPv4 communication. Newer interfaces are usually designed in such a way that IPv6-supporting applications automatically also support IPv4. If the applications process content with URLs as they occur in HTTP or in the Session Initiation Protocol (SIP), they must support the URL notation of IPv6 addresses .

In some cases changes are necessary in order not to reduce the performance of the application. For example, a possibly determined, reduced Path MTU can be transferred to the application in order to avoid fragmentation or the Maximum Segment Size (MSS) in the TCP header must be reduced with IPv6 compared to IPv4. Many programming languages ​​make special libraries available to simplify the use of the new protocol.

administration

The main work of the implementation is on the administrative level: Administration and support must be trained, documentation and configurations, e.g. B. for routing , firewalls , network monitoring , the domain name system and possibly DHCP , must be created and maintained for both protocols during the transition phase. In many documentation or error messages, a distinction must be made between IPv4 and IPv6, where a few years ago only IP was mentioned. The structure of the IP network will initially be doubled.

Often times, IP addresses have a higher level meaning. They appear in log files or netflow data, some of which are further processed with scripts such as Webalizer in order to generate views, statistics or accounts. The layout and the scripts for generating pages such as Wikipedia's “version history” also had to be adapted to the IPv6 notation, as users are sometimes identified by their IP address. Based on rights management, such as B. in many databases, to the access through fixed IP addresses, this must be taken into account when activating IPv6.

Dissemination and projects

Number of autonomous systems with published IPv6 routes and number of published prefixes between 2003 and 2015
Number of new assignments of IPv6 address space to ISPs since 2000

IPv6 is only slowly gaining acceptance in practical use. Address allocation for IPv6 went from experimental to regular operation in July 1999 and more and more ISPs are operating IPv6 as well as IPv4 in their network.

At peak times, 150 Gbit / s IPv6 traffic is transported via the Internet node AMS-IX , which is around 3% of the total traffic of 5 Tbit / s that occurs there. On websites in dual-stack operation, 27% of the accesses worldwide are measured via IPv6, for accesses from Germany the IPv6 share is 46%.

The global IPv6 routing table contained around 33,000 prefixes as of October 2016, and approximately 26% of all Autonomous Systems available on the Internet participate in global IPv6 routing. Most of the large exchange points for Internet traffic allow and promote the exchange of IPv6 via their infrastructure in addition to IPv4. At DE-CIX , around 70 to 80 of a total of 240 providers used IPv6 in April 2008.

The IPv6 Forum was founded in July 1999, the German IPv6 Council in December 2007. The IPv6 Forum Project IPv6-Ready awards the IPv6 logo in three different stages, which measure the implementation of the protocol. The website also lists all IPv6-capable operating systems.

Currently, 74% of all IPv4 addresses are assigned directly to the North American Internet registries and some US institutions and companies, while for example all of China - with over 250 million Internet users (as of June 2008) - years ago only about this many IP addresses owned like a University of California campus (December 2004).

On the part of the end user IPv6 also not required because have now been more or less successfully ported back out of the larger address range of important new features of IPv6 to IPv4 (such as IPsec , QoS , multicast , renumbering and auto-configuration are also using DHCP possible) - it there is no widespread application that would only work with IPv6.

Early projects

In Germany, the JOIN project of the University of Münster was in charge of the experiments on IPv6. JOIN and the Association for the Promotion of a German Research Network ( DFN ) have set up the "6WiN", the first IPv6 backbone in Germany. The 6WiN was a ring-shaped backbone through Germany with a cross connection between Essen and Berlin. At the same time, Deutsche Telekom set up its own IPv6 backbone between the Darmstadt, Münster and Berlin locations and offered its business customers a connection to it as part of a showcase project. This network was connected to the 6WiN in Münster and Berlin. The German central access to the experimental IPv6 network 6Bone , which was switched off on June 7, 2005 as part of the scheduled gradual termination of the worldwide 6Bone operation, was also located in Münster . On January 1, 2006, IPv6 operation in the German research network was handed over from the JOIN project to the DFN-NOC.

The University of Vienna , which also operates the Vienna Internet Exchange (VIX) and several DNS servers for the “.at” zone, played a decisive role in the IPv6 migration in Austria. Both facilities can be reached via IPv6 or offer academic customers an IPv6 connection. The first commercial provider in Austria was next layer .

Connection of end users

The so-called World IPv6 Day took place on June 8, 2011 , on which dual-stack operation was tested on several large websites. The test went largely without any problems. At the Internet hub DE-CIX , a significantly increased volume of IPv6 traffic was measured, which continued after June 8th.

As part of a further day of action on June 6, 2012, the World IPv6 Launch Day , more than 1400 companies worldwide permanently updated their websites to the latest standard so that they can be reached with IPv4 and IPv6.

Since September 25, 2012, Deutsche Telekom has also been providing IPv6 to DSL end customer connections. First of all, the so-called IP connections were made IPv6-capable, initially with new customers. The analog and ISDN connections, which have now been deactivated, did not receive IPv6. In the current service description for the use of LTE at a firmly agreed address (“MagentaZuhause via radio” as an alternative to DSL), Deutsche Telekom provides e.g. For example, it is clear that only IPv4 addresses can be reached via this Internet access.

Users of other types of connection such as the cellular network or cable are increasingly being supplied with IPv6.

Problems

Historical

Especially at the beginning, the IPv6 standards were changed frequently, which meant that already completed implementations had to be adapted several times.

Addressing the network nodes

The biggest cut was the introduction of the IEEE standard EUI-64 for the interface identifier as part of the addresses. In order to guarantee the uniqueness of an address in the network in a simple way, the MAC address of an interface was previously adopted unchanged in the IPv6 address, now the MAC address is written in a modified form in the IPv6 address according to EUI-64; due to a mix-up in RFC 3513, the algorithm for calculating EUI-64 names from EUI-48 names is incorrectly applied to MAC-48 names.

The procedures described lead to a static, host-specific part of the IPv6 address of an auto-configured IPv6 node. Data protectionists were concerned that this would allow users to be identified across different networks and that this could be exploited for marketing measures or government interventions, for example. The IETF therefore subsequently defined the data protection extensions ( privacy extensions ) according to RFC 3041 , later RFC 4941 (see also address structure of IPv6 ). These privacy extensions generate a random host-specific part during the auto configuration via SLAAC. However, since the first 64 bits of the IPv6 address of a network (e.g. a household) are retained, further protection must be ensured by regularly changing the network-specific part (as is the case today with DSL connections).

Integration into the domain name system

For a long time, the DNS adaptation for the integration of IPv6 was inconsistent. In 1995, the record type AAAA was initially defined in RFC 1886 for the resolution of DNS names into IPv6 addresses, which is functionally equivalent to the A record for IPv4. In 2000, AAAA was replaced in RFC 2874 by record type A6, which was primarily intended to simplify renumbering by mapping the IP address piece by piece to the DNS, but was never free from technical problems. In 2003, the A6 method was downgraded to "experimental" in RFC 3596 , and AAAA became the new, old standard.

The reverse resolution ("reverse" resolution) of IPv6 addresses caused even more difficulties, since, due to the change in standards, PTR records existed in two different zones, below ip6.arpa and ip6.int. Due to the traditional use of the TLD .arpa for backward resolution in IPv4, the first variant prevailed against ip6.int, whereupon the delegation of ip6.int was deleted in June 2006.

The resolution is completely independent of the protocol type of the request: If a DNS request is made via IPv4, an AAAA record can also be returned, and name servers accessible via IPv6 also provide information on IPv4 addresses (A records).

Current

Link-local addresses

A possible design weakness of IPv6 is that the address spaces for link-local addresses are generally not separated. If you want to use link-local addresses at the application level for communication between computers in the same network segment, the problem arises that it is not sufficient for them to enter the IP address in the target field, but also a zone index according to RFC 4007 ( in most cases an interface ) has to be specified, since the link-local address space of several interfaces overlaps. It therefore depends on whether the IPv6 support of the application used knows the concept of zone indices, whether link-local addresses can be used for this purpose.

Auto configuration and DNS

The interaction of the IPv6 auto-configuration mechanism with the Domain Name System has resulted in problems to this day. Originally, there was no option whatsoever to inform network nodes about the DNS servers to be used and other DNS-related information such as DNS search paths as part of the autoconfiguration, as is usual for IPv4 in the context of DHCP . Today there are essentially two solutions to the problem:

  • Using the managed flag in router advertisements, network nodes can be instructed to ask a DHCPv6 server for further configuration. DHCPv6 server can use the multicast address ff02::1:2and ff05::1:3be addressed. In contrast to DHCP, the DHCPv6 server does not have to keep logs of such requests, so the configuration can still be stateless.
  • The NDP specification allows additional fields to be specified in router advertisements. The so-called RDNSS ( Recursive DNS Server ) and DNSSL ( DNS Search List ) extensions specify a way of sending DNS servers and DNS search paths as part of router advertisements.

In particular, RDNSS and DNSSL were only standardized in November 2010 with the appearance of RFC 6106 .

Support for the above solutions is inconsistent among the different implementations. For example, Microsoft Windows Vista and 7 only support DHCPv6 and all methods are available for Linux systems, but are often not preinstalled by distributors. However, since version 10.7 (Lion) Mac OS X supports both DHCPv6 and RDNSS.

privacy

Data protectionists criticize IPv6 for the fact that every device connected to the Internet could get a fixed IP address, so that all pages visited could be determined years later and the visitor could be identified. Technically, this can be made more difficult by the privacy extensions.

Even 64-bit addresses would have represented an unimaginable supply of well over 10 19 addresses - a billion by 10 billion, almost a billion generations of humanity. With the 128 bits that are used in IPv6, there are even 10 38 . In theory, this means that every atom of every person in the world could be assigned its own address.

Since there can never be a shortage, technical devices such as IPv4 have become superfluous, which means that an Internet user was sometimes assigned a different IP address every few hours. With IPv6, private individuals practically have a fixed IP address, which is a boon for web tracking . Every IPv6 address can be assigned to a household or even a mobile phone very reliably. This allows z. B. a search engine or online shop identify people and link information about them without gaining access to external computer systems. This originally required so-called " tracking cookies ". With sufficient spread of IPv6 addresses, this procedure becomes obsolete.

In order to get around this problem, data protectionists want to oblige Internet service providers by law to offer dynamic addresses also under IPv6.

IPv5

There is no protocol called IPv5. However, the IANA has reserved the IP version number 5 for the Internet Stream Protocol Version 2 (ST2, defined in RFC 1819 ), which should have improved real-time capabilities compared to IPv4, but then discontinued its development in favor of IPv6 and RSVP for cost-benefit considerations has been.

See also

literature

Basic specifications

  • RFC 2460 . - Internet Protocol, Version 6 (IPv6) Specification . (Updated by RFC 8200  - replaced in July 2017 - English).
    • RFC 8200 . - Internet Protocol, Version 6 (IPv6) Specification . July 2017. (Replaces RFC 2460 - English).
  • RFC 4861 . - Neighbor Discovery for IP version 6 (IPv6) . (English).
  • RFC 4862 . - IPv6 Stateless Address Autoconfiguration . (English).
  • RFC 4291 . - IP version 6 addressing architecture . (English).
  • RFC 5942 . - IPv6 subnet model . (English).

Secondary literature

  • Reiko Kaps: WAN driveway - go online with the IPv6 network . In: c't , Heise, Hannover 2008.6.
  • Silvia Hagen: IPv6. Basics - functionality - integration . Sunny Edition, Maur 2009, ISBN 978-3-9522942-2-2 .
  • Joseph Davies: Understanding IPv6 . 2nd Edition. Microsoft Press, Redmond 2008, ISBN 978-0-7356-2446-7 (English).
  • Anatol Badach: Technology of the IP networks. TCP / IP including IPv6. How it works, protocols and services . Hanser reference book. 2nd Edition. Hanser, Munich 2007, ISBN 3-446-21935-8 .
  • Mathias Hein: IPv6, The Migration Guide . Franzis, Point 2003, ISBN 3-7723-7390-9 .
  • Herbert Wiese: The new Internet protocol IPv6 . Hanser reference book. Hanser, Munich 2002, ISBN 3-446-21685-5 .
  • Hans P. Dittler: IPv6. The new internet protocol. Technology, application, migration. 2nd Edition. Dpunkt, Heidelberg 2002, ISBN 3-89864-149-X .
  • Christian Huitema: IPv6 - the new generation . Addison-Wesley, Munich 2000, ISBN 3-8273-1420-8 .

Web links

Commons : IPv6  - collection of pictures, videos and audio files

Individual evidence

  1. ↑ IPv4 address pool in North America finally exhausted .
  2. ↑ Privacy advocates concerned about IPv6 . Heise.de
  3. ↑ AFRINIC .
  4. ↑ NGO and OECD Highlight that IPv6 Deployment is Too Slow . Regional Internet Registries, press release.
  5. ↑ a b Google per country IPv6 adoption .
  6. ↑ iana.org .
  7. ↑ IPv4 - Charts and Explanations | CIDR / EU: see sections IV.–V. .
  8. ↑ RFC 6434  Section 11 (English).
  9. ↑ IPsec was also specified for IPv4, but implementation is optional there, whereas it was initially prescribed for IPv6 in RFC 4294 . However, this requirement was withdrawn with RFC 6434 .
  10. ↑ a b see for example RFC 2775  Section 5.1.
  11. ↑ RFC 3724  Section 2 (English).
  12. ↑ RFC 2993  Section 6 (English).
  13. ^ Stefan Wintermeyer: Asterisk 1.4 + 1.6 . 1st edition. Addison-Wesley, Munich 2009, Chapter 8. das-asterisk-buch.de .
  14. ↑ A discussion of the problem can be found in an Internet draft by W. Eddy: Comparison of IPv4 and IPv6 Header Overhead .
  15. ↑ Guidelines IPv6 and data protection . ( Memento of December 7, 2012 in the Internet Archive ) German IPv6 Council.
  16. ↑ S. Kawamura:  RFC 5952  - A Recommendation for IPv6 Address Text Representation . August 2010. Section 4.2.2 (English).
  17. ↑ RFC 3986  Section 3.2.2 (English).
  18. ↑ IPv6 Address Allocation and Assignment Policy from APNIC , ARIN , RIPE NCC , Section 4.3.
  19. ↑ IPv6 Address Allocation and Assignment Policy , Section 5.4.1 .
  20. ↑ IPv6 Address Allocation and Assignment Policy , Section 5.4.2 .
  21. ↑ RFC 4291  Section 2.5.4 (English).
  22. ↑ RFC 4291  Section 2.5.2 (English).
  23. ↑ RFC 4291  Section 2.5.6 (English).
  24. ↑ IPv6 addresses. In: heise online. Retrieved November 9, 2018 (German).
  25. ↑ Internet Protocol Version 6 Address Space. Retrieved November 9, 2018 .
  26. ↑ See also the script on kame.net ( memento of the original from June 1, 2009 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. (Online version: sixxs.net ). @1@ 2Template: Webachiv / IABot / www.kame.net
  27. ↑ IPv6 Masquerading Router - Why should the ULA prefix be changed? NAT6, openwrt.org
  28. ↑ Centrally Assigned Unique Local IPv6 Unicast Addresses ( English ) tools.ietf.org. Retrieved May 10, 2019.
  29. ↑ a b RFC 2373  Section 2.7 (English).
  30. ↑ RFC 3307  Section 4.1 (English).
  31. ↑ RFC 4291  Section 2.7 (English).
  32. ↑ Internet Protocol Version 6 Multicast Addresses . IANA.
  33. ↑ IPv6 Unicast Address Assignments . IANA.
  34. ↑ RFC 2462  Section 5.4 (English).
  35. ↑ RFC 2461  Section 4.6.2 (English).
  36. ↑ RFC 2462  Section 4 (English).
  37. ↑ RFC 4862  section 5.5.3 (point e) - English).
  38. ^ Herbert Wiese: The new Internet protocol IPv6 . Hanser Verlag , Munich 2002. ISBN 3-446-21685-5 , p. 197.
  39. ↑ "Hack" for IPv6 accessibility of large content providers . heise.de
  40. ↑ Peter Bieringer: Linux IPv6 Howto, Chapter 9.3 .
  41. ↑ Peter Bieringer: Linux IPv6 Howto, Section 9.4 .
  42. ↑ RFC 4966 . - Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status . (English).
  43. ↑ IPv6 test operation for heise online - make the website IPv6-capable via proxy .
  44. ↑ AKAMAI (PDF)
  45. ↑ AWS .
  46. ↑ azure .
  47. ↑ Cloudflare .
  48. ↑ Android Issue 3389: Full IPv6 Android support .
  49. ↑ Susanne Kirchhoff: Data protection and IPv6: You really surf that anonymously. June 3, 2014, accessed March 29, 2015 .
  50. ↑ Iljitsch van Beijnum: iOS 4 IPv6 ( Memento of the original from May 14, 2012 in the Internet Archive ) Info: The archive link was automatically inserted and not yet checked. Please check the original and archive link according to the instructions and then remove this notice. . @1@ 2Template: Webachiv / IABot / lists.apple.com
  51. ↑ iOS 4.3: Apple improves data protection . hot networks.
  52. ↑ IPv6: Activate Privacy Extensions . hot networks.
  53. ↑ Connecting with IPv6 in Windows 8. MSDN Blog, accessed August 12, 2012 .
  54. ↑ IPv6 support in Microsoft Products and Services. (No longer available online.) MS TechNet, archived from the original on April 22, 2016 ; accessed on September 11, 2013 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / technet.microsoft.com
  55. ↑ Vishwas Manral: RSVP-TE IPv6 .
  56. ↑ Vishwas Manral: Updates to LDP for IPv6 .
  57. ↑ RFC 4890 . (English).
  58. ↑ IPv6 Local Network Protection with Cisco IOS Routers and Switches . ( Memento June 8, 2009 on the Internet Archive ) Cisco Systems.
  59. ↑ Apple enforces IPv6 compatibility for iOS apps .
  60. ↑ Supporting IPv6-only networks .
  61. ↑ Delegation of IPv6 address space . IANA, mailing list entry from July 14, 1999.
  62. ↑ AMS-IX sFlow Statistics .
  63. ↑ AMS-IX Traffic Statistics .
  64. ↑ Google IPv6 Adoption .
  65. ^ Geoff Huston: AS2 IPv6 BGP Table Data .
  66. ^ RIPE NCC. RIPE.
  67. ↑ APA, AP: Internet Protocol IPv6 is finally moving . derstandard.at, May 6, 2008.
  68. ↑ IPv6 Forum website .
  69. ↑ IPv6ready website .
  70. ↑ China now has the largest number of Internet users in the world . Heise Online, July 4, 2008.
  71. ↑ Liu Baijia: China launches new generation Internet . In: China Daily , December 27, 2004.
  72. ^ Vienna Internet Exchange .
  73. ↑ Official website of the World IPv6 Day .
  74. ↑ World IPv6 Day: A lot of attention and hardly any problems . hot networks.
  75. ↑ World IPv6 Day: Unexpected aftermath . hot networks.
  76. ↑ World IPv6 Launch Day: Content providers add IPv6 . heise.de, June 5, 2012, accessed on June 6, 2012.
  77. ↑ IPv6 standard: An invisible revolution for the Internet at welt.de, June 5, 2012, accessed on June 6, 2012.
  78. ↑ Twitter report from Telekom .
  79. ↑ Telekom: No IPv6 for contracts with analog and ISDN telephony . heise.de, December 6, 2012.
  80. ↑ Description of services MagentaZuhause via radio; Status February 2020 ( Memento from February 15, 2020 in the Internet Archive ; PDF).
  81. ↑ Telekom starts IPv6 introduction in the mobile network .
  82. ↑ Kabel Deutschland converts Internet access to IPv6 .
  83. ↑ Discussion of EUI-64, EUI-48 and MAC-48 on the IETF IPng working group mailing list.
  84. ↑ Privacy advocates concerned about IPv6 . Heise.de
  85. ↑ IPv6 - The next generation Internet protocol .
  86. ↑ IPv6 ( memento of the original from December 20, 2013 in the Internet Archive ) Info: The archive link was automatically inserted and not yet checked. Please check the original and archive link according to the instructions and then remove this notice. datenschutzraum.de @1@ 2Template: Webachiv / IABot / www.datenschutzraum.de
  87. ↑ IP addresses are becoming scarce - IPv6 is the future .
  88. ↑ Dynamic address allocation by law also under IPv6 . golem.de