Talk:IPv6/Archives/2012

docsis and IP6

This article implies that all DOCSIS 3 modems are also IPv6 compliant. But, that's not true

Do you have a source?Jasper Deng (talk) 17:32, 7 August 2011 (UTC)

It would be nice to hear from an expert, but:

http://www.cablelabs.com/specifications/CM-SP-MULPIv3.0-I16-110623.pdf

appears to imply that IPv6 support is a basic part of the DOCSIS 3.0 standard. OTOH, it quite explicit that the ISP is *not* required enable it (see section 5.2.5.1, for example). Rwessel (talk) 18:33, 7 August 2011 (UTC)

This mildly annoyed me before as well, but it seems to be worded more neutrally now. Rwessel is quite correct, DOCSIS 3.0 does have IPv6 has part of the standard...but it's entirely dependent on the ISP supporting that! (From a somewhat-expert; I *am* the IPv6 documentation prefix, after all!) I edited the section to note most DOCSIS providers don't actually support IPv6, but I don't have a a verifiable source, so feel free to remove that... – 2001:db8:: (rfc | diff) 10:59, 6 January 2012 (UTC)

Shorter intro, please

The intro (before the TOC) is too long, I think -- it's about half a screen right now. It's four paragraphs

• short intro and explanation of what the Internet does
• IPv4 address exhaustion and why/how IPv6 solves it
• IPv6 features not in IPv4
• IPv4 address exhaustion (again); lack of IPv6 penetration because ...

I bet most of it should go in the sections below, and most likely it's all already there. How about just saying (in other words)

• what it means to be an internet protocol
• that it was designed, starting in the early 1990s, to replace IPv4 (which is what we use now)
• that one of its killer features is more addresses, the scarcity of which is a major problem today
• but that it hasn't succeeded yet

JöG (talk) 09:36, 12 November 2011 (UTC)

Sounds like a great outline. The current intro strikes me as too technical for a general audience, particularly the way it depends on already knowing IPv4, and the way the background information isn't written from the perspective of the topic (e.g. "Each host or computer on the Internet requires an IP address in order to communicate."). However I think I'd keep a summary of the other new features in IPv6 (apart from having more addresses). --Pnm (talk) 18:34, 12 November 2011 (UTC)

Use this if you want to. I kinda consider it WIP, and will probably come back to it if I have time.

Internet Protocol version 6 (IPv6) is the next version of IP addresses that will increase the available address space, and will also enable numerous security, privacy, and mobility features lacking in the current Internet Protocol version 4 (IPv4).

Internet Protocols such as IPv6 are rules that allow different computers and devices to communicate across computer networks, such as the Internet. Each computer or device needs an "IP address" in order to send or recieve "packets" of information to another computer, and the world is beginning to reach the end of available IP addresses in IPv4. IPv6 was concieved and began development in the early 1990's to replace IPv4 because of the foreseen end of available address space.

The reason IPv6 has not yet been made the defacto standard of the Internet is due to a combination of expense upgrading end-user equipment, and because until recently, most computers did not have software for IPv6 installed.

-Nameless (talk) 6:27, 30 November 2011 (UTC)

That one is a little too flattering of IPv6, per WP:NPOV, even though I whole-heartedly agree with what it says.Jasper Deng (talk) 06:29, 30 December 2011 (UTC)

I'd really just like to see a shorter lede. I copyedited a bit, but then read this, re-read the lede, and realized that it's pretty useless if you don't have much knowledge of the subject. I guess the lede itself should try to specify that IPv6 is *mainly* about (as far as the real world goes) allocating more addresses... – 2001:db8:: (rfc | diff) 11:02, 6 January 2012 (UTC)

I edited the lede and put all but the first paragraph into an Introduction section.--agr (talk) 13:20, 6 January 2012 (UTC)

And now extend the lead as per WP:LEAD. ;) Nageh (talk) 13:45, 6 January 2012 (UTC)

Controversy section

The controversy section is completely incoherent and unintelligible. — Preceding unsigned comment added by 86.128.42.150 (talk) 08:47, 7 January 2012 (UTC)

