Talk:IPv6 address

Final Stages

Okay, I think I've finished my editing of the page. Things that remain to be done:

• write a short (two or three paragraphs) summary to include in the Addressing section of the IPv6 page;
• write a structure section, about addresses being 128 bits, host numbers and stuff;
• rewrite the introduction completely, remove anything that went into the Structure section, remove all the silly "my address space is larger than your address space" stuff written by people who don't understand logarithms.--Jec (talk) 21:51, 2 November 2009 (UTC)

Thanks for your input, Jec. Please elaborate on how to change the introduction into a structure section and your comment on 'logarithms'. IPv6 address space is larger (and for good reason) than IPv4 address space and should be at least mentioned in some form or other. Please indicate your view on how to introduce the 'larger address space' without becoming silly. —— _D^an_d^or ⁱ_D (talk) 14:11, 3 November 2009 (UTC)

Wrote an introduction on IPv6 about this page and removed several sections that are hereby moved to this page.

Added a [[Category:IPv6]] at the bottom of the page. Probably more catagories are needed there.

> Please elaborate on how to change the introduction into a structure section

The introduction mixes up stuff that belongs in the introduction with stuff that is about the structure of IPv6 addresses (64-bit prefix and stuff). This needs to be split.

> Please indicate your view on how to introduce the 'larger address space' without becoming silly.

Claims such that IPv6 provides 17 gogozillions addresses per square furlong of the surface of the principality of San Marino are silly. They tell you absolutely nothing.

Try to keep it technical and to the point: with IPv6, the system manager has between 64 and 96 bits of address space to play with. This allows defining a convenient and efficient addressing hierarchy without being constrained by the size of addresses. (In other words, what is meaningful is the number of bits, not the number of addresses -- i.e. the logarithm of the number of addresses). --Jec (talk) 00:03, 15 November 2009 (UTC)

This is a great article! But no, I don't think those sort of comparisons are silly; they're a illustrative. Saying it's a 128-bit address space is nice and all, but - ideally - not everyone who reads this page will know what that means. I'm not saying we should replace this article with a simple english article, but let's throw a bone to the layperson. Anyway, this article is so technical and thorough, it could use at least one sentence with some spunk! Psychlohexane (talk) 19:51, 1 February 2012 (UTC)

Moved the content around: from intro to IPv6 Address Space and to the Structure section. Also moved last subsection to the Notation section. When I reread it it appeared to be just a way of circumventing a naming clash with UNC paths. A DNS domain was registered by Microsoft, but no actual queries are made, so it is just a different way of writing an IPv6 address.

I hope you like it. —— _D^an_d^or ⁱ_D (talk) 21:13, 15 November 2009 (UTC)

There is something wrong with this:

