banner



Home  ›  Which of the Following Format Can Be Considered a Valid Ipv6 Address?

Which of the Following Format Can Be Considered a Valid Ipv6 Address?

Written By Wednesday, February 16, 2022 Add Comment Edit

Label to identify a network interface of a computer or other network node

Decomposition of an IPv6 accost into its binary form

An Internet Protocol Version six address (IPv6 address) is a numeric characterization that is used to identify and locate a network interface of a computer or a network node participating in an computer network using IPv6. IP addresses are included in the packet header to bespeak 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 Cyberspace, 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 comparing, IPv6 has a vastly enlarged address space.

Addressing methods [edit]

IPv6 addresses are classified by the primary addressing and routing methodologies common in networking: unicast addressing, anycast addressing, and multicast addressing.[one]

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 fellow member interfaces, typically the nearest host, according to the routing protocol'due south definition of distance. Anycast addresses cannot be identified hands, they take the same format as unicast addresses, and differ only past their presence in the network at multiple points. Almost any unicast address tin can be employed as an anycast address.

A multicast address is also used by multiple hosts that learn the multicast accost 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 function is subsumed by multicast addressing to the all-nodes link-local multicast group ff02::1 . However, the use of the all-nodes grouping is not recommended, and most IPv6 protocols use a defended link-local multicast group to avoid agonizing every interface in the network.

Address formats [edit]

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

Unicast and anycast address format [edit]

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) sixteen (or fewer) 64
field routing prefix subnet id interface identifier

The network prefix (the routing prefix combined with the subnet id) is independent in the most pregnant 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 bachelor to the network ambassador to ascertain 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.

Unique local addresses are addresses analogous to IPv4 private network addresses.

Unique local accost format
bits 7 ane 40 sixteen 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 nada is currently not defined. The random field is called randomly one time, at the inception of the / 48 routing prefix.

A link-local accost is besides based on the interface identifier, just uses a different format for the network prefix.

Link-local accost 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 ( fe80:: / 64 link-local accost prefix), rendering them not-routable.

Multicast address format [edit]

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

General multicast address format
$.25 8 4 4 112
field prefix flg sc grouping ID

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

Currently, 3 of the four flag bits in the flg field are defined;[one] the nigh-significant flag bit is reserved for futurity use.

Multicast address flags[ii]
scrap flag Pregnant when 0 Meaning when ane
8 reserved reserved reserved
9 R (Rendezvous)[three] Rendezvous point not embedded Rendezvous point embedded
10 P (Prefix)[4] Without prefix information Address based on network prefix
eleven T (Transient)[1] Well-known multicast accost Dynamically assigned multicast address

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

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

Solicited-node multicast accost format
$.25 8 4 4 79 9 24
field prefix flg sc zeroes ones unicast accost

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

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 utilise a comparable format.[5]

Representation [edit]

An IPv6 address is represented as viii groups of 4 hexadecimal digits, each group representing 16 bits[a] The groups are separated by colons (:). An example of an IPv6 address is:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

The standards provide flexibility in the representation of IPv6 addresses. The full representation of eight four-digit groups may exist simplified past several techniques, eliminating parts of the representation. In general, representations are shortened equally much equally possible. However, this practice complicates several common operations, namely searching for a specific accost or an accost pattern in text documents or streams, and comparing addresses to determine equivalence. For mitigation of these complications, the IETF has defined a approved format for rendering IPv6 addresses in text:[8]

The hexadecimal digits are always compared in case-insensitive manner, merely IETF recommendations advise the use of only lower case messages. For instance, 2001:db8::ane is preferred over 2001:DB8::one.

Leading zeros in each sixteen-bit field are suppressed, but each group must retain at to the lowest degree one digit. For example, 2001:0db8::0001:0000 is rendered as 2001:db8::i:0 .

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 forestall ambiguities, information technology is the leftmost that is compressed. For example, 2001:db8:0:0:1:0:0:1 is rendered as 2001:db8::ane:0:0:1 rather than as 2001:db8:0:0:1::i . :: is not used to represent merely a unmarried all-zero field. For case, 2001:db8:0:0:0:0:2:1 is shortened to 2001:db8::2:1 , just 2001:db8:0000:i:ane:1:one:1 is rendered as 2001:db8:0:1:1:1:1:one .

These methods can pb to very short representations for IPv6 addresses. For example, the localhost (loopback) address, 0:0:0:0:0:0:0:ane , and the IPv6 unspecified address, 0:0:0:0:0:0:0:0 , are reduced to ::one and :: , respectively.

During the transition of the Internet from IPv4 to IPv6, it is typical to operate in a mixed addressing environment. For such apply cases, a special notation has been introduced, which expresses IPv4-mapped and IPv4-compatible IPv6 addresses by writing the least-pregnant 32 bits of an address in the familiar IPv4 dot-decimal annotation, whereas the 96 most-pregnant bits are written in IPv6 format. For example, the IPv4-mapped IPv6 accost ::ffff:c000:0280 is written as ::ffff:192.0.2.128 , thus expressing clearly the original IPv4 address that was mapped to IPv6.

Networks [edit]

An IPv6 network uses an accost cake that is a face-to-face group of IPv6 addresses of a size that is a ability 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 past the kickoff accost 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 2001:db8:1234:: / 48 starts at accost 2001:db8:1234:0000:0000:0000:0000:0000 and ends at 2001:db8:1234:ffff:ffff:ffff:ffff:ffff .

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 2001:db8:a::123 connected to subnet 2001:db8:a:: / 64 is written as 2001:db8:a::123 / 64 .

Address block sizes [edit]