Recommended address format

I added RFC 5952's Section 4 recommendations for proper address formatting, and Jasper Deng reverted the edit saying "These are not mandatory".

I think it's important to include the recommended guidelines for writing the addresses, especially since there are so many different ways to format an IPv6 address. If it's just the wording you disagree with ("rules", "MUST", etc), it would be much more productive to simply change the wording rather than revert the entire edit. Naff89 (talk) 20:52, 26 January 2012 (UTC)

I support Jasper Deng's removal on an additional ground: a canonical representation is irrelevant to this article. The protocol is going to use the expanded address, so which abbreviation was used to supply the ultimate address does not matter to the suite. A canonical representation may be important elsewhere, but I don't see it here. Why should this article devote a lot of attention to writing canonical address abbreviations? Glrx (talk) 16:50, 27 January 2012 (UTC)

That's a fair point, and on further investigation the recommendations are already well integrated into the 'IPv6 Address' page. I just know it's gonna bug the crap out of me when people start formatting their addresses stupidly ;) Naff89 (talk) 21:22, 27 January 2012 (UTC)

Table with exact number of possible addresses

I added the following table to show the difference in a more visual manner:

IP Version	Number of Possible Addresses
IPv4	232	4,294,967,296
IPv6	2128	340,282,366,920,938,463,463,374,607,431,768,211,456

Jasper Deng undid the revision stating that "2 or 3 significant figures and the orders of magnitude (here 34 versus 9) are enough". However, I think it provides a good visual representation of the difference between the numbers, and therefore should be included, especially since the exact values are not provided anywhere in the article's text. 71.199.54.157 (talk) 05:22, 17 January 2012 (UTC)

People aren't as impressed by numbers as things like the fact that this would be like 1.7 times the # of carbon atoms in a 50m cube of diamond, or that the DoD's allocation (/13)'s addresses would be more than two hundred million times the radius of the solar system if each address were turned into a penny.Jasper Deng (talk) 05:28, 17 January 2012 (UTC)

I don't think this has anything to do with impressing anybody, and everything to do with representation in a way most people can easily understand. In fact, your comparisons don't impress me at all, because they mean nothing to me. —Darxus (talk) 16:03, 4 March 2012 (UTC)

I just added a very similar table, before looking over this discussion. And yes, "2 or 3 significant figures and the orders of magnitude (here 34 versus 9) are enough" - if you just want to sufficiently accurately convey the size of the address space. But not if you want to actually represent the size in a way that most people will instantly grasp. —Darxus (talk) 16:02, 4 March 2012 (UTC)

And besides, many addresses in both spaces have no practical unicast use (the one most care about) (127.0.0.0/8, ff00::/8, etc.), so it's not most accurate.Jasper Deng (talk) 19:35, 4 March 2012 (UTC)

Very true, that subject has certainly been thoroughly glazed over in this article, and I would be in favor of clarifying it. But I don't think that's a reason to remove the long form of the size of the address spaces. 75.68.127.94 (talk) 14:39, 5 March 2012 (UTC)

While I don't think the exact (FSVO "exact") numbers add much value, I'm not really particularly opposed to them being there. *But*, let's at least format the darn things decently? If we're going to have a table, use the one above, instead of the one now in the article. Rwessel (talk) 23:18, 5 March 2012 (UTC)

I've gone ahead and removed the table. If someone really wants it back in there, let's use the rather more nicely formatted one at the top of this section. Rwessel (talk) 23:56, 7 March 2012 (UTC)

Undecillion

Removed 'Undecillion' from the introductory section: "an address space of 2128 (approximately 340 undecillion or 3.4×1038) addresses." Using "Undecillion" and other obscure number-words adds nothing to the understanding of the article: exponential notation is sufficient and appropriate. 169.234.46.39 (talk) 22:28, 7 March 2012 (UTC)

Please put a summary in the lead

