Английская Википедия:IPv6 address

Материал из Онлайн справочника
Перейти к навигацииПерейти к поиску

Шаблон:Short description

Файл:Ipv6 address leading zeros.svg
Decomposition of an IPv6 address into its binary form

An Internet Protocol Version 6 address (IPv6 address) is a numeric label that is used to identify and locate a network interface of a computer or a network node participating in a computer network using IPv6. IP addresses are included in the packet header to indicate the source and the destination of each packet. The IP address of the destination is used to make decisions about routing IP packets to other networks.

IPv6 is the successor to the first addressing infrastructure of the Internet, Internet Protocol version 4 (IPv4). In contrast to IPv4, which defined an IP address as a 32-bit value, IPv6 addresses have a size of 128 bits. Therefore, in comparison, IPv6 has a vastly enlarged address space.

Addressing methods

IPv6 addresses are classified by the primary addressing and routing methodologies common in networking: unicast addressing, anycast addressing, and multicast addressing.Шаблон:Ref RFC

A unicast address identifies a single network interface. The Internet Protocol delivers packets sent to a unicast address to that specific interface.

An anycast address is assigned to a group of interfaces, usually belonging to different nodes. A packet sent to an anycast address is delivered to just one of the member interfaces, typically the nearest host, according to the routing protocol's definition of distance. Anycast addresses cannot be identified easily, they have the same format as unicast addresses, and differ only by their presence in the network at multiple points. Almost any unicast address can be employed as an anycast address.

A multicast address is also used by multiple hosts that acquire the multicast address destination by participating in the multicast distribution protocol among the network routers. A packet that is sent to a multicast address is delivered to all interfaces that have joined the corresponding multicast group. IPv6 does not implement broadcast addressing. Broadcast's traditional role is subsumed by multicast addressing to the all-nodes link-local multicast group Шаблон:IPaddr. However, the use of the all-nodes group is not recommended, and most IPv6 protocols use a dedicated link-local multicast group to avoid disturbing every interface in the network.

Address formats

An IPv6 address consists of 128 bits.[1] For each of the major addressing and routing methodologies, various address formats are recognized by dividing the 128 address bits into bit groups and using established rules for associating the values of these bit groups with special addressing features.

Unicast and anycast address format

Unicast and anycast addresses are typically composed of two logical parts: a 64-bit network prefix used for routing, and a 64-bit interface identifier used to identify a host's network interface.

General unicast address format (routing prefix size varies)
bits 48 (or more) 16 (or fewer) 64
field routing prefix subnet ID interface identifier