The size of a cake 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 past explicitly specifying which addresses are in the block. For example, an address block with 48 $.25 in the prefix is indicated by / 48 . Such a block contains 2128 − 48 = 2lxxx addresses. The smaller the value of the network prefix, the larger the block: a / 21 block is eight times larger than a / 24 block.

Literal IPv6 addresses in network resource identifiers [edit]

Colon (:) characters in IPv6 addresses may disharmonize with the established syntax of resource identifiers, such as URIs and URLs. The colon has traditionally been used to stop the host path before a port number.[nine] To alleviate this conflict, literal IPv6 addresses are enclosed in foursquare 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 abaft 443 is the example's port number.

Scoped literal IPv6 addresses (with zone index) [edit]

For addresses with other than global scope (every bit described below), and in particular for link-local addresses, the choice of the network interface for sending a parcel may depend on which zone the address belongs to: the same address may be valid in dissimilar zones, and be in use by a unlike host in each of those zones. Fifty-fifty if a single address is non in utilize in dissimilar zones, the address prefixes for addresses in those zones may all the same exist identical, which makes the operating system unable to select an outgoing interface based on the data in the routing table (which is prefix-based).

In club to resolve the ambiguity in textual addresses, a zone alphabetize must be appended to the accost, the two separated past a percentage sign (%).[10] The syntax of zone indices is an implementation-dependent cord, although numeric zone indices must be universally supported equally well. The link-local address

fe80::1ff:fe23:4567:890a

could be expressed by

fe80::1ff:fe23:4567:890a%eth2

or:

fe80::1ff:fe23:4567:890a%three

The former (using an interface[ disambiguation needed ] name) is customary on almost Unix-like operating systems (e.g., BSD, Linux, macOS). The latter (using an interface number) is the standard syntax on Microsoft Windows, merely as support for this syntax is mandatory, it is besides available on other operating systems.

BSD-based operating systems (including macOS) as well back up an alternative, non-standard syntax, where a numeric zone alphabetize is encoded in the second 16-bit give-and-take of the address. Eastward.thou.:

fe80:iii::1ff:fe23:4567:890a

In all operating systems mentioned higher up, 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 continued to the aforementioned switch), in practice two addresses with unlike zone identifiers may actually be equivalent, and refer to the aforementioned host on the aforementioned link.

Use of zone indices in URIs [edit]

When used in uniform resources identifiers (URI), the use of the percent sign causes a syntax conflict, therefore it must exist escaped via percent-encoding,[11] due east.g.:

http://[fe80::1ff:fe23:4567:890a%25eth0]/

Literal IPv6 addresses in UNC path names [edit]

In Microsoft Windows operating systems, IPv4 addresses are valid location identifiers in Uniform Naming Convention (UNC) path names. However, the colon is an illegal grapheme 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 proper noun that can exist used in UNC paths. For this purpose, Microsoft registered and reserved the second-level domain ipv6-literal.net on the Internet (although they gave upwardly the domain in January 2014[12]). IPv6 addresses are transcribed as a hostname or subdomain name inside this name space, in the following style:

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 alphabetize, it is appended to the address portion later on an 'southward' character:

fe80::1ff:fe23:4567:890a%iii

is written as

fe80--1ff-fe23-4567-890as3.ipv6-literal.cyberspace

Address scopes [edit]

Every IPv6 address, except the unspecified address ( :: ), has a "scope",[ten] which specifies in which part of the network information technology is valid.

Unicast [edit]

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

Link-local addresses and the loopback address accept link-local telescopic, which means they can only be used on a single directly fastened 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 telescopic on the directly fastened network. Packets with a source or destination in i telescopic cannot be routed to a different scope.[thirteen]

Unique local addresses have global scope, only they are non globally administered. Every bit a result, only other hosts in the same administrative domain (eastward.g., an system), or within a cooperating administrative domain are able to reach such addresses, if properly routed. Every bit their scope is global, these addresses are valid as a source address when communicating with whatsoever other global-scope accost, even though it may be incommunicable to route packets from the destination back to the source.

Anycast [edit]

Anycast addresses are syntactically identical to and duplicate from unicast addresses. Their but deviation is administrative. Scopes for anycast addresses are therefore the same as for unicast addresses.

Multicast [edit]

For multicast addresses, the four least-pregnant bits of the 2nd address octet ( ff0south:: ) place the accost due southcope, i.east. the domain in which the multicast parcel should be propagated. Predefined and reserved scopes[1] are:

Scope values
Value Telescopic proper name Notes
0x0 reserved
0x1 interface-local Interface-local scope spans only a single interface on a node, and is useful but for loopback transmission of multicast.
0x2 link-local Link-local telescopic spans the same topological region as the corresponding unicast scope.
0x3 realm-local Realm-local telescopic is defined as larger than link-local, automatically determined by network topology and must not exist larger than the following scopes.[14]
0x4 admin-local Admin-local scope is the smallest scope that must exist 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 system-local Organisation-local scope is intended to bridge all sites belonging to a single organization.
0xe global Global scope spans all reachable nodes on the net - information technology is unbounded.
0xf reserved

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

Address space [edit]

General allocation [edit]

The management of IPv6 address resource allotment procedure is delegated to the Cyberspace Assigned Numbers Authority (IANA)[15] past the Internet Compages Lath and the Internet Applied science Steering Group. Its main function is the consignment of large accost 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 accost space since Dec 1995.[16]

Only one 8th of the total address space is currently allocated for use on the Internet, 2000:: / 3 , in order to provide efficient road 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 big blocks of / 23 up to / 12 .[17]