Local addresses: ::1/128 — the loopback address is a unicast localhost address (analogous to the RFC.

but I'm not sure what was intended. 206.171.6.11 (talk) 16:15, 26 November 2009 (UTC)

Top Templates

Added some templates at the top of this page. —— _D^an_d^or ⁱ_D (talk) 18:37, 14 November 2009 (UTC)

Address Types: edits reverted

The edits by User:140.124.25.86 and User:12.237.205.131 are hereby reverted, since they are wrong (anycast), have sloppy format (multicast), or incomplete (unicast). Furthermore, they distract the reader from the subject of the section. I like the way of representing an IPv6 address this way though (in a more nuts-and-bolts fashion), but this should be done in the structure section in more general terms. —— _D^an_d^or ⁱ_D (talk) 16:31, 26 December 2009 (UTC)

Ambiguity in address compression

It isn't clear in the article if a double colon can represent just one group of all zeros or if it must represent at least two. The problem is that RFC 5321 states the latter, whereas RFC 4291 states the former. Could anyone shed light on this, and edit the article accordingly? —Preceding unsigned comment added by 94.195.110.161 (talk) 07:24, 17 August 2010 (UTC)

There is no ambiguity. Both versions of the RFC are equally clear on this. But this article is wrong and poorly written. Thank you for your observation.Kbrose (talk) 17:46, 17 August 2010 (UTC)

Ambigue or not, RFC 5952 clarifies this and says that at least two groups of zeroes can be eligible for double colon representation, not one. This is changed in the article now. —— _D^an_d^or ⁱ_D (talk) 21:04, 19 February 2011 (UTC)

There is no ambiguity. RFC5952 tells how programs should write IPv6 addresses. RFC4291 tells how programs should read IPv6 addresses. More specifically the RFC 4291 tells: 'The use of "::" indicates one or more groups of 16 bits of zeros'. So, an IPv6 address using :: to substitute ONLY one group is VALID. —Preceding unsigned comment added by 89.96.141.102 (talk) 15:43, 29 March 2011 (UTC)

feature of IPv6 Protocols

we want the features IPv6 protocols —Preceding unsigned comment added by Suresh514 (talk • contribs) 17:52, 3 October 2010 (UTC)

Can you be clear? This article doesn't cover the protocol-see IPv6 for that.Jasper Deng (talk) 00:03, 13 January 2011 (UTC)

Special addresses

Although it is mentioned in the article, the address ff02::1 does not appear in special addresses. This address is very important because it represents the IPv4 broadcast (it is the multicast group all-nodes). Should not be mentioned as an speciall address ? — Preceding unsigned comment added by Mtorrecilla (talk • contribs) 14:47, 10 February 2011 (UTC)

Sources?Jasper Deng (talk) 01:28, 12 February 2011 (UTC)

Sources ???. The IPv6 address article: IPv6 does not implement broadcast addressing. Broadcast's traditional role is subsumed by multicast addressing to the all-nodes link-local multicast group ff02::1 But we can see it in RFC 4861

Reading RFC 4291 I think that we should change FROM

---

Solicited-Node multicast addresses

Main article: Solicited-node multicast address

• ff02::1:ff00:0/104 — The least significant 24 bits of the 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.

---

TO

---

Reserved multicast addresses

The multicast addresses ff00::0/12 are reserved<ref name=rfc4291> and should never be assigned to any multicast group.

• ff01::1 and ff02::1 — All Nodes Addresses. These addresses identify the group of all IPv6 nodes, within scope 1 (interface-local) or 2 (link-local).
• ff01::2, ff02::2, and ff05::2 — All Routers Addresses. They identify the group of all IPv6 routers, within scope 1 (interface-local), 2 (link-local), or 5 (site-local).
• ff02::1:ff00:0/104 — Solicited-node multicast address. The least significant 24 bits of the 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.

---

Mtorrecilla (talk) 13:24, 14 February 2011 (UTC)

Acceptable, with the exception that "shall" should be "should" as per WP:MOS.Jasper Deng (talk) 03:43, 15 February 2011 (UTC)

The literal phrase in RFC 4291 is: The above multicast addresses are reserved and shall never be assigned to any multicast group. Mtorrecilla (talk) 09:42, 15 February 2011 (UTC)

Edited the text somewhat. I would like to propose the word "will", since that is what the authors of the RFC would like to convey with the word "shall" in a way that other RFC writers and implementors will understand. "Will" is the lay-man's way of saying this. —— _D^an_d^or ⁱ_D (talk) 12:00, 15 February 2011 (UTC)

We should indicate what is meant by "assignment to a multicast group"; either here or on the multicast wiki. Are they not a group themselves? —— _D^an_d^or ⁱ_D (talk) 12:06, 15 February 2011 (UTC)

I'm not native english, so i'm not able to see the diference. Perhaps, the correct word would be "should", because you shouldn't use these addresses (or you must not use them). Please, if you want, change the article and use the word that you think is better. About "assignment to a multicast group"..... I think that multicast wiki is better. Mtorrecilla (talk) 15:38, 15 February 2011 (UTC)

I agree, because that guideline is written in legal language which isn't appropriate for Wikipedia. It's technically possible but not actually permissible to use those addresses.Jasper Deng (talk) 18:04, 15 February 2011 (UTC)

Special address section, unique local addresses external reference

The reference to RFC1918 is correct in the ref name= part of <ref name=1918>RFC 1978 ... but incorrect in the text for the reference. Links to RFCs are autocreated from the TEXT not the tag, and this makes the external link at the bottom of the page direct users to RFC 1978, PPP Predictor Compression Protocol, NOT RFC 1918. Correct line should be <ref name=1918>RFC 1918, ...</ref> NOT <ref name=1918>RFC 1978, ...</ref> . My edit from 2/16 at 20:38 was correct, and should not have been reverted. 71.195.229.210 (talk) 21:00, 16 February 2011 (UTC)

United States Department of Defense allocation

The ARIN allocations to US DoD are controversial. But I do not think it factually accurate to say they got a /13, when they got 14x /22 (USDDD-001 to USDDD-014), evenly spaced out over a /13.

I am unsure why SixXS lists it as a /13, as they have never seen it announced, and it is not coming from ARIN data. --Cybjit (talk) 21:06, 16 February 2011 (UTC)

We can say 14 /22s.Jasper Deng (talk) 00:51, 17 February 2011 (UTC)

Yes, changed it now. --Cybjit (talk) 20:07, 17 February 2011 (UTC)

Scientific notation is an approximation while powers of two are exact

I'd like to remind editors of this article that when representing numbers in scientific notation or otherwise in the base 10 systems, remember to say "about" or "approximate," because most of those numbers are only approximations of the real base 2 numbers. For example, 2³² is only approximated by 4.3 x 10⁹.Jasper Deng (talk) 00:51, 18 February 2011 (UTC)

Versions

I think the editor who reverted my edit misunderstands the concept of IP versions. IPv4 is the fourth version and IPv6 the sixth, regardless of whether versions 1-3 or 5 were deployed or not. I undid the edit back. Please don't revert again unless you can prove me wrong here.Jasper Deng (talk) 02:08, 20 February 2011 (UTC)

Your edit is unreferenced and (imo) dubious. It doesn't matter what you or I say about this, and in the absence of a reliable source, I'm going to edit it to not specify that either way.Rememberway (talk) 02:38, 20 February 2011 (UTC)

The source is the IPv6 article.Jasper Deng (talk) 03:09, 20 February 2011 (UTC)

OK, first, wikipedia articles aren't sources. Second, the only thing I could find in the article was it described as version 6 of the internet protocol. That's actually different from it being the sixth version of the internet protocol. 'version 6' is a name, whereas sixth version means that there's actually been 5 previous versions. If that sounds dubious, consider that you can often have version 4.3 of a release of software or protocols, but you can never have the 4.3th version of software. There is actually a difference.Rememberway (talk) 04:00, 20 February 2011 (UTC)

Wikipedia articles are OK for sources for other Wikipedia articles, as I've seen elsewhere. And anyhow, let's just say version 6. Is this consensus?Jasper Deng (talk) 04:03, 20 February 2011 (UTC)

"Wikipedia articles are OK for sources for other Wikipedia articles, as I've seen elsewhere." Nah. Sorry. Which policy are you claiming says this?Rememberway (talk) 04:15, 20 February 2011 (UTC)

It's not a policy, but it's just copy and pasting, with the reference, so the reference carries over. I should have said it differently.Jasper Deng (talk) 04:17, 20 February 2011 (UTC)

If we stick to version 6 of the Internet Protocol we are neutral and avoid using the version number as an ordinal number. According to Internet Protocol#Version history, IPv6 can be regarded (if you stretch it) as the sixth version of IP (versions 0-3 for testing, 4 for IPv4, and 6 for IPv6, which makes 6 versions). But the version number is in NO way related to its ordinality; if Internet Stream Protocol did not exist, IPv6 would surely be named IPv5 (and still be the sixth version of IP). If version number 6 were given to another protocol before IPv6 was launched, it could be IPv7, or IPv41 for that matter. It is version 6 just because '6' was a free number. — Preceding unsigned comment added by Dandorid (talk • contribs) 12:43, 24 February 2011 (UTC)

In that sense it's the 7th IP; IPv5 did exist, it's just not been widely released; and it was allocated an IP version number.Rememberway (talk) 16:37, 24 February 2011 (UTC)

IPv6 prefixes

I think it would be a good idea to visualize assigned prefixes and explicitly state their ranges both in hex ( http://www.sabi.co.uk/Notes/swIPv6Prefixes.html ) and in binary (like this http://ip-doc.com/rfc/rfc2373 but with the correct information, of course). Any thoughts? PAStheLoD (talk) 17:13, 6 May 2011 (UTC)

Correct statement?

Under http://en.wikipedia.org/wiki/IPv6_address#Networks, a statement is made, "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". Is this correct? When I read it, I thought that "... an interface with address 2001:db8:a::123 connected to subnet 2001:db8:a::/48 is written as 2001:db8:a::123/64". Wouldn't the subnet be a 48-bit prefix, not a 64-bit prefix? I didn't know enough to be 100% positive, so I didn't change it. — Bryan Burgers (talk) 14:15, 13 June 2011 (UTC)

Either is correct in terms of syntax. Whether you have a /48 or /64 depends on what your ISP gives you though, you can't change from one to the other just because there's zeroes in the address. -Rememberway (talk) 15:41, 13 June 2011 (UTC)

As Rememberway said, it is correct. A ipv6 address 2001:db8:a::123/64 belongs to the IPv6 network 2001:0db8:000a:0000::/64. Is it more clear in this way ?

If you write the ipv6 2001:db8:a::123/48, its IPv6 network is 2001:0db8:000a::/48, that it is different Mtorrecilla (talk) 16:29, 14 June 2011 (UTC)

a6 records

Currently A6 record redirects to IPv6#IPv6_in_the_Domain_Name_System which directs the user to IPv6_address#IPv6_addresses_in_the_Domain_Name_System with a "main article link" but there is no mention of them in either of those sections.

While A6 records are were downgraded to experimental I think they should still be mentioned and explained. The question is where (they are quite complex), should I create an A6 record article independently? should I split IPv6 addresses in the Domain Name System from this article (reducing it to a summary here?) and explain A6 records in that article? should I just explain them in this article? Plugwash (talk) 12:30, 28 July 2011 (UTC)

The whole section about DNS should be moved to the DNS wiki in my opinion. You cannot properly explain how to configure them (AAAA or A6 records) in this wiki without making it a long section. You could also put in a section about typesetting an IPv6 address using LaTex; I mean: it is off-topic anyway. Put in a see-also wikilink and you're done. One thing you should NOT do is discussing a deprecated DNS feature in this article. —— _D^an_d^or ⁱ_D (talk) 17:35, 29 July 2011 (UTC)

The DNS article is already huge and doesn't really mention individual record types. There is a List of DNS record types article but a list article is IMO not really the place for the prose needed to explain the A6 system. I would therefore propose that creating a new IPv6 addresses in the Domain Name System article to explain the relationship between IPv6 and DNS and the abortive idea that was A6 records is the best option unless you have a better idea. Plugwash (talk) 15:58, 1 August 2011 (UTC)

I think it might be a good idea to move the section to a new article. It seems the easiest thing to do. If you are not comfortable in discussing this on the DNS article, you could give it its own page. On the other hand, I believe that A6 records should only be mentioned as "a bad idea that some thought would solve things", without going into much detail and just referencing RFC 2874 (for the idea) and RFC 3363 (for showing it was a bad one)... That would just leave an article with the discussion of AAAA records and PTR records for IPv6, which might be just to small a topic to put into an article of itself. Anyway, I am unhappy the way it is described in the IPv6 address article, not so much the text itself, but more that an attempt is made at all to describe it here. You might blame the writers of the DNS article not to leave room for this, but that would no do them credit where credit is due. If there is no article describing the technicalities about using all kinds of DNS records, maybe there should be one; which could include the AAAA records and mention the existence of A6 records. —— _D^an_d^or ⁱ_D (talk) 19:40, 2 August 2011 (UTC)

Unicast local address subnets

The section about unique local addresses contained the following sentence: “RFC 4193 currently only define the fd00::/8 prefix for locally assigned address.” Then someone changed that to fc00::/8, which is wrong, so I changed it back. User:Teapeat reverted my change and eventually removed the whole sentence after we discussed about it on their talk page. Their opinion is that it is not obvious from the RFC that fc00::/8 is not defined and fd00::/8 should be used, so they want me to reference additional sources. My opinion is that it is obvious from the RFC and that it is the best source to reference. It seems now that someone has added and rephrased the sentence, without citing any additional references. Does anyone have a third opinion on this? --Candid Dauth (talk) 21:01, 5 February 2013 (UTC)

The rfc clearly splits the space in half, makes rules for users to allocate themselves addresses from one half and reserves the other. It doesn't explicitly use CIDR notation to reffer to the halves but IMO converting from wordy descriptions to CIDR notation is just a form of rephrasing, not "original research". Plugwash (talk) 22:16, 5 February 2013 (UTC)

Modified EUI-64

For its example, the text uses a different address from the accompanying diagram, which seems unnecessarily complicated. I propose to change the text to match the diagram, unless anyone objects. (00:1D:BA in the text is Sony; 00:0C:29 in the diagram is Vmware.) Isidore (talk) 09:09, 24 June 2013 (UTC)

Done. Isidore (talk) 09:01, 25 June 2013 (UTC)

It would help if there was a complete example of an IPv6 address somewhere on the page

Missing example. The insert at the to right ends in :: or 000's and is not clearly part of the address. — Preceding unsigned comment added by 99.244.115.138 (talk) 22:56, 18 October 2015 (UTC)

Typo in 2001:db8::1/32 (section Literal IPv6 addresses in UNC path names)?

I think there is a typo in the example with the zone index as zone indices are separated by a percent sign and the slash is used for address block sizes. So I think 2001:db8::1/32 should be replaced with 2001:db8::1%32

The '/' was not correct indeed. Fixed it (and replaced the example global scope addresses by more appropriate link-local addresses in the process). Thanks. RogierA7 (talk) 14:09, 9 November 2017 (UTC)

Networks Heading

Under group 28/line #2, it reads: “An IPv6 network uses an address block that is a contiguous group of IPv6 addresses...”

Shouldn’t it read: An IPv6 network uses an address block that is a contiguous group of bits or (IPV6 bits)...?

Or at least say... “An IPv6 network (is comprised of) an address block that is a contiguous group of IPv6 addresses”

All I’m saying is it doesn’t seem right in what it’s trying to say.

Best Regards, Dave GTO3DEUCES (talk) 02:35, 7 June 2019 (UTC)

An address block of e.g. 2001:db8::/32 is a contiguous group of IPv6 addresses imho. --Zac67 (talk) 06:18, 7 June 2019 (UTC)

I believe GTO3DEUCES is trying to say that, while the statement is technically correct, it is not comprehensive/complete. For example, while the address block 2001:db8::/32 is contiguous and also a complete set of addresses for use in a given network, the set of addresses { 2001:db8::1, 2001:db8::2, 2001:db8::3, 2001:db8::4, 2001:db8::5 } is contiguous but does not constitute an entire network (since the smallest block containing these addresses is 2001:db8::/125, but the given set of addresses does not exhaust this block). Despite this, the rest of the paragraph in question seems to make this point (emphasis mine): "... 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, ..."; so I don't think any change is necessary. — JivanP (talk) 17:08, 10 June 2019 (UTC)

"For example, the network written as 2001:db8:1234::/48 starts at address 2001:db8:1234:0000:0000:0000:0000:0000 and ends at 2001:db8:1234:ffff:ffff:ffff:ffff:ffff." Is this correct? 5 groups of 16 bits is 80 bits, not 48. Doesn't this "describe the network written as 2001:db8:1234::/80" ? -- Jds13 (talk) 15:49, 22 August 2023 (UTC)

I completely fail to see five 16-bit groups – there are three (separated by ':') and 3*16=48. --Zac67 (talk) 16:58, 22 August 2023 (UTC)

Link-local address range

As I understand it, the first 10 bits of a link-local IPv6 address must be 1111111010, and the next 54 bits must be 0 (this is specified in RFC 4291 section 2.5.6). Shouldn't the "Last address" for link-local addresses in the "Special addresses" table be fe80::ffff:ffff:ffff:ffff instead of febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff? Rich (talk) 12:53, 24 February 2021 (UTC)

Yes, indeed. The subnet ID field needs to be all-zero. --Zac67 (talk) 13:19, 24 February 2021 (UTC)

I've updated it. Rich (talk) 12:28, 28 February 2021 (UTC)

deprecated addresses

In order to find fec0 in the article, you have to already know that it's deprecated. — Preceding unsigned comment added by 121.200.27.15 (talk) 04:43, 25 November 2021 (UTC)

Is 2002::/16 really deprecated?

The section on reserved addresses says:

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.

While citing RFC 7526. But the RFC clearly says in section 4:

The basic unicast 6to4 mechanism defined in [RFC3056] and the associated 6to4 IPv6 prefix 2002::/16 are not deprecated. The default address selection rules specified in [RFC6724] are not modified.

AFAIU this RFC only deprecates the anycast version of 6to4 and the associated IPv4 prefix:

This document formally deprecates the anycast 6to4 transition mechanism defined in [RFC3068] and the associated anycast IPv4 address 192.88.99.1. It is no longer considered to be a useful service of last resort.

The prefix 192.88.99.0/24 MUST NOT be reassigned for other use except by a future IETF Standards Action. StayFoolish2021 (talk) 07:46, 20 April 2023 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for speedy deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for speedy deletion:

• Ipv6 address leading zeros.svg

You can see the reason for deletion at the file description page linked above. —Community Tech bot (talk) 09:55, 21 April 2023 (UTC)

SLAAC Interface identifier composition from MAC address is not accurate

The example about converting 48-bit MAC address into 64-bit interface identifier should be clearer. It appropriately describes addition of FF-FE in the middle, but is missing that the universal/local bit (next to lowest in first byte) should be complemented in the (common) case of Ethernet interface. There is a footnote comment stating this, but in my opinion it could be said more clearly (in a single short sentence) in the actual paragraph. RFC 2464 describes this quite clearly and could be referenced here. Pasisar (talk) 08:45, 4 March 2024 (UTC)