Can someone please put a summary of what IPv6 is in the lead? As it currently stands, it is nearly incomprehensible for a non-techie such as myself. (I may be "a master of all known wiki-markup", but I can't make heads nor tails of the lead in this article.) A good lead here, imho, would start with a summary that could be understood by someone who knows that a "normal" IP address is in the format of xxx.xxx.xxx.xxx but knows little else. This isn't to say that more complex/complete information should be excluded, but a simple summary definitely needs to be added. --Philosopher ^{Let us reason together.} 03:41, 3 June 2012 (UTC)

I've made an effort to improve things by reorganizing the intro and adding a diagram of an IPv4 address. --agr (talk) 18:37, 5 June 2012 (UTC)

Thanks, the article is much better now. --Philosopher ^{Let us reason together.} 01:14, 13 June 2012 (UTC)

IPv6

Wikipedia now has it. -- 2001:980:1451:1:7149:688C:F192:3318 (talk)

Confirmed, as evidenced by my IPv6 address :-) — 2001:44B8:3178:E800:0:0:B000:B1E5 (talk) 11:35, 23 June 2012 (UTC)

Possible error re IPv6 address "host and subnet" terminology

Shouldn't the line "since the host identifiers (the least-significant 64 bits of an address) can be independently self-configured by a host" be worded as "since the subnet identifiers (or mask) (the least-significant 64 bits of an address) can be independently self-configured by a host"? I am an IT professional with 40 years experience, but not confident enough in this topic to unilaterally make this change. HWSager (talk) 03:52, 18 June 2012 (UTC)HWSager

I don't believe IPv6 has the concept of a subnet mask; shouldn't "subnet mask" refer to the size of the IP subnet itself anyways? I'm not sure of "subnet identifiers" as terminology; that terminology might be used for the most significant 64 bits, I think.--Jasper Deng (talk) 03:57, 18 June 2012 (UTC)

IPv6 absolutely has the concept of a subnet mask, even if it's not normally represented as ffff:ffff...etc, but rather as /48 or whatever. It's still a subnet mask, no different than, say, 255.255.255.0 == /24. Although, to answer HWSager's question further, even if it was the subnet identifier...that wouldn't equal the mask for either IPv4 or IPv6, since the identifier is generally the leading side of the address (i.e. most significant bits), not the mask...although "subnet identifier" isn't something I've seen commonly used outside of random documentation, even if it's technically accurate...actually, more accurate than the common use of "subnet" for the same! (But still not common.) – 2001:db8:: (rfc | diff) 07:39, 4 July 2012 (UTC)

No. The LS 64 bits are just the host identifier. The notion of subnet would apply to the upper 64 bits. Don't get confused by schemes that happen to encode a non-IPv6 network address in the host id. Glrx (talk) 15:54, 19 June 2012 (UTC)

Keep in mind that even though the least-significant 64 bits are "meant" to be used for the host identifier, devices are generally required to apply the concept of a subnet down all the way down to the /128. You're not going to see things smaller than /64s globally, of course, (well, or /56-/48 now, and perhaps /40-/32 going forward, but I digress), but it's quite common to have random /127s and /128s or whatever floating around an IGP, with devices routing those tiny subnets. For most common uses, of course, the LSB /64 can just be assumed to be the host identifier...but that doesn't restrict the subnettable portion for routing purposes. – 2001:db8:: (rfc | diff) 05:48, 7 July 2012 (UTC)

Example of the size of the IPv6 address space

Here is one visualization. Imagine that the entire range of IPv4 address, 2³² is represented by a typical human hair having a mean diameter of 70 μm. (There is a reference given on the human hair article which uses 70 to 80 μm as a typical experimental value.) Now, suppose we represent the size of the IPv6 address space in the same manner. Since there are 2¹²⁸ addresses, we can see quickly that our example requires a distance of 2⁹⁶ x 70 μm. This is an enormously long distance. It is so long, in fact, that we need to convert it to light years for convenience's sake.

Assume ${70\mu m}=1{\text{ hair diameter}}$