The RIRs assign smaller blocks to local Internet registries that distributes them to users. These are typically in sizes from / 19 to / 32 .[18] [19] [twenty] The addresses are typically distributed in / 48 to / 56 sized blocks to the end users.[21]

Global unicast assignment records can exist found at the diverse 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 / 48 block which contains 280 addresses, being 248 or nearly 2.8×10xiv times larger than the entire IPv4 address space of 232 addresses and well-nigh 7.2×1016 times larger than the / 8 blocks of IPv4 addresses, which are the largest allocations of IPv4 addresses. The total puddle, yet, is sufficient for the foreseeable future, considering there are 2128 (exactly 340,282,366,920,938,463,463,374,607,431,768,211,456) or about 3.4×1038 (340 trillion trillion trillion) unique IPv6 addresses.

Each RIR can dissever each of its multiple / 23 blocks into 512 / 32 blocks, typically one for each ISP; an Isp tin can divide its / 32 cake into 65536 / 48 blocks, typically one for each customer;[23] customers can create 65536 / 64 networks from their assigned / 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 4.3×109 ) addresses.

Past blueprint, just a very small fraction of the address space volition really be used. The big address infinite ensures that addresses are almost always bachelor, which makes the utilize of network accost 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 resource allotment [edit]

To 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 2001:678:: / 29 .

Internet Exchange Points (IXPs) are assigned special addresses from the ranges 2001:7f8:: / 32 , 2001:504:: / 30 , and 2001:7fa:: / 32 [24] for communication with their connected ISPs.

Root name servers have been assigned addresses from the range 2001:7f8:: / 29 .[25]

Reserved anycast addresses [edit]

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

The 128 highest addresses within each / 64 subnet prefix are reserved to be used every bit anycast addresses.[26] These addresses usually have the kickoff 57 $.25 of the interface identifier gear up to 1, followed by the seven-bit anycast ID. Prefixes for the network, including subnets, are required to take a length of 64 bits, in which example the universal/local chip must exist set to 0 to indicate the address is not globally unique. The accost with value 0x7e in the 7 to the lowest degree-significant $.25 is divers as a mobile IPv6 abode agents anycast address. The address with value 0x7f (all bits 1) is reserved and may not be used. No more than assignments from this range are fabricated, then values 0x00 through 0x7d are reserved as well.

Special addresses [edit]

There are a number of addresses with special meaning in IPv6.[27] They represent less than 2% of the unabridged accost space:

Special address blocks
Address block (CIDR) Start address Last address Number of addresses Usage Purpose
::/0 :: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2128 Routing Default road (no specific road)
::/128 :: :: 1 Software Unspecified address
::i/128 ::1 ::i one Host Loopback accost—a virtual interface that loops all traffic dorsum to itself, the local host
::ffff:0:0/96 ::ffff:0.0.0.0 ::ffff:255.255.255.255 2128 − 96 = 232 = 4294 967 296 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 Global Internet IPv4/IPv6 translation[28]
64:ff9b:1::/48 64:ff9b:one::0.0.0.0 64:ff9b:1:ffff:ffff:ffff:255.255.255.255 280 Individual internets IPv4/IPv6 translation[29]
100::/64 100:: 100::ffff:ffff:ffff:ffff ii64 Routing Discard prefix[xxx]
2001:0000::/32 2001:: 2001::ffff:ffff:ffff:ffff:ffff:ffff ii96 Global Cyberspace Teredo tunneling[31]
2001:20::/28 2001:20:: 2001:2f:ffff:ffff:ffff:ffff:ffff:ffff 2100 Software ORCHIDv2[32]
2001:db8::/32 2001:db8:: 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff ii96 Documentation Addresses used in documentation and example source code[33]
2002::/xvi 2002:: 2002:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2112 Global Cyberspace The 6to4 addressing scheme (deprecated)[34]
fc00::/seven fc00:: fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2121 Private internets Unique local address[35]
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 Global Internet Multicast address

Unicast addresses [edit]

Default route [edit]

  • :: / 0 — The default route address (respective to 0.0.0.0 / 0 in IPv4) for destination addresses (unicast, multicast and others) not specified elsewhere in a routing tabular array.

