Talk:IPv6 address

This is the talk page for discussing improvements to the IPv6 address article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing: Networking C‑class Mid‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
C	This article has been rated as C-class on Wikipedia's content assessment scale.
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as High-importance).

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Top Templates

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

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)[reply]

Literal IPv6 addresses in UNC path names

It looks, like these does not work in windows xp (tried, but these all resolves to 65.55.39.something ipv4 address). In google found only examples for windows vista. -Yyy (talk) 06:48, 30 January 2010 (UTC)[reply]

Can you describe what exactly you have tried? —— _D^an_d^orⁱ_D (talk) 21:03, 2 February 2010 (UTC)[reply]

All I can say about this "ipv6-literal.net" BS is it's yet another stupid Micro$oft hack that needs to be killed immediately, just like the "*.phx.gbl" BS they pulled several years ago. They may have registered the domain name, but the servers never respond to DNS queries (which will be done by NON-WINDOWS OS machines). It needs to die quickly. 71.106.210.230 (talk) 02:33, 15 August 2010 (UTC)[reply]

Perhaps you just need to learn the facts about this. There is no network DNS resolution involved in this concept. If you want to use this outside of Windows, then you need to configure your own DNS server properly. Kbrose (talk) 18:51, 17 August 2010 (UTC)[reply]

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)[reply]

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)[reply]

feature of IPv6 Protocols

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

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

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)[reply]

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

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

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 and shall never be assigned to any multicast group.

ff02::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 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)[reply]