$(2^{128}\ {\text{ addresses}})\cdot {\frac {1{\text{ hair diameter}}}{2^{32}{\text{ addresses}}}}\cdot {\frac {70\ \mu {\text{ m}}}{1{\text{ hair diameter}}}}\cdot {\frac {1{\text{m}}}{10^{6}\ \mu {\text{m}}}}\cdot {\frac {1{\text{ light-year}}}{9.4607{\text{x}}10^{15}{\text{ m}}}}=$ 586,000,000 light-years

This is 10 times farther than it is to the center of the Virgo Cluster, which is nearby galaxy cluster. So if IPv4 is a hair on your head, then IPv6 is tantamount to the distance traveled by light in 586 million years. I like to saw logs! (talk) 06:29, 5 July 2012 (UTC)

More trivia:

• 7.5 x 10¹⁸ Estimated number of grains of sand on all the beaches in the world.
• 3.26 x 10²⁰ Estimated number of gallons of water in the world.
• 10²² Estimated number of stars in the universe.
• 4.339 x 10²⁶ Nanoseconds that have passed since the Big Bang.
• 3.403 x 10³⁸ IPv6 addresses.

I'd be wary of listing examples and such in the article though, because it could get "crufty" and expand rapidly as everyone tries to include an example they think describes things better. Equazcion ^(talk) 06:42, 5 Jul 2012 (UTC)

See Category:Orders of magnitude.

—Wavelength (talk) 18:05, 5 July 2012 (UTC)

I like the idea of a "simple" comparison, more-so than that numerical infobox. Unfortunately, I don't see a good example amongst the ones you've proposed...nor can I think of one myself. The difference in magnitude is just too large for most simple comparisons. Now, if someone has a good way to describe 2^96 that the average reader can understand, and makes sense in context, that could be useful. – 2001:db8:: (rfc | diff) 03:31, 7 July 2012 (UTC)

Number of possible addresses

{{IPv6 comparison}} The lead contains a comparison of possible addresses using scientific notation for the IPv6 number. There should be a more lay representation of the number for those who don't know how to visualize "3.4×10³⁸".

I've tried putting "a number with 37 zeros" in parenthesis and was reverted, then tried adding a comparison box (the one to the right) and was similarly reverted.

Since the vastly different number of possible addresses in IPv6 is the entire point of IPv6, it needs to be conveyed in a way that ensures everyone can appreciate just how different these numbers are. If neither of these methods are good, let's talk about how else we can do it. Equazcion ^(talk) 04:10, 5 Jul 2012 (UTC)

The previous consensus was that orders of magnitude and analogies were sufficient to convoy the message and that the exact # comparison was excessive on space.--Jasper Deng (talk) 04:16, 5 July 2012 (UTC)

We don't have any analogies or orders of magnitude right now, at least as far as the lead goes. I doubt any could replace a straight view of the numbers themselves though. The box above doesn't take up much space, in fact it's a fraction of the size of our smallest image, and only about 20% wider. Nevertheless if people still don't like it, let's talk about some analogies etc that will get the job done. Equazcion ^(talk) 04:25, 5 Jul 2012 (UTC)

It's definitely something that doesn't belong in the lead, given its size.--Jasper Deng (talk) 04:33, 5 July 2012 (UTC)

Then back to the OP. What does belong? We need something aside from the scientific notation. Equazcion ^(talk) 04:36, 5 Jul 2012 (UTC)

PS. Having a look at the discussion above where I see this "consensus" occurred, it was 2 against 2, and it's now 3 against 2 in favor (of the box with the long number). Plus this version of the box is smaller than that one. Equazcion ^(talk) 04:42, 5 Jul 2012 (UTC)

I've now reduced the size of the box again. It's now less wide than the first lead image, and obviously much shorter height-wise. Since size obviously is no longer an issue, are there any others, before I re-insert this? Equazcion ^(talk) 04:49, 5 Jul 2012 (UTC)

I think this belongs in the address space section, at about 80% of that size.--Jasper Deng (talk) 05:03, 5 July 2012 (UTC)