Unspecified address [edit]

  • :: / 128 — The address with all zero $.25 is chosen the unspecified address (respective to 0.0.0.0 / 32 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 non forward packets with the unspecified accost.
    Applications may exist listening on ane 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.

Local addresses [edit]

  • ::i / 128 — The loopback accost is a unicast localhost address (respective to 127.0.0.i / 8 in IPv4).
    If an application in a host sends packets to this address, the IPv6 stack volition loop these packets dorsum on the same virtual interface.
  • fe80:: / 10 — Addresses in the link-local prefix are only valid and unique on a single link (comparable to the motorcar-configuration addresses 169.254.0.0 / sixteen of IPv4).
    Within this prefix only one subnet is allocated (54 zero bits), yielding an effective format of fe80:: / 64 . The least significant 64 bits are commonly chosen as the interface hardware address constructed in modified EUI-64 format. A link-local address is required on every IPv6-enabled interface—in other words, applications may rely on the being of a link-local address even when at that place is no IPv6 routing.

Unique local addresses [edit]

  • fc00:: / seven — Unique local addresses (ULAs) are intended for local communication[35] (comparable to IPv4 private addresses 10.0.0.0 / 8 , 172.16.0.0 / 12 and 192.168.0.0 / 16 ).
    They are routable only within a set of cooperating sites. The block is split into ii halves. The lower half of the block ( fc00:: / 8 ) was intended for globally allocated prefixes, but an allocation method has yet to exist divers. The upper half ( fd00:: / 8 ) is used for "probabilistically unique" addresses in which the / eight prefix is combined with a forty-scrap locally generated pseudorandom number to obtain a / 48 private prefix. The mode in which such a 40-bit number is chosen results in merely a negligible gamble that ii sites that wish to merge or communicate with each other will use the aforementioned 40-bit number, and thus use the aforementioned / 48 prefix.[35]

Transition from IPv4 [edit]

  • ::ffff:0:0 / 96 — 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 utilise of the transport layer protocols over IPv4 through the IPv6 networking awarding programming interface. Server applications just need to open a single listening socket to handle connections from clients using IPv6 or IPv4 protocols. IPv6 clients will be handled natively by default, and IPv4 clients appear as IPv6 clients at their IPv4-mapped IPv6 accost. 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.
  • ::ffff:0:0:0 / 96 — A prefix used for IPv4-translated addresses.
    These are used by the Stateless IP/ICMP Translation (SIIT) protocol.[36]
  • 64:ff9b:: / 96 — The "Well-Known" Prefix.
    Addresses with this prefix are used for automated IPv4/IPv6 translation.[28]
  • 64:ff9b:1:: / 48 — 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.[29]
  • 2002:: / 16 — This prefix was used for 6to4 addressing (an address from the IPv4 network 192.88.99.0 / 24 was also used).
    The 6to4 addressing scheme is deprecated.[34]

Main article: 6to4

Special-purpose addresses [edit]

IANA has reserved a and so-called 'Sub-TLA ID' address block for special assignments[27] [37] of 2001:: / 23 (split into the range of 64 network prefixes 2001:0000:: / 29 through 2001:01f8:: / 29 ). Iii assignments from this block are currently assigned:
  • 2001:: / 32 — Used for Teredo tunneling.
  • 2001:ii:: / 48 — Used for benchmarking IPv6 (corresponding to 198.18.0.0 / xv for benchmarking IPv4).
    Assigned to the Benchmarking Methodology Working Group (BMWG).[38]
  • 2001:20:: / 28 — ORCHIDv2 (Overlay Routable Cryptographic Hash Identifiers).[32]
    These are non-routed IPv6 addresses used for Cryptographic Hash Identifiers.

Documentation [edit]

  • 2001:db8:: / 32 — This prefix is used in documentation[33] (corresponding to 192.0.2.0 / 24 , 198.51.100.0 / 24 , and 203.0.113.0 / 24 in IPv4.)[39]
    The addresses should be used anywhere an example IPv6 address is given or model networking scenarios are described.

Discard [edit]

  • 100:: / 64 — This prefix is used for discarding traffic.[30]

Deprecated and obsolete addresses [edit]

Farther information: § Historical notes

Multicast addresses [edit]

The multicast addresses ff0x:: where x is any hexadecimal value are reserved[1] and should not be assigned to whatsoever multicast group. The Internet Assigned Numbers Authority (IANA) manages accost reservations.[xl]

Some common IPv6 multicast addresses are the post-obit:

Address Description Available Scopes
ff0X::one All nodes address, identify the group of all IPv6 nodes Available in scope ane (interface-local) and 2 (link-local):
  • ff01::1 → All nodes in the interface-local
  • ff02::1 → All nodes in the link-local
ff0X::2 All routers Available in scope 1 (interface-local), two (link-local) and five (site-local):
  • ff01::2 → All routers in the interface-local
  • ff02::2 → All routers in the link-local
  • ff05::2 → All routers in the site-local
ff02::5 OSPFIGP ii (link-local)
ff02::6 OSPFIGP designated routers 2 (link-local)
ff02::nine RIP routers 2 (link-local)
ff02::a EIGRP routers ii (link-local)
ff02::d All PIM routers 2 (link-local)
ff02::1a All RPL routers 2 (link-local)
ff0X::fb mDNSv6 Available in all scopes
ff0X::101 All NTP servers Available in all scopes
ff02::1:one Link proper name 2 (link-local)
ff02::1:2 All-dhcp-agents (DHCPv6) 2 (link-local)
ff02::one:3 Link-local multicast name resolution 2 (link-local)
ff05::1:3 All-dhcp-servers (DHCPv6) 5 (site-local)
ff02::1:ff00:0/104 Solicited-node multicast address. See beneath 2 (link-local)
ff02::2:ff00:0/104 Node information queries 2 (link-local)

Solicited-node multicast address [edit]

The least significant 24 $.25 of the solicited-node multicast address grouping ID are filled with the least pregnant 24 bits of the interface'south unicast or anycast accost. These addresses let 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 [edit]

On system startup, a node automatically creates a link-local accost on each IPv6-enabled interface, even if globally routable addresses are manually configured or obtained through "configuration protocols" (meet below). Information technology does so independently and without whatever prior configuration past stateless address autoconfiguration (SLAAC),[41] using a component of the Neighbor Discovery Protocol. This address is selected with the prefix fe80:: / 64 .

In IPv4, typical "configuration protocols" include DHCP or PPP. Although DHCPv6 exists, IPv6 hosts normally utilize 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.[42]

The lower 64 $.25 of these addresses are populated with a 64-fleck 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 exist joined for neighbor discovery. For this, a multicast address is used, formed from the network prefix ff02::1:ff00:0 / 104 and the 24 least meaning bits of the address.

Modified EUI-64 [edit]

A 64-bit interface identifier is well-nigh commonly derived from its 48-bit MAC address. A MAC address 00-0C-29-0C-47-D5 is turned into a 64-bit EUI-64 by inserting FF-Fe in the middle: 00-0C-29-FF-FE-0C-47-D5 . When this EUI-64 is used to form an IPv6 address, it is modified:[ane] the pregnant of the Universal/Local scrap (the 7th almost significant chip of the EUI-64, starting from 1) is inverted, so that a 1 at present means Universal. To create an IPv6 address with the network prefix 2001:db8:1:2:: / 64 it yields the address 2001:db8:i:2:0ii0c:29ff:fe0c:47d5 (with the Universal/Local flake, the second-least-significant chip of the underlined quartet, inverted to one in this instance because the MAC address is universally unique).

Duplicate address detection [edit]

The consignment 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 blazon 135 and 136) messages. While in the process of establishing uniqueness an address has a tentative land.

