词条 | IPv6 address | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
释义 |
An Internet Protocol Version 6 address (IPv6 address) is a numerical label that is used to identify a network interface of a computer or a network node participating in an IPv6 computer network. An IP address serves the purpose of identifying an individual network interface of a host, locating it on the network, and thus permitting the routing of IP packets between hosts. For routing, IP addresses are present in fields of the packet header where they indicate the source and destination of the packet. 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, IPv6 has a vastly enlarged address space compared to IPv4. Addressing methodsIPv6 addresses are classified by the primary addressing and routing methodologies common in networking: unicast addressing, anycast addressing, and multicast addressing.[1] 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, which 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|ff02::1}}. 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 formatsAn IPv6 address consists of 128 bits.[1] For each of the major addressing and routing methodologies, various address formats are recognized by logically dividing the 128 address bits into bit groups and establishing rules for associating the values of these bit groups with special addressing features. Unicast and anycast address formatUnicast 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.
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 either automatically generated from the interface's MAC address using the modified EUI-64 format, obtained from a DHCPv6 server, automatically established randomly, or assigned manually. A link-local address is also based on the interface identifier, but uses a different format for the network prefix.
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|fe80::|64}} link-local address prefix), rendering them non-routable. Multicast address format{{details | Multicast address#IPv6 }}Multicast addresses are formed according to several specific formatting rules, depending on the application.
The prefix holds the binary value 11111111 for any multicast address. Currently, 3 of the 4 flag bits in the flg field are defined;[1] the most-significant flag bit is reserved for future use.
The 4-bit scope field (sc) is used to indicate where the address is valid and unique. There are special multicast addresses, like Solicited Node.
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.
Link-scoped multicast addresses use a comparable format.[5] RepresentationAn IPv6 address is represented as eight groups of four hexadecimal digits, each group representing 16 bits (two octets, a group sometimes also called a hextet[6][7]). The groups are separated by colons (:). An example of an IPv6 address is: {{IPaddr|2001:0db8:85a3:0000:0000:8a2e:0370:7334}} The hexadecimal digits are case-insensitive, but IETF recommendations suggest the use of lower case letters. The full representation of eight 4-digit groups may be simplified by several techniques, eliminating parts of the representation. Leading zeroes in a group may be omitted, but each group must retain at least one hexadecimal digit.[1] Thus, the example address may be written as: {{IPaddr|2001:db8:85a3:0:0:8a2e:370:7334}} One or more consecutive groups containing zeros only may be replaced with a single empty group, using two consecutive colons (::).[1] The substitution may only be applied once in the address, however, because multiple occurrences would create an ambiguous representation. Thus, the example address can be further simplified: {{IPaddr|2001:db8:85a3::8a2e:370:7334}} The localhost (loopback) address, {{IPaddr|0:0:0:0:0:0:0:1}}, and the IPv6 unspecified address, {{IPaddr|0:0:0:0:0:0:0:0}}, are reduced to {{IPaddr|::1}} 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 other 96 (most significant) bits are written in IPv6 format. For example, the IPv4-mapped IPv6 address {{IPaddr|::ffff:c000:0280}} is written as {{IPaddr|::ffff:192.0.2.128}}, thus expressing clearly the original IPv4 address that was mapped to IPv6. Recommended representation as textIn an attempt to simplify IPv6 addresses, the standards provide flexibility in their representation. However, this also complicates several common operations: searching for a specific address in a text file or stream, and comparing two addresses to determine their equivalence. To mitigate these problems, a canonical format is defined[8] for rendering IPv6 addresses in text:
NetworksAn 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|2001:db8:1234::|48}} starts at address {{IPaddr|2001:db8:1234:0000:0000:0000:0000:0000}} and ends at {{IPaddr|2001:db8:1234:ffff:ffff:ffff:ffff:ffff}}. The routing prefix of an interface address may be directly indicated with the address by CIDR notation. For example, the configuration of an interface with address {{IPaddr|2001:db8:a::123}} connected to subnet {{IPaddr|2001:db8:a::|64}} is written as {{IPaddr|2001:db8:a::123|64}}. Address block sizesThe 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, rather than by explicitly specifying which addresses are in the block. For example, an address block with 48 bits in the prefix is indicated by {{IPaddr||48}}. Such a block contains 2128 − 48 = 280 addresses. The smaller the value of the network prefix, the larger the block: a {{IPaddr||21}} block is 8 times larger than a {{IPaddr||24}} block. Literal IPv6 addresses in network resource identifiersColon (:) characters in IPv6 addresses may conflict with the established syntax of resource identifiers, such as URIs and URLs. The colon has traditionally been used to terminate the host path before a port number.[9] To alleviate this conflict, literal IPv6 addresses are enclosed in square brackets in such resource identifiers, for example: http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/ When the URL also contains a port number the notation is: https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443/ where the trailing 443 is the example's port number. Scoped literal IPv6 addressesFor addresses with other than global scope (as described below), 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 be 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 zone index must be appended to the address, the two separated by a percent sign (%).[17] The syntax of zone indices is an implementation-dependent string, although numeric zone indices must be universally supported as well. The following link-local address: {{IPaddr|fe80::1ff:fe23:4567:890a}} could become for instance: {{IPaddr|fe80::1ff:fe23:4567:890a%eth2}} or: {{IPaddr|fe80::1ff:fe23:4567:890a%3}} The former (using an interface name) is customary on most Unix-like operating systems (e.g., BSD, Linux, OS X). The latter (using an interface number) is the standard syntax on Microsoft Windows, but as support for this syntax is mandatory, it is also available on other operating systems. BSD-based operating systems (including OS X) 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.: {{IPaddr|fe80:3::1ff:fe23:4567:890a}} 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 switch), in practice two addresses with different zone-ids may actually be equivalent, and refer to the same host on the same link. Use of zone indices in URIsWhen used in uniform resource identifiers (URI), the use of the percent sign causes a syntax conflict, therefore it must be escaped via percent-encoding,[10] e.g.: http://[fe80::1ff:fe23:4567:890a%25eth0]/ Literal IPv6 addresses in UNC path namesIn 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[11]). IPv6 addresses are transcribed as a hostname or subdomain name within this name space, in the following fashion: {{IPaddr|2001:db8:85a3:8d3:1319:8a2e:370:7348}} is written as 2001-db8-85a3-8d3-1319-8a2e-370-7348.ipv6-literal.net 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: {{IPaddr|fe80::1ff:fe23:4567:890a%3}} is written as fe80--1ff-fe23-4567-890as3.ipv6-literal.net Address scopesEvery IPv6 address, except the unspecified address ({{IPaddr|::}}), has a "scope",[12] which specifies in which part of the network it is valid. UnicastFor 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 (link). All other addresses (including Unique local addresses) have global (or universal) scope, which means they are (or could be) 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.[13] Even though Unique local addresses have global scope, they are not globally administered. As a result, only other hosts inside the same administrative domain (e.g. an organisation), or inside a cooperating administrative domain will be able to reach such addresses (i.e. have a route to them). 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. AnycastAnycast 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. MulticastFor multicast addresses, the four least-significant bits of the second address octet ({{IPaddr|ff0s::}}) identify the address scope, i.e. the domain in which the multicast packet should be propagated. Predefined and reserved scopes[1] are:
All other scopes are unassigned, and available to administrators for defining additional regions. Address spaceGeneral allocationThe management of IPv6 address allocation process is delegated to the Internet Assigned Numbers Authority (IANA)[15] 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 {{date|December 1995}}.[16] Only one eighth of the total address space is currently allocated for use on the Internet, {{IPaddr|2000::|3}}, in order to provide efficient route aggregation, thereby reducing the size of the Internet routing tables; 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 large blocks of {{IPaddr||23}} up to {{IPaddr||12}}.[17] The RIRs assign smaller blocks to local Internet registries that distributes them to users. These are typically in sizes from {{IPaddr||19}} to {{IPaddr||32}}.[18][19][20] The addresses are typically distributed in {{IPaddr||48}} to {{IPaddr||56}} sized blocks to the end users.[21] Global unicast assignment records can be found at the various RIRs or other websites.[22] IPv6 addresses are assigned to organizations in much larger blocks as compared to IPv4 address assignments—the recommended allocation is a {{IPaddr||48}} block which contains 280 addresses, being 248 or about {{val|2.8|e=14}} times larger than the entire IPv4 address space of 232 addresses and about {{val|7.2|e=16}} times larger than the {{IPaddr||8}} 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|3.4|e=38}} (340 trillion trillion trillion) unique IPv6 addresses. Each RIR can divide each of its multiple {{IPaddr||23}} blocks into 512 {{IPaddr||32}} blocks, typically one for each ISP; an ISP can divide its {{IPaddr||32}} block into {{gaps|65|536}} {{IPaddr||48}} blocks, typically one for each customer;[23] customers can create {{gaps|65|536}} {{IPaddr||64}} networks from their assigned {{IPaddr||48}} 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|4.3|e=9}}) addresses. By design, only a very small fraction of the address space will actually be used. 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 completely unnecessary. NAT has been increasingly used for IPv4 networks to help alleviate IPv4 address exhaustion. Special allocationTo allow for provider changes without renumbering, provider-independent address space – assigned directly to the end user by the RIRs – is taken from the special range {{IPaddr|2001:678::|29}}. Internet Exchange Points (IXPs) are assigned special addresses from the range {{IPaddr|2001:7f8::|29}} for communication with their connected ISPs.[24]Root name servers have been assigned addresses from the same range. Reserved anycast addressesThe 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||64}} subnet prefix are reserved to be used as anycast addresses.[25] These addresses usually have the 57 first bits of the interface identifier set to 1, followed by the 7-bit anycast ID. Prefixes for the network, including subnets, are required to have a length of 64 bits, in which case the universal/local bit must be set to 0 to indicate the address is not globally unique. 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 are made, so values 0x00 through 0x7d are reserved as well. Special addresses{{see also|Reserved IP addresses#IPv6}}There are a number of addresses with special meaning in IPv6.[26] They represent less than 2% of the entire address space:
Unicast addressesDefault route
Unspecified address
Local addresses
Unique local addresses
Transition from IPv4
Special-purpose addressesIANA has reserved a so-called 'Sub-TLA ID' address block for special assignments[26][34] which consists of 64 network prefixes in the range {{IPaddr|2001:0000::|29}} through {{IPaddr|2001:01f8::|29}}. Three assignments from this block have been made:
{{Anchor|Documentation}} Documentation
Discard
Deprecated and obsolete addresses{{further|#Historical notes}}Multicast addressesThe multicast addresses {{IPaddr|ff0X::}} where {{IPaddr|X}} is any hexadecimal value are reserved[1] and should not be assigned to any multicast group. The Internet Assigned Numbers Authority (IANA) manages address reservations.[37] Some common IPv6 multicast addresses are the following:
Solicited-node multicast addressThe 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 autoconfigurationOn 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),[38] using a component of the Neighbor Discovery Protocol. This address is selected with the prefix {{IPaddr|fe80::|64}}. 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.[39] The lower 64 bits of these addresses are populated with a 64-bit interface identifier in modified EUI-64 format. This identifier is usually shared by all automatically configured addresses of that interface, which has the advantage that only one multicast group needs to be joined for neighbor discovery. For this, a multicast address is used, formed from the network prefix {{IPaddr|ff02::1:ff00:0|104}} and the 24 least significant bits of the address. Modified EUI-64A 64-bit interface identifier is most commonly derived from its 48-bit MAC address. A MAC address {{MACaddr|00-0C-29-0C-47-D5}} is turned into a 64-bit EUI-64 by inserting {{MACaddr|FF-FE}} in the middle: {{MACaddr|00-0C-29-FF-FE-0C-47-D5}}. When this EUI-64 is used to form an IPv6 address it is modified:[1] the meaning of the Universal/Local bit (the 7th most significant bit of the EUI-64, starting from 1) is inverted, so that a 1 now means Universal. To create an IPv6 address with the network prefix {{IPaddr|2001:db8:1:2::|64}} it yields the address {{IPaddr|2001:db8:1:2:020c:29ff:fe0c:47d5}} (with the Universal/Local bit, the second-least-significant bit of the underlined quartet, inverted to 1 in this case because the MAC address is universally unique). Duplicate address detectionThe 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 (if not already done so) and sends neighbor solicitations, with the tentative address as target address and the unspecified address ({{IPaddr|::|128}}) as source address. The node also joins the all-hosts multicast address {{IPaddr|ff02::1}}, so it will be able to receive Neighbor Advertisements. If a node receives a neighbor solicitation with its own tentative address as the target address, then that 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. Address lifetimeEach IPv6 address that is bound to an interface has a fixed 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.[40] 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. 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. Note: In most cases, the lifetime does not expire because new Router Advertisements (RAs) refresh the timers. But if there are no more RAs, eventually the preferred lifetime elapses and the address becomes "deprecated". Temporary addressesThe 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.[41] 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[42] and relatively short lifetimes (hours to days), after which they are replaced with new addresses. Temporary addresses may be used as source address 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 addressesAs a means to enhance security for Neighbor Discovery Protocol cryptographically generated addresses (or CGAs) were introduced in 2005[43] 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 addressesStateless autoconfigured addresses have some security and privacy related drawbacks,[44] due to the fact that the underlying hardware address (most typically the MAC address) is used to generate it. Users may be tracked and accounts correlated, by means of this embedded hardware address. Attacks may be more successful, since the address space to search for victims is greatly reduced and vendor specific attacks may be launched, as this is part of the address. Another drawback is that if the hardware is replaced, a different address will be used for the same device, which may require updating security policies or hinder log entry correlation. Since using temporary addresses do not fully alleviate these problems stable privacy addresses were introduced. These addresses are stable within a specific network but change when moving to another, to improve privacy. They are chosen deterministic but randomly in the entire address space of the network, to improve security. Generation of a stable privacy address is based on a hash function that takes several stable parameters as its arguments. It at least uses the network prefix, the name of the network interface, a duplicate address counter, and a secret key. The resulting hash value is then used to construct the final address: typically the 64 least significant bits of it are concatenated to the 64 bit network prefix, to get 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 selectionIPv6-enabled network interfaces usually have more than one IPv6 address, for example, a link-local and a global address, and permanent versus temporary addresses. 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,[45] which selects the most appropriate address to use in communications with a particular destination (including the use of IPv4-mapped addresses in dual-stack implementations), is based on a user-customizable preference table that associates each routing prefix with a precedence level. The default table is as follows:[45]
The default configuration places preference on IPv6, rather than IPv4, and on 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). In order to minimize connection times 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, where the first connection that is thus established aborts current and future attempts to connect to other addresses. Domain Name SystemIn the Domain Name System, hostnames are mapped to IPv6 addresses by AAAA resource records, so-called quad-A records.[46] 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|fdda:5cc1:23:4::1f}}. Its quad-A address record is and its IPv6 pointer record is 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.
Historical notesDeprecated and obsolete addresses
Miscellaneous
Notes1. ^1 2 3 4 5 6 7 8 9 10 {{Cite IETF|rfc=4291|title=IP Version 6 Addressing Architecture|author1=R. Hinden|authorlink2=Steve Deering|author2=S. Deering|publisher=Network Working Group|date=February 2006}} Updated by: RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064. 2. ^{{cite book |title=IPv6 Essentials |author=Silvia Hagen |publisher=O'Reilly |edition=Second |date=May 2006 |isbn=978-0-596-10058-2}} 3. ^1 {{Cite IETF|rfc=3956|title=Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address|author1=P. Savola|author2=B. Haberman|date=November 2004|publisher=Network Working Group}} 4. ^1 {{Cite IETF|rfc=3306|title=Unicast-Prefix-based IPv6 Multicast Addresses|author1=B. Haberman|author2=D. Thaler|date=August 2002|publisher=Network Working Group}} 5. ^{{Cite IETF|rfc=4489|title=A Method for Generating Link-Scoped IPv6 Multicast Addresses|author1=J-S. Park|author2=M-K. Shin|author3=H-J. Kim|date=April 2006|publisher=Network Working Group}} 6. ^{{cite book |author-first=Rick |author-last=Graziani |title=IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6 |year=2012 |publisher=Cisco Press |isbn=978-0-13-303347-2 |page=55 |url=https://books.google.com/books?id=FbYjJjZNA5gC&pg=PA55}} 7. ^{{cite book |author-first=Tom |author-last=Coffeen |title=IPv6 Address Planning: Designing an Address Plan for the Future |year=2014 |publisher=O'Reilly Media |isbn=978-1-4919-0326-1 |page=170 |url=https://books.google.com/books?id=dZU8BQAAQBAJ&pg=PT170}} 8. ^{{Cite IETF|rfc=5952|title=A Recommendation for IPv6 Address Text Representation|author1=S. Kawamura|author2=M. Kawashima|publisher=IETF|date=August 2010|issn=2070-1721}} 9. ^{{Cite IETF|rfc=3986|std=66|title=Uniform Resource Identifier (URI): Generic Syntax|authorlink1=Tim Berners-Lee|author1=T. Berners-Lee|authorlink2=Roy Fielding|author2=R. Fielding|author3=L. Masinter |date=January 2005|publisher=Network Working Group}} 10. ^Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers. Tools.ietf.org. Retrieved on 2013-07-09. 11. ^{{cite web|title=ipv6-literal.net Domain History|url=http://www.who.is/domain-history/ipv6-literal.net|publisher=who.is|accessdate=20 October 2014}} 12. ^1 {{Cite IETF|rfc=4007|title=IPv6 Scoped Address Architecture|authorlink1=Steve Deering|author1=S.Deering|author2=B. Haberman|author3=T. Jinmei|author4=E. Nordmark|author5=B. Zill|date=March 2005|publisher=Network Working Group}} 13. ^It is not mandatory for the source and destination address of a packet to have the same scope. 14. ^{{Cite IETF|rfc=7346|title=IPv6 Multicast Address Scopes|author=R Droms|date=August 2014|publisher=IETF|issn=2070-1721}} 15. ^{{Cite IETF|rfc=1881|title=IPv6 Address Allocation Management|publisher=Network Working Group, IETF |date=December 1995}} 16. ^IPv6 address space at IANA. Iana.org (2010-10-29). Retrieved on 2011-09-28. 17. ^IPv6 unicast address assignments, IANA 18. ^DE-TELEKOM-20050113 db.ripe.net. Retrieved 2011-09-28. 19. ^{{cite web |url=https://www.arin.net/policy/nrpm.html#four22 |title=ARIN Number Resource Policy Manual: Initial allocation to ISPs}} 20. ^{{cite web |url=http://www.ripe.net/ripe/docs/ripe-481#minimum_allocation |title=RIPE NCC IPv6 Address Allocation and Assignment Policy: Minimum allocation}} 21. ^1 2 {{Cite IETF|rfc=6177|bcp=157|title=IPv6 Address Assignment to End Sites|author1=T. Narten|author2=G. Houston|author3=L. Roberts|publisher=IETF|date=March 2011}} 22. ^for example. Iana.org. Retrieved on 2011-09-28. 23. ^{{cite web |title=IPv6 Addressing Plans |publisher=ARIN IPv6 Wiki |url=https://getipv6.info/display/IPv6/IPv6+Addressing+Plans |quote=All customers get one {{IPaddr||48}} unless they can show that they need more than 65k subnets. [...] If you have lots of consumer customers you may want to assign {{IPaddr||56}}s to private residence sites. |accessdate=2018-07-15}} 24. ^{{cite web|title=Address Space Managed by the RIPE NCC|url=https://www.ripe.net/ripe/docs/ripe-510|accessdate=2011-05-22}} 25. ^{{Cite IETF|rfc=2526|title=Reserved IPv6 Subnet Anycast Addresses|author1=D. Johnson|authorlink2=Steve Deering|author2=S. Deering|date=March 1999|publisher=Network Working Group}} 26. ^1 {{Cite IETF|rfc=6890|bcp=153|title=Special-Purpose IP Address Registries|author1=M. Cotton|author2=L. Vegoda|author3=R. Bonica|author4=B. Haberman|date=April 2013|publisher=Internet Engineering Task Force}} Updated by RFC 8190. 27. ^1 {{Cite IETF|rfc=6052|title=IPv6 Addressing of IPv4/IPv6 Translators|author1=C. Bao|author2=C. Huitema|author3=M. Bagnulo|author4=M. Boucadair|author5=X. Li|date=October 2010|publisher=Internet Engineering Task Force}} 28. ^1 {{Cite IETF|rfc=6666|title=A Discard Prefix for IPv6|author1=N. Hilliard|author2=D. Freedman|date=August 2012|publisher=Internet Engineering Task Force}} 29. ^1 2 {{Cite IETF|rfc=7343|title=An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)|author1=J. Laganier|author2=F. Dupont|publisher=Internet Engineering Task Force|date=September 2014}} 30. ^1 {{Cite IETF|rfc=3849|title=IPv6 Address Prefix Reserved for Documentation|author1=G. Huston|author2=A. Lord|author3=P. Smith|date=July 2004|publisher=Network Working Group}} 31. ^1 2 {{Cite IETF|rfc=7526|bcp=196|title=Deprecating the Anycast Prefix for 6to4 Relay Routers|author1=O. Troan|editor=B. Carpenter|publisher=Internet Engineering Task Force|date=May 2015}} 32. ^1 2 3 {{Cite IETF|rfc=4193|title=Unique Local IPv6 Unicast Addresses|author1=R. Hinden|author2=B. Haberman|date=October 2005|publisher=Network Working Group}} 33. ^{{Cite IETF|rfc=7915|title=Stateless IP/ICMP Translation Algorithm|author1=C. Bao|author2=X. Li|author3=F. Baker|authorlink3=Fred Baker (IETF chair)|author4=T. Anderson|author5=F. Gont|date=June 2016}} 34. ^{{Cite IETF|rfc=2928|title=Initial IPv6 Sub-TLA ID Assignments|author1=R. Hinden|author2link=Steve Deering|author2=S. Deering|author3=R. Fink|author4=T. Hain|date=September 2000|publisher=Network Working Group}} 35. ^{{Cite IETF|rfc=5180|title=IPv6 Benchmarking Methodology for Network Interconnect Devices|author1=C. Popoviciu|author2=A. Hamza|author3=G. Van de Velde|author4=D. Dugatkin|date=May 2008|publisher=Network Working Group}} 36. ^{{Cite IETF|rfc=5737|title=IPv4 Address Blocks Reserved for Documentation|author1=J. Arkko|author2=M. Cotton|author3=L. Vegoda|publisher=Internet Engineering Task Force|date=January 2010|issn=2070-1721}} 37. ^IANA Internet Protocol Version 6 Multicast Addresses. 38. ^{{Cite IETF|rfc=4862|title=IPv6 Stateless Address Autoconfiguration|author1=S. Thomson|author2=T. Narten|author3=T. Jinmei |date=September 2007|publisher=Network Working Group}} 39. ^{{Cite IETF|rfc=4861|title=Neighbor Discovery for IP version 6 (IPv6)|author1=T. Narten|author2=E. Nordmark|author3=W. Simpson|author4=H. Holiman|date=September 2007|publisher=Network Working Group}} 40. ^{{Cite news| journal=The Internet Protocol Journal| year=2006| volume=9| issue=3| pages=16–29| title=IPv6 Internals| author=Iljitsch van Beijnum |url=http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-3/ipv6_internals.html}} 41. ^The privacy implications of stateless IPv6 addressing. Portal.acm.org (2010-04-21). Retrieved on 2011-09-28. 42. ^{{Cite IETF|rfc=4941|title=Privacy Extensions for Stateless Address Autoconfiguration in IPv6|author1=T. Narten|author2=R. Draves|author3=S. Krishnan|date=September 2007|publisher=Network Working Group}} 43. ^{{Cite IETF|rfc=3972|title=Cryptographically Generated Addresses (CGA)|author=T. Aura|date=March 2005|publisher=Network Working Group IETF}} 44. ^{{Cite IETF|rfc=7217|title=A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)|author=F. Gont|date=April 2014|issn=2070-1721|publisher=IETF}} 45. ^1 {{Cite IETF|rfc=6724|title=Default Address Selection for Internet Protocol Version 6 (IPv6)|editor=D. Thaler|author1=D. Thaler|author2=R. Draves|author3=A. Matsumoto|author4=T. Chown|date=September 2012|publisher=IETF|issn=2070-1721}} 46. ^{{Cite IETF|rfc=3596|title=DNS Extensions to Support IP Version 6|author1=S. Thomson|author2=C. Huitema|author3=V. Ksinant|author4=M. Souissi|publisher=Network Working Group|date=October 2003}} 47. ^1 {{Cite IETF|rfc=1884|title=IP Version 6 Addressing Architecture|author1=R. Hinden|authorlink2=Steve Deering|author2=S. Deering|date=December 1995|publisher=Network Working Group}} 48. ^{{Cite IETF|rfc=3879|title=Deprecating Site Local Addresses|author1=C. Huitema|author2=B. Carpenter|date=September 2004|publisher=Network Working Group}} 49. ^{{Cite IETF|rfc=4147|title=Proposed Changes to the Format of the IANA IPv6 Registry|author=G. Houston|publisher=Network Working Group|date=Aug 2005}} 50. ^{{Cite IETF|rfc=1888|title=OSI NSAPs and IPv6|author1=J. Bound|author2=B. Carpenter|author3=D. Harrington|author4=J. Houldsworth|author5=A. Lloyd|date=Aug 1996|publisher=Network Working Group}} Obsoleted by RFC 4048. 51. ^{{Cite IETF|rfc=4048|title=RFC 1888 Is Obsolete|author=B. Carpenter|date=Apr 2005}} 52. ^1 {{Cite IETF|rfc=2471|title=IPv6 Testing Address Allocation|author1=R. Hinden|author2=R. Fink|authorlink3=Jon Postel|author3=J. Postel|date=Dec 1998}} Obsoleted by RFC 3701. 53. ^{{Cite IETF|rfc=3701|title=6bone (IPv6 Testing Address Allocation) Phaseout|author1=R. Fink|author2=R. Hinden|date=Mar 2004|publisher=Network Working Group}} 54. ^{{Cite IETF|rfc=4843|title=An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)|author1=P. Nikander|author2=J. Laganier|author3=F. Dupont|date=April 2007|publisher=Network Working Group}} 55. ^{{Cite IETF|rfc=3152|title=Delegation of IP6.ARPA|author=R. Bush|date=Aug 2001}} Obsoleted by RFC 3596 56. ^{{Cite IETF|rfc=3177|title=IAB/IESG Recommendations on IPv6 Address Allocations to Sites|author1=IAB|author2=IESG|date=September 2001}} 57. ^{{Cite IETF|rfc=1886|title=DNS Extensions to support IP version 6|author1=S. Thomson|author2=C. Huitema|publisher=Network Working Group|date=December 1995}} Obsoleted by RFC 3596. 58. ^{{Cite IETF|rfc=2874|title=DNS Extensions to Support IPv6 Address Aggregation and Renumbering|author1=M. Crawford|author2=C. Huitema|date=July 2000}} 59. ^[https://tools.ietf.org/html/draft-ietf-dnsext-aaaa-a6-01 Comparison of AAAA and A6 (do we really need A6?)], Jun-ichiro itojun Hagino, ({{date|July 2001}}) 60. ^1 {{Cite IETF|rfc=3363|title=Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)|author1=R. Bush|author2=A. Durand|author3=B. Fink|author4=O. Gudmundsson|author5=T. Hain|publisher=Network Working Group|date=August 2002}}. 61. ^{{Cite IETF|rfc=3364|title=Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)|author=R. Austein|publisher=Network Working Group|date=August 2002}} 62. ^1 {{Cite IETF|rfc=6536|title=Moving A6 to Historic Status|author1=S. Jiang|author2=D. Conrad|author3=B. Carpenter|date=March 2012|publisher=IETF}} 63. ^{{Cite IETF|rfc=4074|title=Common Misbehavior Against DNS Queries for IPv6 Addresses|author1=Y. Morishita|author2=T. Jinmei|date=May 2005}} References{{Reflist|40em}}External links
|last=Beijnum, van |first=Iljitsch |year=2005 |title=Running IPv6 |isbn=978-1-59059-527-5 }}
|rfc=1924 |title=A Compact Representation of IPv6 Addresses (RFC1924) |last=Elz |first=Robert |date=1996-04-01 |publisher=IETF |quote=Represent any IPv6 address in 20 octets. }} This humorous RFC specifies an alternative way of representing IPv6 addresses, using a base-85 encoding. {{IPv6}}{{DEFAULTSORT:Ipv6 Address}} 2 : IPv6|IP addresses |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识,基本涵盖了大多数领域的百科知识,是一部内容自由、开放的电子版国际百科全书。