For what reason? The difference in possible addresses is the main point of IPv6. I might agree if we left this point out of the lead entirely -- but if we're going to include it in the lead in some way (there's no doubt we should), something easily readable by everyone needs to also be included there. The article is already too technical for most people to get into, and most will not be looking past the lead; the lead should therefore at least be accessible to the majority of people. I don't see what the size issue is either, since it's now smaller than other lead images. Equazcion ^(talk) 05:10, 5 Jul 2012 (UTC)

Well, an exact comparison is a detail I feel belongs after the lead, though your earlier comment about the digits may be sufficiently brief to stay in the lead. The lead is already very long, so I don't like the thought of bulking it up.--Jasper Deng (talk) 05:21, 5 July 2012 (UTC)

In this case it's not a detail. The rationale for its inclusion is that the current lead description is too technical, and this is a clarification for lay people. I've now reduced the size yet again. It's now significantly smaller, both length and width wise, than several lead images. The lead is not very long anymore, though it once was, before I massively reduced it recently. This box is downright tiny now. Equazcion ^(talk) 05:24, 5 Jul 2012 (UTC)

The only last thing I'd want would be for all the images in the lead moved out and that this diagram be the only image in the lead.--Jasper Deng (talk) 05:26, 5 July 2012 (UTC)

Done. I may at some point add example IPv4 and IPv6 address to the box, now that the "decomposition" image is gone from the lead, as I think something should prominently display an example IPv6 address. Equazcion ^(talk) 05:33, 5 Jul 2012 (UTC)

The current treatment is poor - in particular the infobox being shoved downwards like that is by another less useful box of a different width is not aesthetically pleasing nor does it help put the subject into context. The purpose of the lede is to summarise the contents of the article as a whole - presenting an exact value like that is pointless clutter. If we transposed the last couple of digits would i have any practical significance whatsoever? Of course not. The exact value in decimal notation is pretty much an irrelevance. Spelling out the full number, especially boxed off like that, for the sole purpose of stating "Gee, this is a really big number" doesn't achieve anything. The prose of the lede already refers to a greatly expanded address space, that is enough context for the lede which is built upon later. Wedging in random facts that convey little in the way of real understanding does not help to put the article into context, it is distracting clutter that serves to obscure the key points. Ultimately, if someone finds 10³⁸ meaningless I somehow doubt that a 39 digit string of numbers is going to make any more sense. Crispmuncher (talk) 05:58, 5 July 2012 (UTC)

Sure it will. Not everyone knows how to read scientific notation, so for the them, that figure means nothing. Everyone knows how to read decimal, so that number means something. This isn't a random fact, nor is it a "golly what a big number". It's an attempt at providing information to the lay person that the technical person already has. Those who understand the bits and the scientific notation already have an idea of how the two addressing schemes compare. Those who don't, don't, unless we provide numbers they are capable of comparing. As far as formatting improvements to the box, if you have suggestions, please feel free to state them. Equazcion ^(talk) 06:08, 5 Jul 2012 (UTC)

I strenuously absolutely object to the prominence of the comparison box as placed now. This is *far* from a major bit of information, and it would be better to have no images in the lead at all than this. I think the information itself fairly pointless, not to mention not particularly accurate either. And following a number with 39 significant digits with "but not really," is kinda silly. Nor do I think a 39 digit number is particularly clear to the lay user in *any* context, so it doesn't really even achieve the stated goal. If we want something like this, it should absolutely not go in the lead, rather in Addressing or Larger address space. Nor do I think we need to worry too much about visualizations, the "N addresses per human" in Larger address space seems to cover the "really a lot" concept adequately. Rwessel (talk) 08:48, 5 July 2012 (UTC)

Strenuously object all you want, just offer something better while you do it. We're not putting scientific-notation only in the lead. If that's there, then something else needs to be there in addition, that will just as plainly convey the address space differences to lay people as it does to tech people. Equazcion ^(talk) 11:41, 5 Jul 2012 (UTC)

You were quick to assert the numbers showed consensus when this discussion was only thirty two minutes old and it was 3:2 in your favour including a previous discussion. It's now 3:1 against you this time around. You have yet to make a convincing case that this is important enough that is must be mentioned to the last digit up front and right away, you are not in any position to be asserting "we are not..." at this point. Crispmuncher (talk) 12:13, 5 July 2012 (UTC).