The network prefix (the routing prefix combined with the subnet ID) is contained in the most significant 64 bits of the address. The size of the routing prefix may vary; a larger prefix size means a smaller subnet ID size. The bits of the subnet ID field are available to the network administrator to define subnets within the given network. The 64-bit interface identifier is automatically established randomly, obtained from a DHCPv6 server, or assigned manually. (Historically, it was automatically generated from the interface's MAC address using the modified EUI-64 format, but this method is now not recommended for privacy reasons.Шаблон:Ref RFC)

Unique local addresses are addresses analogous to IPv4 private network addresses. <section begin=ULA-format/>

Unique local address format
bits 7 1 40 16 64
field prefix L random subnet ID interface identifier

The prefix field contains the binary value 1111110. The L bit is one for locally assigned addresses; the address range with L set to zero is currently not defined. The random field is chosen randomly once, at the inception of the Шаблон:IPaddr routing prefix.

<section end=ULA-format/> A link-local address is also based on the interface identifier, but uses a different format for the network prefix.

Link-local address format
bits 10 54 64
field prefix zeroes interface identifier

The prefix field contains the binary value 1111111010. The 54 zeroes that follow make the total network prefix the same for all link-local addresses (Шаблон:IPaddr link-local address prefix), rendering them non-routable.

Multicast address format

Шаблон:Further

Multicast addresses are formed according to several specific formatting rules, depending on the application.

General multicast address format
bits 8 4 4 112
field prefix flg sc group ID

For all multicast addresses, the prefix field holds the binary value 11111111.

Currently, three of the four flag bits in the flg field are defined;[1] the most-significant flag bit is reserved for future use.

Multicast address flags[2]
bit flag Meaning when 0 Meaning when 1
8 reserved reserved reserved
9 R (Rendezvous)Шаблон:Ref RFC Rendezvous point not embedded Rendezvous point embedded
10 P (Prefix)Шаблон:Ref RFC Without prefix information Address based on network prefix
11 T (Transient)[1] Well-known multicast address Dynamically assigned multicast address

The four-bit scope field (sc) is used to indicate where the address is valid and unique.

In addition, the scope field is used to identify special multicast addresses, like solicited node.

Solicited-node multicast address format
bits 8 4 4 79 9 24
field prefix flg sc zeroes ones unicast address

The sc(ope) field holds the binary value 0010 (link-local). Solicited-node multicast addresses are computed as a function of a node's unicast or anycast addresses. A solicited-node multicast address is created by copying the last 24 bits of a unicast or anycast address to the last 24 bits of the multicast address.

Unicast-prefix-based multicast address format[3][4]
bits 8 4 4 4 4 8 64 32
field prefix flg sc res riid plen network prefix group ID

Link-scoped multicast addresses use a comparable format.Шаблон:Ref RFC

Representation

An IPv6 address is represented as eight groups of four hexadecimal digits, each group representing 16 bitsШаблон:Efn The groups are separated by colons (:). An example of an IPv6 address is: Шаблон:Block indent

The standards provide flexibility in the representation of IPv6 addresses. The full representation of eight four-digit groups may be simplified by several techniques, eliminating parts of the representation. In general, representations are shortened as much as possible. However, this practice complicates several common operations, namely searching for a specific address or an address pattern in text documents or streams, and comparing addresses to determine equivalence. For mitigation of these complications, the IETF has defined a canonical format for rendering IPv6 addresses in text:Шаблон:Ref RFC

  • The hexadecimal digits are always compared in case-insensitive manner, but IETF recommendations suggest the use of only lower case letters. For example, 2001:db8::1 is preferred over 2001:DB8::1;
  • Leading zeros in each 16-bit field are suppressed, but each group must retain at least one digit. For example, Шаблон:IPaddr is rendered as Шаблон:IPaddr;
  • The longest sequence of consecutive all-zero fields is replaced with two colons (::). If the address contains multiple runs of all-zero fields of the same size, to prevent ambiguities, it is the leftmost that is compressed. For example, Шаблон:IPaddr is rendered as Шаблон:IPaddr rather than as Шаблон:IPaddr. :: is not used to represent just a single all-zero field. For example, Шаблон:IPaddr is shortened to Шаблон:IPaddr, but Шаблон:IPaddr is rendered as Шаблон:IPaddr.

These methods can lead to very short representations for IPv6 addresses. For example, the localhost (loopback) address, Шаблон:IPaddr, and the IPv6 unspecified address, Шаблон:IPaddr, are reduced to Шаблон:IPaddr and Шаблон:IPaddr, respectively.

During the transition of the Internet from IPv4 to IPv6, it is typical to operate in a mixed addressing environment. For such use cases, a special notation has been introduced, which expresses IPv4-mapped and IPv4-compatible IPv6 addresses by writing the least-significant 32 bits of an address in the familiar IPv4 dot-decimal notation, whereas the 96 most-significant bits are written in IPv6 format. For example, the IPv4-mapped IPv6 address Шаблон:IPaddr is written as Шаблон:IPaddr, thus expressing clearly the original IPv4 address that was mapped to IPv6.

Networks

An IPv6 network uses an address block that is a contiguous group of IPv6 addresses of a size that is a power of two. The leading set of bits of the addresses are identical for all hosts in a given network, and are called the network's address or routing prefix.

Network address ranges are written in CIDR notation. A network is denoted by the first address in the block (ending in all zeroes), a slash (/), and a decimal value equal to the size in bits of the prefix. For example, the network written as Шаблон:IPaddr starts at address Шаблон:IPaddr and ends at Шаблон:IPaddr.

The routing prefix of an interface address may be directly indicated with the address using CIDR notation. For example, the configuration of an interface with address Шаблон:IPaddr connected to subnet Шаблон:IPaddr is written as Шаблон:IPaddr.

Address block sizes

The size of a block of addresses is specified by writing a slash (/) followed by a number in decimal whose value is the length of the network prefix in bits. For example, an address block with 48 bits in the prefix is indicated by Шаблон:IPaddr. Such a block contains 2128 − 48 = 280 addresses. The smaller the value of the network prefix, the larger the block: a Шаблон:IPaddr block is 8 times larger than a Шаблон:IPaddr block.

Literal IPv6 addresses in network resource identifiers

Colon (:) characters in IPv6 addresses may conflict with the established syntax of resource identifiers, such as URIs and URLs. The colon is conventionally used to terminate the host path before a port number.Шаблон:Ref RFC To alleviate this conflict, literal IPv6 addresses are enclosed in square brackets in such resource identifiers, for example: Шаблон:Block indent When the URL also contains a port number the notation is: Шаблон:Block indent where the trailing 443 is the example's port number.

Scoped literal IPv6 addresses (with zone index)

For addresses with other than global scope (as described in Шаблон:Slink), and in particular for link-local addresses, the choice of the network interface for sending a packet may depend on which zone the address belongs to. The same address may be valid in different zones, and in use by a different host in each of those zones. Even if a single address is not in use in different zones, the address prefixes for addresses in those zones may still be identical, which makes the operating system unable to select an outgoing interface based on the information in the routing table (which is prefix-based).

In order to resolve the ambiguity in textual addresses, a Шаблон:Vanchor must be appended to the address. The zone index is separated from the address by a percent sign (%).Шаблон:Ref RFC Although numeric zone indices must be universally supported, the zone index may also be an implementation-dependent string. The link-local address Шаблон:Block indent could be expressed by Шаблон:Block indent or Шаблон:Block indent The former (using an interface name) is customary on most Unix-like operating systems (e.g., BSD, Linux, macOS).[5] The latter (using an interface number) is the only syntax on Microsoft Windows, but as support for this syntax is mandatory per standard, it is also available on other operating systems.Шаблон:Efn

BSD-based operating systems (including macOS) also support an alternative, non-standard syntax, where a numeric zone index is encoded in the second 16-bit word of the address. E.g.: Шаблон:Block indent

In all operating systems mentioned above, the zone index for link-local addresses actually refers to an interface, not to a zone. As multiple interfaces may belong to the same zone (e.g. when connected to the same network), in practice two addresses with different zone identifiers may actually be equivalent, and refer to the same host on the same link.Шаблон:Efn

When used in uniform resource identifiers (URI), the use of the percent sign causes a syntax conflict, therefore it must be escaped via percent-encoding,Шаблон:Ref RFC e.g.: Шаблон:Block indent

Literal IPv6 addresses in UNC path names

In Microsoft Windows operating systems, IPv4 addresses are valid location identifiers in Uniform Naming Convention (UNC) path names. However, the colon is an illegal character in a UNC path name. Thus, the use of IPv6 addresses is also illegal in UNC names. For this reason, Microsoft implemented a transcription algorithm to represent an IPv6 address in the form of a domain name that can be used in UNC paths. For this purpose, Microsoft registered and reserved the second-level domain ipv6-literal.net on the Internet (although they gave up the domain in January 2014[6]). IPv6 addresses are transcribed as a hostname or subdomain name within this namespace, in the following fashion: Шаблон:Block indent is written as Шаблон:Block indent This notation is automatically resolved locally by Microsoft software, without any queries to DNS name servers.

If the IPv6 address contains a zone index, it is appended to the address portion after an 's' character: Шаблон:Block indent is written as Шаблон:Block indent

Address scopes

Every IPv6 address, except the unspecified address (Шаблон:IPaddr), has a scope,Шаблон:Ref RFC which specifies in which part of the network it is valid.

Unicast

For unicast addresses, two scopes are defined: link-local and global.

Link-local addresses and the loopback address have link-local scope, which means they can only be used on a single directly attached network. All other addresses (including Unique local addresses) have global (or universal) scope, which means they are potentially globally routable and can be used to connect to addresses with global scope anywhere, or to addresses with link-local scope on the directly attached network.

Unique local addresses have global scope, but they are not globally administered. As a result, only other hosts in the same administrative domain (e.g., an organization), or within a cooperating administrative domain are able to reach such addresses, if properly routed. As their scope is global, these addresses are valid as a source address when communicating with any other global-scope address, even though it may be impossible to route packets from the destination back to the source.

Anycast

Anycast addresses are syntactically identical to and indistinguishable from unicast addresses. Their only difference is administrative. Scopes for anycast addresses are therefore the same as for unicast addresses.

Multicast

For multicast addresses, the four least-significant bits of the second address octet (Шаблон:IPaddr) identify the address scope, i.e. the domain in which the multicast packet should be propagated. Predefined and reserved scopes are:

Scope valuesШаблон:Ref RFCШаблон:Rp
Value Scope name Notes
0x0 reserved
0x1 interface-local Interface-local scope spans only a single interface on a node, and is useful only for loopback transmission of multicast.
0x2 link-local Link-local scope spans the same topological region as the corresponding unicast scope.
0x3 realm-local Realm-local scope is defined as larger than link-local, automatically determined by network topology and must not be larger than the following scopes.Шаблон:Ref RFC
0x4 admin-local Admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non-multicast-related configuration.
0x5 site-local Site-local scope is intended to span a single site belonging to an organisation.
0x8 organization-local Organization-local scope is intended to span all sites belonging to a single organization.
0xe global Global scope spans all reachable nodes on the internet - it is unbounded.
0xf reserved

All other scopes are unassigned and available to administrators for defining additional regions.

Address space

General allocation

The management of IPv6 address allocation process is delegated to the Internet Assigned Numbers Authority (IANA)Шаблон:Ref RFC by the Internet Architecture Board and the Internet Engineering Steering Group. Its main function is the assignment of large address blocks to the regional Internet registries (RIRs), which have the delegated task of allocation to network service providers and other local registries. The IANA has maintained the official list of allocations of the IPv6 address space since December 1995.[7]

In order to allow efficient route aggregation, thereby reducing the size of the Internet routing tables, only one-eighth of the total address space (Шаблон:IPaddr) is currently allocated for use on the Internet. The rest of the IPv6 address space is reserved for future use or for special purposes. The address space is assigned to the RIRs in blocks of Шаблон:IPaddr up to Шаблон:IPaddr.[8]

The RIRs assign smaller blocks to local Internet registries that distribute them to users. These are typically in sizes from Шаблон:IPaddr to Шаблон:IPaddr.[9][10][11] Global unicast assignment records can be found at the various RIRs or other websites.[12]

The addresses are then typically distributed in Шаблон:IPaddr to Шаблон:IPaddr sized blocks to the end users.Шаблон:Ref RFC IPv6 addresses are assigned to organizations in much larger blocks as compared to IPv4 address assignments—the recommended allocation is a Шаблон:IPaddr block which contains 280 addresses, being 248 or about Шаблон:Val times larger than the entire IPv4 address space of 232 addresses and about Шаблон:Val times larger than the Шаблон:IPaddr blocks of IPv4 addresses, which are the largest allocations of IPv4 addresses. The total pool, however, is sufficient for the foreseeable future, because there are 2128 (exactly 340,282,366,920,938,463,463,374,607,431,768,211,456) or about Шаблон:Val (340 undecillion) unique IPv6 addresses.

Each RIR can divide each of its multiple Шаблон:IPaddr blocks into 512 Шаблон:IPaddr blocks, typically one for each ISP; an ISP can divide its Шаблон:IPaddr block into Шаблон:Gaps Шаблон:IPaddr blocks, typically one for each customer;[13] customers can create Шаблон:Gaps Шаблон:IPaddr networks from their assigned Шаблон:IPaddr block, each having 264 (18,446,744,073,709,551,616) addresses. In contrast, the entire IPv4 address space has only 232 (exactly 4,294,967,296 or about Шаблон:Val) addresses.

By design, only a small fraction of the address space will be used actively. The large address space ensures that addresses are almost always available, which makes the use of network address translation (NAT) for the purposes of address conservation unnecessary. NAT has been increasingly used for IPv4 networks to help alleviate IPv4 address exhaustion.

Special allocation

Provider-independent address space is assigned directly to the end user by the RIRs from the special range Шаблон:IPaddr and allows customers to make provider changes without renumbering their networks.

Internet exchange points (IXPs) are assigned special addresses from the ranges Шаблон:IPaddr, Шаблон:IPaddr, and Шаблон:IPaddr[14] for communication with their connected ISPs.

Root name servers have been assigned addresses from the range Шаблон:IPaddr.[15]

Reserved anycast addresses

The lowest address within each subnet prefix (the interface identifier set to all zeroes) is reserved as the subnet-router anycast address.[1] Applications may use this address when talking to any one of the available routers, as packets sent to this address are delivered to just one router.

The 128 highest addresses within each Шаблон:IPaddr subnet prefix are reserved to be used as anycast addresses.Шаблон:Ref RFC These addresses usually have the first 57 bits of the interface identifier set to 1, followed by the 7-bit anycast ID. Prefixes for the network can be of any length for routing purposes, but subnets are required to have a length of 64 bits. The address with value 0x7e in the 7 least-significant bits is defined as a mobile IPv6 home agents anycast address. The address with value 0x7f (all bits 1) is reserved and may not be used. No more assignments from this range have been made, so values 0x00 through 0x7d are reserved as well.

Special addresses

Шаблон:See also There are a number of addresses with special meaning in IPv6.Шаблон:Ref RFC They represent less than 2% of the entire address space: <section begin=IPv6-special-address-blocks/>

Special address blocks
Address block (CIDR) First address Last address Number of addresses Usage Purpose
::/128 :: :: 1 Software Unspecified address
::1/128 ::1 ::1 1 Host Loopback address—a virtual interface that loops all traffic back to itself, the local host
::ffff:0:0/96 ::ffff:0.0.0.0 ::ffff:255.255.255.255 232 Software IPv4-mapped addresses
::ffff:0:0:0/96 ::ffff:0:0.0.0.0 ::ffff:0:255.255.255.255 232 Software IPv4 translated addresses
64:ff9b::/96 64:ff9b::0.0.0.0 64:ff9b::255.255.255.255 232 The global Internet IPv4/IPv6 translationШаблон:Ref RFC
64:ff9b:1::/48 64:ff9b:1:: 64:ff9b:1:ffff:ffff:ffff:ffff:ffff 280, with 248 for each IPv4 Private internets IPv4/IPv6 translationШаблон:Ref RFC
100::/64 100:: 100::ffff:ffff:ffff:ffff 264 Routing Discard prefixШаблон:Ref RFC
2001::/32 2001:: 2001::ffff:ffff:ffff:ffff:ffff:ffff 296 The global Internet Teredo tunnelingШаблон:Ref RFC
2001:20::/28 2001:20:: 2001:2f:ffff:ffff:ffff:ffff:ffff:ffff 2100 Software ORCHIDv2Шаблон:Ref RFC
2001:db8::/32 2001:db8:: 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff 296 Documentation Addresses used in documentation and example source codeШаблон:Ref RFC
2002::/16 2002:: 2002:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2112 The global Internet The 6to4 addressing scheme (deprecated)Шаблон:Ref RFC
fc00::/7 fc00:: fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2121 Private internets Unique local addressШаблон:Ref RFC
fe80::/64 from fe80::/10 fe80:: fe80::ffff:ffff:ffff:ffff 264 Link Link-local address
ff00::/8 ff00:: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2120 The global Internet Multicast address

<section end=IPv6-special-address-blocks/>

Unicast addresses

Unspecified address

  • Шаблон:IPaddrШаблон:SndThe address with all zero bits is called the unspecified address (corresponding to Шаблон:IPaddr in IPv4). This address must never be assigned to an interface and is to be used only in software before the application has learned its host's source address appropriate for a pending connection. Routers must not forward packets with the unspecified address.

Applications may listen on one or more specific interfaces for incoming connections, which are shown in listings of active internet connections by a specific IP address (and a port number, separated by a colon). When the unspecified address is shown it means that an application is listening for incoming connections on all available interfaces.

In routing table configuration, the unspecified address may be used to represent the default route address (corresponding to Шаблон:IPaddr in IPv4) for destination addresses (unicast, multicast and others) not specified elsewhere in a routing table.

Local addresses

Unique local addresses

Transition from IPv4

  • Шаблон:IPaddr — This prefix is used for IPv6 transition mechanisms and designated as an IPv4-mapped IPv6 address.
    With a few exceptions, this address type allows the transparent use of the transport layer protocols over IPv4 through the IPv6 networking application programming interface. In this dual-stack configuration, server applications only need to open a single listening socket to handle connections from clients using IPv6 or IPv4 protocols. IPv6 clients are handled natively by default, and IPv4 clients appear as IPv6 clients at their IPv4-mapped IPv6 address. Transmission is handled similarly; established sockets may be used to transmit IPv4 or IPv6 datagram, based on the binding to an IPv6 address, or an IPv4-mapped address.
  • Шаблон:IPaddr — A prefix used for IPv4-translated addresses. These are used by the Stateless IP/ICMP Translation (SIIT) protocol.Шаблон:Ref RFC
  • Шаблон:IPaddr — The well-known prefix. Addresses with this prefix are used for automatic IPv4/IPv6 translation.[17]
  • Шаблон:IPaddr — A prefix for locally translated IPv4/IPv6 addresses. Addresses with this prefix can be used for multiple IPv4/IPv6 translation mechanisms like NAT64 and SIIT.[18] It is defined in RFC 8215 and compared to Шаблон:IPaddr it contains the IPv4 address in position 48-63 and 72-87 (see RFC6052). This means that for every IPv4 address a /88 IPv6 prefix is assigned to the device. This enables similar use cases as 6to4, where a single public IPv4 address gets translated into a prefix. This way only one level of NAT is required and the devices do not need to do NAT66 internally if they need additional addresses e.g. for P2P interfaces or docker containers.
  • Шаблон:IPaddr — This prefix was used for 6to4 addressing (prefix from the IPv4 network, Шаблон:IPaddr, was also used).
    The 6to4 addressing scheme is deprecated.[19]

Special-purpose addresses

IANA has reserved a so-called Sub-TLA ID address block for special assignments[20]Шаблон:Ref RFC of Шаблон:IPaddr (split into the range of 64 network prefixes Шаблон:IPaddr through Шаблон:IPaddr). Three assignments from this block are currently allocated:

Шаблон:Anchor Documentation

  • Шаблон:IPaddr — This prefix is used in documentation[22]Шаблон:Efn The addresses should be used anywhere an example IPv6 address is given or model networking scenarios are described.

Discard

Deprecated and obsolete

See Шаблон:Slink

Multicast addresses

The multicast addresses Шаблон:IPaddr, where Шаблон:IPaddr is any hexadecimal value, are reserved[1] and managed by the Internet Assigned Numbers Authority (IANA).[24]

Common IPv6 multicast addresses
Address Description Available scopes
Шаблон:IPaddr All nodes address, identify the group of all IPv6 nodes Available in scope 1 (interface-local) and 2 (link-local):
Шаблон:IPaddr All routers Available in scope 1 (interface-local), 2 (link-local) and 5 (site-local):
Шаблон:IPaddr OSPFIGP 2 (link-local)
Шаблон:IPaddr OSPFIGP designated routers 2 (link-local)
Шаблон:IPaddr RIP routers 2 (link-local)
Шаблон:IPaddr EIGRP routers 2 (link-local)
Шаблон:IPaddr Web Services Dynamic Discovery 2 (link-local)
Шаблон:IPaddr All PIM routers 2 (link-local)
Шаблон:IPaddr All RPL routers 2 (link-local)
Шаблон:IPaddr mDNSv6 Available in all scopes
Шаблон:IPaddr All NTP servers Available in all scopes
Шаблон:IPaddr Link name 2 (link-local)
Шаблон:IPaddr All-dhcp-agents (DHCPv6) 2 (link-local)
Шаблон:IPaddr Link-local multicast name resolution 2 (link-local)
Шаблон:IPaddr All-dhcp-servers (DHCPv6) 5 (site-local)
Шаблон:IPaddr Solicited-node multicast address (see below) 2 (link-local)
Шаблон:IPaddr Node information queries 2 (link-local)

Solicited-node multicast address

The least significant 24 bits of the solicited-node multicast address group ID are filled with the least significant 24 bits of the interface's unicast or anycast address. These addresses allow link-layer address resolution via Neighbor Discovery Protocol (NDP) on the link without disturbing all nodes on the local network. A host is required to join a solicited-node multicast group for each of its configured unicast or anycast addresses.

Stateless address autoconfiguration (SLAAC)

On system startup, a node automatically creates a link-local address on each IPv6-enabled interface, even if globally routable addresses are manually configured or obtained through configuration protocols (see below). It does so independently and without any prior configuration by stateless address autoconfiguration (SLAAC),Шаблон:Ref RFC using a component of the Neighbor Discovery Protocol. This address is selected with the prefix Шаблон:IPaddr.

In IPv4, typical configuration protocols include DHCP or PPP. Although DHCPv6 exists, IPv6 hosts normally use the Neighbor Discovery Protocol to create a globally routable unicast address: the host sends router solicitation requests and an IPv6 router responds with a prefix assignment.Шаблон:Ref RFC

Interface identifier

The lower 64 bits of these addresses are populated with a 64-bit interface identifier. This should be a pseudo-random number for privacy reasons. Also for privacy reasons, the interface identifier is different for each automatically configured address of that interface. This has the disadvantage that multiple multicast groups need to be joined for neighbor discovery. For this, a multicast address is used, formed from the network prefix Шаблон:IPaddr and the 24 least significant bits of the address.

A 64-bit interface identifier can be derived from the interface's 48-bit MAC address, although stable privacy addresses are now recommended as a default instead.Шаблон:Ref RFC A MAC address Шаблон:MACaddr is turned into a 64-bit EUI-64 by inserting Шаблон:MACaddr in the middle: Шаблон:MACaddr.Шаблон:Efn

Duplicate address detection

The assignment of a unicast IPv6 address to an interface involves an internal test for the uniqueness of that address using Neighbor Solicitation and Neighbor Advertisement (ICMPv6 type 135 and 136) messages. While in the process of establishing uniqueness an address has a tentative state.

The node joins the solicited-node multicast address for the tentative address and sends neighbor solicitations, with the tentative address as the target address and the unspecified address (Шаблон:IPaddr) as its source address. The node also joins the all-hosts multicast address Шаблон:IPaddr, so it can receive Neighbor Advertisements.

If a node receives a neighbor solicitation with its own tentative address as the target address, then in know its address is not unique. The same is true if the node receives a neighbor advertisement with the tentative address as the source of the advertisement. Only after having successfully established that an address is unique may it be assigned and used by an interface.

When an anycast address is assigned to an interface (e.g. a subnet-router anycast address), due to the inherent non-uniqueness of this type of address, duplicate address detection is not performed.

Address lifetime

Each IPv6 address that is bound to an interface has a defined lifetime. Lifetimes are infinite, unless configured to a shorter period. There are two lifetimes that govern the state of an address: the preferred lifetime and the valid lifetime.[25] Lifetimes can be configured in routers that provide the values used for autoconfiguration, or specified when manually configuring addresses on interfaces.

When an address is assigned to an interface it gets the status preferred, which it holds during its preferred-lifetime. After that lifetime expires the status becomes deprecated and no new connections should be made using this address.Шаблон:Efn The address becomes invalid after its valid-lifetime also expires; the address is removed from the interface and may be assigned somewhere else on the Internet.

Temporary addresses

The globally unique and static MAC addresses, used by stateless address autoconfiguration to create interface identifiers, offer an opportunity to track user equipment—across time and IPv6 network prefix changes—and so users.[26] To reduce the prospect of a user identity being permanently tied to an IPv6 address portion, a node may create temporary addresses with interface identifiers based on time-varying random bit stringsШаблон:Ref RFC and relatively short lifetimes (hours to days), after which they are replaced with new addresses.

Temporary addresses may be used as source addresses for originating connections, while external hosts use a public address by querying the Domain Name System.

Network interfaces configured for IPv6 use temporary addresses by default in OS X Lion and later Apple systems as well as in Windows Vista, Windows 2008 Server and later Microsoft systems.

Cryptographically generated addresses

As a means to enhance security for Neighbor Discovery Protocol cryptographically generated addresses (or CGAs) were introduced in 2005Шаблон:Ref RFC as part of the Secure Neighbor Discovery (SEND) Protocol.

Such an address is generated using two hash functions that take several inputs. The first uses a public key and a random modifier; the latter being incremented repeatedly until a specific amount of zero bits of the resulting hash is acquired. (Comparable with the 'proof of work' field in Bitcoin mining.) The second hash function takes the network prefix and the previous hash value. The least significant 64 bits of the second hash result is appended to the 64-bit network prefix to form a 128-bit address.

The hash functions can also be used to verify if a specific IPv6 address satisfies the requirement of being a valid CGA. This way, communication can be set up between trusted addresses exclusively.

Stable privacy addresses

The use of the modified EUI-64 format has serious implications for security and privacy concerns,Шаблон:Ref RFC because the underlying hardware address (most typically the MAC address) is exposed beyond the local network, permitting the tracking of user activities and correlation of user accounts to other information. It also permits vendor-specific attack strategies, and reduces the size of the address space for searching for attack targets.

Stable privacy addresses were introduced to remedy these shortcomings. They are stable within a specific network but change when moving to another, to improve privacy. They are chosen deterministically, but randomly, in the entire address space of the network.

Generation of a stable privacy address is based on a hash function that uses several stable parameters. It is implementation specific, but it is recommended to use at least the network prefix, the name of the network interface, a duplicate address counter, and a secret key. The resulting hash value is used to construct the final address: Typically the 64 least significant bits are concatenated to the 64-bit network prefix, to yield a 128-bit address. If the network prefix is smaller than 64 bits, more bits of the hash are used. If the resulting address does not conflict with existing or reserved addresses, it is assigned to the interface.

Default address selection

IPv6-enabled network interfaces usually have more than one IPv6 address, for example, a link-local and a global address. They may also have temporary addresses that change after a certain lifetime has expired. IPv6 introduces the concepts of address scope and selection preference, yielding multiple choices for source and destination address selections in communication with another host.

The preference selection algorithm selects the most appropriate address to use in communications with a particular destination, including the use of IPv4-mapped addresses in dual-stack implementations.Шаблон:Ref RFC It uses a configurable preference table that associates each routing prefix with a precedence level. The default table has the following content:

Prefix Precedence Label Usage
::1/128 50 0 Localhost
::/0 40 1 Default unicast
::ffff:0:0/96 35 4 IPv4-mapped IPv6 address
2002::/16 30 2 6to4
2001::/32 5 5 Teredo tunneling
fc00::/7 3 13 Unique local address
::/96 1 3 IPv4-compatible addresses (deprecated)
fec0::/10 1 11 Site-local address (deprecated)
3ffe::/16 1 12 6bone (returned)

The default configuration places preference on IPv6 usage, and selects destination addresses within the smallest possible scope, so that link-local communication is preferred over globally routed paths when otherwise equally suitable. The prefix policy table is similar to a routing table, with the precedence value serving as the role of a link cost, where higher preference is expressed as a larger value. Source addresses are preferred to have the same label value as the destination address. Addresses are matched to prefixes based on the longest matching most-significant bit-sequence. Candidate source addresses are obtained from the operating system and candidate destination addresses may be queried via the Domain Name System (DNS).

For minimizing the time of establishing connections when multiple addresses are available for communication, the Happy Eyeballs algorithm was devised. It queries the Domain Name System for IPv6 and IPv4 addresses of the target host, sorts candidate addresses using the default address selection table, and tries to establish connections in parallel. The first connection that is established aborts current and future attempts to connect to other addresses.

Domain Name System

In the Domain Name System, hostnames are mapped to IPv6 addresses by AAAA resource records, so-called quad-A records.Шаблон:Ref RFC For reverse lookup the IETF reserved the domain ip6.arpa, where the name space is hierarchically divided by the 1-digit hexadecimal representation of nibble units (4 bits) of the IPv6 address.

As in IPv4, each host is represented in the DNS by two DNS records: an address record and a reverse mapping pointer record. For example, a host computer named derrick in zone example.com has the unique local address Шаблон:IPaddr. Its quad-A address record is 

 derrick.example.com.  IN  AAAA  fdda:5cc1:23:4::1f

and its IPv6 pointer record is 

 f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.3.2.0.0.1.c.c.5.a.d.d.f.ip6.arpa.  IN  PTR   derrick.example.com.

This pointer record may be defined in a number of zones, depending on the chain of delegation of authority in the zone d.f.ip6.arpa.

The DNS protocol is independent of its transport layer protocol. Queries and replies may be transmitted over IPv6 or IPv4 transports regardless of the address family of the data requested.

AAAA record fields
NAME Domain name
TYPE AAAA (28)
CLASS Internet (1)
TTL Time to live, in seconds
RDLENGTH Length of RDATA field
RDATA 128-bit IPv6 address, network byte order

Historical notes

Deprecated and obsolete addresses

Miscellaneous

  • For reverse DNS lookup, IPv6 addresses were originally registered in the DNS zone ip6.int, because it was expected that the top-level domain arpa would be retired. In 2000, the Internet Architecture Board (IAB) reverted this intention, and decided in 2001 that arpa should retain its original function. Domains in ip6.int were moved to ip6.arpaШаблон:Ref RFC and zone ip6.int was officially removed on 6 June 2006.
  • In March 2011, the IETF refined the recommendations for allocation of address blocks to end sites.Шаблон:Ref RFC Instead of assigning either a Шаблон:IPaddr, Шаблон:IPaddr, or Шаблон:IPaddr (according to IAB's and IESG's views of 2001),Шаблон:Ref RFC Internet service providers should consider assigning smaller blocks (for example a Шаблон:IPaddr) to end users. The ARIN, RIPE & APNIC regional registries' policies encourage Шаблон:IPaddr assignments where appropriate.Шаблон:Ref RFC
  • Originally, two proposals existed for translating domain names to IPv6 addresses: one using AAAA records,Шаблон:Ref RFC the other using A6 records.Шаблон:Ref RFC AAAA records, the method that prevailed, are comparable to A records for IPv4, providing a simple mapping from hostname to IPv6 address. The method using A6 records used a hierarchical scheme, in which the mapping of subsequent groups of address bits was specified by additional A6 records, providing the possibility to renumber all hosts in a network by changing a single A6 record. As the perceived benefits of the A6 format were not deemed to outweigh the perceived costs,[28]Шаблон:Ref RFCШаблон:Ref RFCШаблон:Ref RFC the method was moved to experimental status in 2002,[29] and finally to historic status in 2012.[30]
  • In 2009, many DNS resolvers in home-networking NAT devices and routers were found to handle AAAA records improperly.Шаблон:Ref RFC Some of these simply dropped DNS requests for such records, instead of properly returning the appropriate negative DNS response. Because the request is dropped, the host sending the request has to wait for a timeout to trigger. This often causes increased latency when connecting to dual-stack IPv6/IPv4 hosts, as the client software waits for the IPv6 connection to fail before trying IPv4. Шаблон:See also

Notes

Шаблон:Notelist

References

Шаблон:Reflist

External links

Шаблон:IPv6

Партнерские ресурсы
Криптовалюты
Магазины
Хостинг
Разное

  1. ↑ 1,0 1,1 1,2 1,3 1,4 Ошибка цитирования Неверный тег <ref>; для сносок rfc4291 не указан текст
  2. ↑ Шаблон:Cite book
  3. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc3956 не указан текст
  4. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc3306 не указан текст
  5. ↑ Шаблон:Man "The KAME implementation supports an extended numeric IPv6 address notation for link-local addresses, like "fe80::1%de0" [...] draft-ietf-ipngwg-scopedaddr-format-02.txt"
  6. ↑ Шаблон:Cite web
  7. ↑ IPv6 address space at IANA. Iana.org (2010-10-29). Retrieved on 2011-09-28.
  8. ↑ IPv6 unicast address assignments, IANA
  9. ↑ DE-TELEKOM-20050113Шаблон:Dead link db.ripe.net. Retrieved 2011-09-28.
  10. ↑ Шаблон:Cite web
  11. ↑ Шаблон:Cite web
  12. ↑ for example. Iana.org. Retrieved on 2011-09-28.
  13. ↑ Шаблон:Cite web
  14. ↑ Шаблон:Cite web
  15. ↑ Шаблон:Cite web
  16. ↑ 16,0 16,1 Ошибка цитирования Неверный тег <ref>; для сносок rfc4193 не указан текст
  17. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc6052 не указан текст
  18. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc8215 не указан текст
  19. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc7526 не указан текст
  20. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc6890 не указан текст
  21. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc7343 не указан текст
  22. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc3849 не указан текст
  23. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc6666 не указан текст
  24. ↑ IANA Internet Protocol Version 6 Multicast Addresses.
  25. ↑ Шаблон:Cite news
  26. ↑ The privacy implications of stateless IPv6 addressing. Portal.acm.org (2010-04-21). Retrieved on 2011-09-28.
  27. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc1884 не указан текст
  28. ↑ Comparison of AAAA and A6 (do we really need A6?), Jun-ichiro itojun Hagino, (July 2001)
  29. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc3363 не указан текст
  30. ↑ Ошибка цитирования Неверный тег <ref>; для сносок rfc6536 не указан текст
Источник — http://wikihandbk.com/ruwiki/index.php?title=Английская_Википедия:IPv6_address&oldid=15351450