The node joins the solicited-node multicast address for the tentative address (if not already done and so) and sends neighbor solicitations, with the tentative accost as target accost and the unspecified address ( :: / 128 ) equally source address. The node likewise joins the all-hosts multicast accost ff02::one , so it will be able to receive Neighbor Advertisements.

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

Address lifetime [edit]

Each IPv6 address that is bound to an interface has a stock-still lifetime. Lifetimes are infinite, unless configured to a shorter menses. At that place are ii lifetimes that govern the state of an address: the preferred lifetime and the valid lifetime.[43] Lifetimes tin can exist 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 information technology holds during its preferred-lifetime. After that lifetime expires the condition becomes "deprecated" and no new connections should be made using this address. The accost becomes "invalid" afterward its valid-lifetime likewise expires; the accost is removed from the interface and may exist assigned somewhere else on the Internet.

Annotation: In most cases, the lifetime does not elapse because new Router Advertisements (RAs) refresh the timers. But if there are no more than RAs, eventually the preferred lifetime elapses and the address becomes "deprecated".

Temporary addresses [edit]

The globally unique and static MAC addresses, used past stateless address autoconfiguration to create interface identifiers, offer an opportunity to rails user equipment—across time and IPv6 network prefix changes—and so users.[44] 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 flake strings[45] and relatively brusk lifetimes (hours to days), after which they are replaced with new addresses.

Temporary addresses may exist used as source address for originating connections, while external hosts utilize a public address by querying the Domain Proper noun System.

Network interfaces configured for IPv6 use temporary addresses by default in Os X Lion and later Apple systems likewise every bit in Windows Vista, Windows 2008 Server and after Microsoft systems.

Cryptographically generated addresses [edit]

As a means to enhance security for Neighbor Discovery Protocol cryptographically generated addresses (or CGAs) were introduced in 2005[46] as function of the Secure Neighbor Discovery (Send) Protocol.

Such an accost 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 cipher bits of the resulting hash is acquired. (Comparable with the 'proof of work' field in Bitcoin mining.) The second hash role takes the network prefix and the previous hash value. The least significant 64 bits of the second hash outcome is appended to the 64-bit network prefix to form a 128-chip address.

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

Stable privacy addresses [edit]

The use of stateless autoconfigured addresses has serious implications for security and privacy concerns,[47] because the underlying hardware address (most typically the MAC address) is exposed across 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 infinite for searching for assail targets.

Stable privacy addresses were introduced to remedy these shortcomings. They are stable within a specific network only modify when moving to another, to ameliorate privacy. They are chosen deterministically, just randomly, in the unabridged address space of the network.

Generation of a stable privacy address is based on a hash role that uses several stable parameters. Information technology is implementation specific, just it is recommended to use at least the network prefix, the proper name of the network interface, a indistinguishable address counter, and a surreptitious key. The resulting hash value is used to construct the terminal accost: Typically the 64 least significant $.25 are concatenated to the 64-chip network prefix, to yield a 128-bit address. If the network prefix is smaller than 64 bits, more than $.25 of the hash are used. If the resulting accost does non conflict with existing or reserved addresses, information technology is assigned to the interface.

Default address option [edit]

IPv6-enabled network interfaces normally accept more than than ane IPv6 address, for example, a link-local and a global accost. They may besides have temporary addresses that modify after a certain lifetime has expired. IPv6 introduces the concepts of address scope and selection preference, yielding multiple choices for source and destination accost selections in advice with another host.

The preference selection algorithm published in RFC 6724 selects the most appropriate address to use in communications with a detail destination, including the use of IPv4-mapped addresses in dual-stack implementations.[48] It uses a configurable preference table that associates each routing prefix with a precedence level. The default table has the post-obit content:[48]