Easy enough. The exact (or even approximate) numbers are trivia, and don't belong in the lead, period. Let's change the second paragraph to:

"Each device on the Internet, such as a computer or mobile telephone, must be assigned an IP address in order to communicate with other devices. With the ever-increasing number of new devices being connected to the Internet, there is a need for more addresses than IPv4 can accommodate. IPv6 uses 128-bit addresses instead of IPv4's 32-bit addresses, providing more than a billion-billion fold increase in the number of devices that can be connected."

Certainly I'm not in love with the current lead, but it's a hard subject to summarize. The increase in address space, which is the main justification for IPv6, is at nominally explainable to a layman, so I understand the temptation to build on that. But again, the exact numbers (2**32 and 2**128) are trivia, and sufficiently wrong to make them misleading. And it’s probably closer to correct that the motivation for increasing the address space is really the motivation to increase the number of devices which can be attached to the Internet, and once we consider that, you have to take into account mitigations (like the use of NAT in IPv4), and inefficiencies (like the considerable waste of address bits for ease of administration and routing). And when you do that, it’s hard to justify even a claim of a “billion-billion fold” (2**60) in the increase in attachable devices. A single billion-fold is probably more accurate based on current policy (although that is subject to some change). Rwessel (talk) 16:14, 5 July 2012 (UTC)

I'm done here. You guys do what you want. Equazcion ^(talk) 18:09, 5 Jul 2012 (UTC)

I'm getting into this discussion a bit late, so I'm not going to rehash the above arguments...I kinda like the box, since it provides a nice comparison that the average user can make sense of, but it looks HORRIBLE stuck up top where it is under some browsers. (Chrome and Safari stick it above the entire lead for me, Firefox puts it off to the side.) Can it be stuck above the Internet Protocol Suite infobox, off to the side, in a proper fashion? I'm not sure what tags to use to do this. :) Also, the bit about fewer addresses being available isn't needed in the lead; the numbers are close enough, and explaining the reason for that is obviously fairly technical. I'd just remove it, but this seems to be a contentious issue in general. – 2001:db8:: (rfc | diff) 01:54, 7 July 2012 (UTC)

I think that the discussion of address space exhaustion and size comparison should consider the fact that assigning /48 or /56 prefixes will result in much lower available address space extensions than the astronomical factor of 2**96 suggests. One might assume that the usage of the prefix space of IPv6 is expected to be much better than that of the entire v4 address space (of course, average usage of the entire v6 address space will be extremely small). — Preceding unsigned comment added by 2003:5A:EE0E:9F00:743D:D156:FB53:FD1B (talk) 22:30, 10 December 2012 (UTC)

Security issues

From BBS posts it seems that many admins are unhappy about the largely untested and unproven security aspects of IPv6, and are therefore disabling it. Maybe a section on this would be in order.

For one thing, I can cite the issue that some IPv6 Windows and Linux implementations assign a randomly-generated linklocal address even where the interface in question has been declared STATIC. This would seem to be an extremely bad practice. It effectively defeats the firewall, making it impossible to lock down a server against portprobes by clandestine local computers.

A related issue is that on Linux, the building of IPv6 into the kernel has made it hard to disable fully.

My guess would be that we haven't yet seen even a tenth of the security issues with IPv6. It's a desperately overcomplex and ill-conceived scheme, and should be replaced ASAP with a simplified alternative, one whose security can be properly audited.--Anteaus (talk) 21:26, 1 October 2012 (UTC)

Removal of the Technical Tag

Is it time to remove the technical tag? I feel that the summary portion and in-body hyperlinks to relevant ancillary topics should cover the "layman's" explanation. Jaychan00 (talk) 00:47, 23 August 2012 (UTC)

I made another pass at the lede. I agree it may be time to remove the technical tag, but someone else should make that call.--agr (talk) 19:21, 13 September 2012 (UTC)

I agree and am deleting it. wp:bold --Chuunen Baka (talk • contribs) 16:04, 20 December 2012 (UTC)