Prefix Precedence Label Usage
::i/128 50 0 Localhost
::/0 40 1 Default unicast
::ffff:0:0/96 35 iv IPv4-mapped IPv6 address
2002::/sixteen 30 2 6to4
2001::/32 5 5 Teredo tunneling
fc00::/7 three 13 Unique local address
::/96 1 3 IPv4-compatible addresses (deprecated)
fec0::/10 1 eleven Site-local address (deprecated)
3ffe::/16 ane 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 tabular array, with the precedence value serving as the role of a link toll, where higher preference is expressed as a larger value. Source addresses are preferred to take the same label value as the destination address. Addresses are matched to prefixes based on the longest matching nigh-meaning bit-sequence. Candidate source addresses are obtained from the operating system and candidate destination addresses may be queried via the Domain Name Arrangement (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 Organisation for IPv6 and IPv4 addresses of the target host, sorts candidate addresses using the default address selection table, and tries to plant connections in parallel. The commencement connection that is established aborts current and future attempts to connect to other addresses.

Domain Name Arrangement [edit]

In the Domain Proper name System, hostnames are mapped to IPv6 addresses by AAAA resource records, so-called quad-A records.[49] 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.

Equally in IPv4, each host is represented in the DNS by ii DNS records: an accost record and a reverse mapping pointer record. For example, a host calculator named derrick in zone case.com has the Unique Local Address fdda:5cc1:23:4::1f . Its quad-A address tape is 

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

and its IPv6 pointer record is 

          f.ane.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.iii.2.0.0.one.c.c.5.a.d.d.f.ip6.arpa.  IN  PTR   derrick.example.com.

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

The DNS protocol is independent of its send layer protocol. Queries and replies may exist 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 (i)
TTL Time to alive in seconds
RDLENGTH Length of RDATA field
RDATA 128-bit IPv6 address, network byte society

Historical notes [edit]

Deprecated and obsolete addresses [edit]

  • The site-local prefix fec0:: / 10 specifies that the accost is valid only within the site network of an organization. Information technology was part of the original addressing architecture[50] in December 1995, but its use was deprecated in September 2004[51] because the definition of the term site was cryptic, which led to confusing routing rules. New networks must non support this special type of address. In October 2005, a new specification[35] replaced this address blazon with unique local addresses.
  • The address cake 200:: / seven was defined as an OSI NSAP-mapped prefix set in August 1996,[52] [53] simply was deprecated in December 2004.[54]
  • The 96-chip zip-value prefix :: / 96 , originally known every bit IPv4-compatible addresses, was mentioned in 1995[50] but first described in 1998.[55] [ failed verification ] This range of addresses was used to represent IPv4 addresses within an IPv6 transition engineering. Such an IPv6 accost has its outset (most significant) 96 bits fix to zero, while its last 32 $.25 are the IPv4 accost that is represented. In February 2006, the Internet Applied science Task Force (IETF) deprecated the use of IPv4-compatible addresses.[1] The only remaining utilize of this address format is to stand for an IPv4 address in a tabular array or database with stock-still size members that must also be able to store an IPv6 accost.
  • Accost block 3ffe:: / 16 was allocated for test purposes for the 6bone network in December 1998.[55] Prior to that, the accost block 5f00:: / 8 was used for this purpose. Both accost blocks were returned to the address puddle in June 2006.[56]
  • Due to operational bug with 6to4 the use of address block 2002:: / 16 is diminishing, since the 6to4 machinery is deprecated since May 2015.[34] Although IPv4 address block 192.88.99.0 / 24 is deprecated, 2002:: / 16 is not.
  • In April 2007 the address block 2001:10:: / 28 was assigned for Overlay Routable Cryptographic Hash Identifiers (ORCHID).[57] It was intended for experimental use. In September 2014 a 2nd version of ORCHID was specified,[32] and with the introduction of block 2001:xx:: / 28 the original block was returned to IANA.

Miscellaneous [edit]

  • For reverse DNS lookup, IPv6 addresses were originally registered in the DNS zone ip6.int, because it was expected that the tiptop-level domain arpa would be retired. In 2000, the Internet Compages 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[58] 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.[21] Instead of assigning either a / 48 , / 64 , or / 128 (according to IAB's and IESG'south views of 2001),[59] Internet service providers should consider assigning smaller blocks (for example a / 56 ) to cease users. The ARIN, RIPE & APNIC regional registries' policies encourage / 56 assignments where appropriate.[21]
  • Originally, two proposals existed for translating domain names to IPv6 addresses: one using AAAA records,[60] the other using A6 records.[61] 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 past boosted A6 records, providing the possibility to renumber all hosts in a network by changing a single A6 record. Equally the perceived benefits of the A6 format were not deemed to outweigh the perceived costs,[62] [63] [64] [65] the method was moved to experimental condition in 2002,[63] and finally to historic condition in 2012.[65]
  • In 2009, many DNS resolvers in home-networking NAT devices and routers were found to handle AAAA records improperly.[66] 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 look for a timeout to trigger. This oftentimes causes a slow-down when connecting to dual-stack IPv6/IPv4 hosts, as the client software will wait for the IPv6 connection to fail before trying IPv4.

Notes [edit]

  1. ^ A 16 bit or 2 octet quantity is sometimes also called a hextet.[6] [7]

References [edit]

  1. ^ a b c d e f k h i R. Hinden; S. Deering (February 2006). IP Version six Addressing Architecture. Network Working Group. doi:10.17487/RFC4291. RFC 4291. Updated by: RFC 5952, RFC 6052, RFC 7136, RFC 7346, RFC 7371, RFC 8064.
  2. ^ Silvia Hagen (May 2006). IPv6 Essentials (Second ed.). O'Reilly. ISBN978-0-596-10058-ii.
  3. ^ a b P. Savola; B. Haberman (Nov 2004). Embedding the Rendezvous Betoken (RP) Address in an IPv6 Multicast Address. Network Working Group. doi:10.17487/RFC3956. RFC 3956.
  4. ^ a b B. Haberman; D. Thaler (August 2002). Unicast-Prefix-based IPv6 Multicast Addresses. Network Working Group. doi:10.17487/RFC3306. RFC 3306.
  5. ^ J-Due south. Park; Thousand-Thou. Shin; H-J. Kim (April 2006). A Method for Generating Link-Scoped IPv6 Multicast Addresses. Network Working Group. doi:x.17487/RFC4489. RFC 4489.
  6. ^ Graziani, Rick (2012). IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6. Cisco Press. p. 55. ISBN978-0-xiii-303347-2.
  7. ^ Coffeen, Tom (2014). IPv6 Address Planning: Designing an Address Plan for the Time to come. O'Reilly Media. p. 170. ISBN978-i-4919-0326-1.
  8. ^ S. Kawamura; Thou. Kawashima (Baronial 2010). A Recommendation for IPv6 Address Text Representation. IETF. doi:10.17487/RFC5952. ISSN 2070-1721. RFC 5952.
  9. ^ T. Berners-Lee; R. Fielding; L. Masinter (Jan 2005). Uniform Resources Identifier (URI): Generic Syntax. Network Working Group. doi:10.17487/RFC3986. STD 66. RFC 3986.
  10. ^ a b S.Deering; B. Haberman; T. Jinmei; E. Nordmark; B. Zill (March 2005). IPv6 Scoped Address Architecture. Network Working Group. doi:ten.17487/RFC4007. RFC 4007.
  11. ^ B. Carpenter; Southward. Cheshire; R. Hinden (February 2013). Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers. IETF. doi:ten.17487/RFC6874. RFC 6874. Updates RFC 3986.
  12. ^ "ipv6-literal.net Domain History". who.is. Retrieved 20 October 2014.
  13. ^ "Scope zones". IBM Knowledge Centre. 27 September 2013. Retrieved xiii December 2019. Packets that comprise a source or destination address of a given scope can be routed just within the aforementioned scope zone, and cannot be routed between different scope zone instances.
  14. ^ R Droms (August 2014). IPv6 Multicast Accost Scopes. IETF. doi:10.17487/RFC7346. ISSN 2070-1721. RFC 7346.
  15. ^ IPv6 Address Allocation Management. Network Working Group, IETF. December 1995. doi:x.17487/RFC1881. RFC 1881.
  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. ^ "ARIN Number Resources Policy Manual: Initial allocation to ISPs".
  20. ^ "RIPE NCC IPv6 Address Allocation and Consignment Policy: Minimum allocation".
  21. ^ a b c T. Narten; G. Houston; L. Roberts (March 2011). IPv6 Address Assignment to End Sites. IETF. doi:ten.17487/RFC6177. BCP 157. RFC 6177.
  22. ^ for example. Iana.org. Retrieved on 2011-09-28.
  23. ^ "IPv6 Addressing Plans". ARIN IPv6 Wiki. Retrieved 2018-07-xv . All customers get i / 48 unless they can evidence that they demand more than 65k subnets. [...] If you take lots of consumer customers you may desire to assign / 56 s to private residence sites.
  24. ^ "What are Bogons?". Retrieved 2021-11-15 .
  25. ^ "Address Infinite Managed by the RIPE NCC". Retrieved 2011-05-22 .
  26. ^ D. Johnson; Southward. Deering (March 1999). Reserved IPv6 Subnet Anycast Addresses. Network Working Group. doi:10.17487/RFC2526. RFC 2526.
  27. ^ a b One thousand. Cotton; L. Vegoda; R. Bonica; B. Haberman (April 2013). Special-Purpose IP Address Registries. Internet Engineering Chore Forcefulness. doi:10.17487/RFC6890. BCP 153. RFC 6890. Updated past RFC 8190.
  28. ^ a b C. Bao; C. Huitema; M. Bagnulo; Grand. Boucadair; X. Li (October 2010). IPv6 Addressing of IPv4/IPv6 Translators. Cyberspace Engineering science Job Force. doi:x.17487/RFC6052. RFC 6052.
  29. ^ a b T. Anderson (August 2017). Local-Use IPv4/IPv6 Translation Prefix. Cyberspace Engineering Task Force. doi:10.17487/RFC8215. RFC 8215.
  30. ^ a b N. Hilliard; D. Freedman (August 2012). A Discard Prefix for IPv6. Internet Engineering science Task Force. doi:ten.17487/RFC6666. RFC 6666.
  31. ^ RFC 4680
  32. ^ a b c J. Laganier; F. Dupont (September 2014). An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2). Internet Engineering Task Strength. doi:ten.17487/RFC7343. RFC 7343.
  33. ^ a b M. Huston; A. Lord; P. Smith (July 2004). IPv6 Address Prefix Reserved for Documentation. Network Working Group. doi:10.17487/RFC3849. RFC 3849.
  34. ^ a b c O. Troan (May 2015). B. Carpenter (ed.). Deprecating the Anycast Prefix for 6to4 Relay Routers. Internet Engineering Chore Forcefulness. doi:10.17487/RFC7526. BCP 196. RFC 7526.
  35. ^ a b c d R. Hinden; B. Haberman (October 2005). Unique Local IPv6 Unicast Addresses. Network Working Group. doi:ten.17487/RFC4193. RFC 4193.
  36. ^ C. Bao; X. Li; F. Bakery; T. Anderson; F. Gont (June 2016). Stateless IP/ICMP Translation Algorithm. doi:10.17487/RFC7915. RFC 7915.
  37. ^ R. Hinden; S. Deering; R. Fink; T. Hain (September 2000). Initial IPv6 Sub-TLA ID Assignments. Network Working Group. doi:10.17487/RFC2928. RFC 2928.
  38. ^ C. Popoviciu; A. Hamza; G. Van de Velde; D. Dugatkin (May 2008). IPv6 Benchmarking Methodology for Network Interconnect Devices. Network Working Group. doi:10.17487/RFC5180. RFC 5180.
  39. ^ J. Arkko; 1000. Cotton; L. Vegoda (January 2010). IPv4 Accost Blocks Reserved for Documentation. Net Engineering science Chore Forcefulness. doi:10.17487/RFC5737. ISSN 2070-1721. RFC 5737.
  40. ^ IANA Cyberspace Protocol Version half-dozen Multicast Addresses.
  41. ^ S. Thomson; T. Narten; T. Jinmei (September 2007). IPv6 Stateless Address Autoconfiguration. Network Working Group. doi:10.17487/RFC4862. RFC 4862.
  42. ^ T. Narten; E. Nordmark; Westward. Simpson; H. Holiman (September 2007). Neighbor Discovery for IP version 6 (IPv6). Network Working Group. doi:x.17487/RFC4861. RFC 4861.
  43. ^ Iljitsch van Beijnum (2006). "IPv6 Internals". The Internet Protocol Periodical. Vol. 9, no. iii. pp. 16–29.
  44. ^ The privacy implications of stateless IPv6 addressing. Portal.acm.org (2010-04-21). Retrieved on 2011-09-28.
  45. ^ T. Narten; R. Draves; S. Krishnan (September 2007). Privacy Extensions for Stateless Address Autoconfiguration in IPv6. Network Working Group. doi:10.17487/RFC4941. RFC 4941.
  46. ^ T. Aura (March 2005). Cryptographically Generated Addresses (CGA). Network Working Group IETF. doi:10.17487/RFC3972. RFC 3972.
  47. ^ F. Gont (April 2014). A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC). IETF. doi:ten.17487/RFC7217. ISSN 2070-1721. RFC 7217.
  48. ^ a b D. Thaler; R. Draves; A. Matsumoto; T. Chown (September 2012). D. Thaler (ed.). Default Accost Choice for Internet Protocol Version 6 (IPv6). IETF. doi:ten.17487/RFC6724. ISSN 2070-1721. RFC 6724.
  49. ^ S. Thomson; C. Huitema; V. Ksinant; M. Souissi (October 2003). DNS Extensions to Support IP Version 6. Network Working Group. doi:10.17487/RFC3596. RFC 3596.
  50. ^ a b R. Hinden; S. Deering (December 1995). IP Version 6 Addressing Architecture. Network Working Group. doi:10.17487/RFC1884. RFC 1884.
  51. ^ C. Huitema; B. Carpenter (September 2004). Deprecating Site Local Addresses. Network Working Group. doi:10.17487/RFC3879. RFC 3879.
  52. ^ G. Houston (Aug 2005). Proposed Changes to the Format of the IANA IPv6 Registry. Network Working Grouping. doi:10.17487/RFC4147. RFC 4147.
  53. ^ J. Spring; B. Carpenter; D. Harrington; J. Houldsworth; A. Lloyd (Aug 1996). OSI NSAPs and IPv6. Network Working Group. doi:10.17487/RFC1888. RFC 1888. Obsoleted by RFC 4048.
  54. ^ B. Carpenter (Apr 2005). RFC 1888 Is Obsolete. doi:10.17487/RFC4048. RFC 4048.
  55. ^ a b R. Hinden; R. Fink; J. Postel (Dec 1998). IPv6 Testing Address Allocation. doi:10.17487/RFC2471. RFC 2471. Obsoleted by RFC 3701.
  56. ^ R. Fink; R. Hinden (Mar 2004). 6bone (IPv6 Testing Address Allocation) Phaseout. Network Working Grouping. doi:10.17487/RFC3701. RFC 3701.
  57. ^ P. Nikander; J. Laganier; F. Dupont (April 2007). An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID). Network Working Group. doi:10.17487/RFC4843. RFC 4843.
  58. ^ R. Bush-league (Aug 2001). Delegation of IP6.ARPA. doi:10.17487/RFC3152. RFC 3152. Obsoleted by RFC 3596
  59. ^ IAB; IESG (September 2001). IAB/IESG Recommendations on IPv6 Address Allocations to Sites. doi:10.17487/RFC3177. RFC 3177.
  60. ^ S. Thomson; C. Huitema (December 1995). DNS Extensions to support IP version six. Network Working Grouping. doi:ten.17487/RFC1886. RFC 1886. Obsoleted past RFC 3596.
  61. ^ M. Crawford; C. Huitema (July 2000). DNS Extensions to Support IPv6 Address Aggregation and Renumbering. doi:ten.17487/RFC2874. RFC 2874.
  62. ^ Comparison of AAAA and A6 (exercise we really need A6?), Jun-ichiro itojun Hagino, (July 2001)
  63. ^ a b R. Bush; A. Durand; B. Fink; O. Gudmundsson; T. Hain (August 2002). Representing Cyberspace Protocol version 6 (IPv6) Addresses in the Domain Name Organisation (DNS). Network Working Grouping. doi:ten.17487/RFC3363. RFC 3363. .
  64. ^ R. Austein (August 2002). Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version six (IPv6). Network Working Group. doi:10.17487/RFC3364. RFC 3364.
  65. ^ a b S. Jiang; D. Conrad; B. Carpenter (March 2012). Moving A6 to Historic Status. IETF. doi:10.17487/RFC6536. RFC 6536.
  66. ^ Y. Morishita; T. Jinmei (May 2005). Mutual Misbehavior Against DNS Queries for IPv6 Addresses. doi:10.17487/RFC4074. RFC 4074.

External links [edit]

  • IP Version 6 multicast addresses
  • Beijnum, van, Iljitsch (2005). Running IPv6. ISBN978-ane-59059-527-five.
  • Elz, Robert (1996-04-01). A Compact Representation of IPv6 Addresses (RFC1924). IETF. doi:10.17487/RFC1924. RFC 1924. Correspond any IPv6 accost in twenty octets. This humorous RFC specifies an alternative manner of representing IPv6 addresses, using a base of operations-85 encoding.

denisonopinkh78.blogspot.com

Source: https://en.wikipedia.org/wiki/IPv6_address

0 Response to "Which of the Following Format Can Be Considered a Valid Ipv6 Address?"

Post a Comment

Subscribe to: Post Comments (Atom)

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel