Talk:IPv6/Archives/2006

Can anyone elaborate on multicast?
I'd like to see a little elaboration on how multicast works under IPv6, if anybody knows... SimonFunk 02:30, 9 January 2006 (UTC)


 * The page about multicast needs a complete rewrite in any case. No, I'm not volunteering.--Jec 18:01, 1 February 2006 (UTC)


 * IPv6 multicast works in exactly the same way that IPv4 multicast works. There are different sizes of padding and address fields in packet headers, but it's roughly the same. -- Anonymous Coward 01:38, 3 October 2006 (UTC)

Simplified and reworked
I've simplified this page, added a section about the new features, and reworked a number of sections. I believe that the new version is comprehensible by anyone with a working understanding of the IP(v4) suite, so I've removed the confusing tag.

I'd like to go further -- I think that this page tries to do too much, and I think about one third of it could be removed. For example, the section about special addresses could loose about half its weight. I'd also like to remove 90% of the references.

I'll wait for opinions for a week or so, and then go ahead and cut the fat --Jec 20:35, 26 January 2006 (UTC)

I haven't had any feedback on that -- am I or amn't I going to get flamed to death if I remove the (IMHO completely useless) list of national task forces, closed working groups etc. that litters this page? --Jec 18:30, 1 February 2006 (UTC)

Removed a lot of links, basically those that didn't make sense to me. If there's any you think should be added back, go ahead, but please explain why you think they are interesting — if I don't get it, I don't expect the casual reader to get it either.--Jec 20:23, 8 February 2006 (UTC)

Math and more math
I added in the "crazy" number names in since the average user might actually look that up and remember it. Instead of trying to figure out what the hell 3.4 x 10 to the 100th power is. Also thought about change the every living person part in it but didn't. Since, well it isn't just for a person...we also use it for printers, servers and so on. Wasn't sure on wording.


 * I have removed the pedantic number names. 10^28 makes sense, octillion doesn't.--Jec 20:23, 8 February 2006 (UTC)

Inevitable?
Ninjagecko: {which might never happen} -> {which will inevitably happen}

I've reverted this change. This is not about widespread IPv6 adoption, which might or might not be inevitable, this is about IPv4 being completely supplanted by IPv6 and no longer being used, which is definitely not.--Jec 17:58, 1 February 2006 (UTC)

omitted zeros and acronyms
Say "If a four-digit group is 0000, the zeros may be omitted" BEFORE not after having casually used it leaving readers scratching their heads.

AYIYA: acronyms that an offline reader has no way of figuring out. Don't depend that we can click, or even mouseover, e.g., on our PDA offline.


 * Please clarify. The phrase “generic encapsulation schemes, such as GRE or AYIYA” makes it perfectly clear that AYIYA is a generic encapsulation scheme.--Jec 20:23, 8 February 2006 (UTC)

Following this rule, any group of consecutive 0000 groups may be reduced to two colons, as long as there is only one double colon used in an address. Leading zeros in a group can also be omitted. Thus, the addresses below are all valid and equivalent:

2001:0db8:0000:0000:0000:0000:1428:57ab 2001:0db8:0000:0000:0000::1428:57ab 2001:0db8:0:0:0:0:1428:57ab 2001:0db8:0::0::1428:57ab <-- isn't there 2 doubles in this address? 2001:0db8::1428:57ab 2001:db8::1428:57ab

I'm no expert - I have just read the page and im confused by this -- keep up the good work


 * Fixed, thanks for pointing it out -- RoySmith (talk) 12:52, 8 September 2006 (UTC)

Software (Operating Systems + Applications)
Could someone clarify what this section is for? In a search for OSes that support IPv6, I ended up on the Wikipedia. Maybe there's a seperate page for this? --Allen Huffman

Please clarify.--Jec 16:43, 28 May 2006 (UTC)

New hardware
I may have missed it but is there a portion of the article (or another article) that describes the impact of switching from IPv4 to IPv6? All of today's hardware (ethernet cards, wireless routers, etc) will need to be replaced, as well as a lot of software. With the high degree of h/w and s/w turnover in the computer biz, I guess this isn't going to be a huge issue, but I still think its worth mentioning.

Wikipedia brown 16:44, 14 May 2006 (UTC)

I've tried to make that clear in the article (`IPv6 is a conservative extension of IPv4'), but obviously I've failed: IPv6 works over the link layers that you know and love, including Ethernet, PPP, 802.11, etc. (but not SLIP). I'll think how to make this clearer.--Jec 16:42, 28 May 2006 (UTC)

- added:

Actually ethernet cards will be fine. They (usually) are working on a lower layer. Remember how IPX/SPX was being used on the same network cards? Same thing here. What won't work on ipv6 if they are not ipv6 compatible:

a) NAT Home routers, such as dsl modems and wireless routers. Actually, they can often be used as a switch, which could work too. But the firewall won't work, and you won't have the privacy of a NAT. Furthermore, you just disabled NAT, so ipv4 connectivity has become very limited

b) Docsis cable modems. Get a Docsis 3.0 compatible one from next year or so.

c) Your PC will typically be fine. Be aware though of onboard firewalls and accelerating network cards.

d) Ethernet cameras

e) Ethernet oscilloscopes

f) Ethernet printers

g) Ethernet Voip phones

h) Ethernet payment systems

i) ...

Some of these might be able to get a firmware upgrade, if it's still properly supported then.

Number of addresses per
Any reason why the facts listed in a previous version of the article were removed?

"IPv6 is intended to address the concern of IPv4 address exhaustion. There are too few IP addresses available for the future demand of device connectivity (especially cell phones and mobile devices). IPv4 supports 4.2 billion (2564 ≈ 4.294 &times; 109) addresses, which is inadequate for giving even one address to every living person, much less support the burgeoning market for connective devices. IPv6 addresses this problem by supporting 340 undecillion (655368 ≈ 3.4 &times; 1038) addresses. For scale, this would allow an average of about 430 quintillion (4.3 &times; 1020) unique addresses per square inch, or 670 quadrillion (6.7 &times; 1017) per square millimeter, of the Earth's surface. In other terms, assuming a population of about 6.5 billion humans, there are enough IPv6 addresses such that every atom of every person on Earth could be assigned 7 unique addresses with enough to spare (assuming 7 &times; 1027 atoms per human)."

I would think this information would be useful or interesting to some people.... &mdash;Gordon P. Hemsley&rarr; &#x2709; 03:43, 6 June 2006 (UTC)


 * I agree that it helps put a scope on the pure number of available addresses available with IPv6. People know atoms are tiny, and people know there are lots of them in a human, so it helps perspective as well as provide an interesting fact. The surface area example might need to be re-worded to make it clearer, but I'd suggest putting the examples back into the article, assuming nobody has any complaints. --Nick, 65.100.221.52 08:44, 31 July 2006 (UTC)

Perhaps the article could explain more and perhaps justify why 128 and not a smaller number of bits are used. Half the number of bits would provide 4 billion times as many addresses as IPv4, which already seems like a significant overkill. Bandwidth wastage aside, there are other concerns that are possibly slowing acceptance as well, e.g. smaller microcontroller devices may already be pushing their resources to handle IPv4 addresses and would require upgrading to handle IPv6, which may be impractical and expensive. The article does list some reasons such as 128 bits is good for 64 bit architectures (and 64 bit addresses wouldn't be?) and the allocation of large blocks, but I'm not sure if that is a good reason since that's half the reason why we got into a mess with IPv4 in the first place. 85.176.114.183 16:45, 16 June 2006 (UTC)

Number of addresses misleading

 * IPv6 supports 3.4×10^38 addresses, or 5×10^28(50 octillion) for each of the roughly 6.5 billion people alive today.

Technically accurate, but misleading. The actual number of addresses available for devices will be considerably less than this. In a typical situation my ISP might assign me a 64 bit block of addresses, of which precisely two will be used by me. (Even if in the future we have fridges and washing machines connected to the internet, there still no possible way I could use up all 2^64 addresses). Then there are loads of addresses wasted in other ways (eg. the 6to4 prefix, ::ffff:, inefficient assignment to ISPs, etc.) I think the article should reflect this. Richard W.M. Jones 09:20, 16 July 2006 (UTC)


 * I think you're misunderstanding. It's not talking about the actual distribution of addresses, but just pure numbers. Total number of possible addresses divided by number of humans equals X addresses per human. --Nick, 65.100.221.52 08:38, 31 July 2006 (UTC)

ICANN Announcement
How about adding something to the page from ICANN's announcement at http://www.icann.org/announcements/announcement-14jul06.htm? —Preceding unsigned comment added by Alien- (talk • contribs) 05:05, 22 July 2006

addresses per gram of the Earth
In the introduction of this article, we had said that "IPv6 supports 3.4×1038 addresses, or 5×1028(50 octillion) for each of the roughly 6.5 billion people alive today, or about 800 addresses for each gram of matter in the Earth." which User:Roadrunner7 changed to say "almost 57 billion addresses" per gram, and User:Richard W.M. Jones reverted Roadrunner7's edit, on the ground that the chage was uncited. We don't currently have a citation for either number, but it's fairly easy to calculate the number, which comes out as Roadrunner's 57 billion: There are (less reserved parts of the number space) $$2^{128}$$ IPv6 addresses, and per Earth the mass of the earth is $$5.9742*10^{24}$$kg. So, the number of addresses per gram of the Earth is $$\frac{2^{128}}{5.9742*10^{27}} = 5.696*10^{10}$$ addresses per gram, which it is quite reasonable to call "almost 57 billion". So, do we find a citation for this number, or do we want to just remove it altogether (or possibly provide a cite for the Earth's mass and show the calculation)? -- AJR | Talk 16:43, 19 September 2006 (UTC) 5*10^28/(5.9742 * 10^27)
 * My math agrees with Roadrunner7's and yours. If instead you take the 5×1028 figure (upper bound on the number of addresses per person on Earth) and divide that by the mass of the Earth in grams, you get about 8, which is not still 800.


 * Personally I think such statements are unencyclopedic and add no value to the article. The number is huge by any practical standard, and no end of silly calculations could be invented to show it. If necessary we could link to an Orders of magnitude (numbers) to give some perspective. Wmahan. 17:49, 19 September 2006 (UTC)


 * I agree that these calculations add no value to the article. It should be enough to state the theoretical maximum number of addresses is 3.4×1038, and perhaps mention that in reality the address allocation schemes will limit the number of useful addresses. If somebody wants to calculate how many addresses per [insert an irrelevant unit here] IPv6 theoretically provides, they may do it themselves. Including these calculations here only makes the article seem amateurish.--Teemuk 07:59, 28 September 2006 (UTC)


 * OK, glad someone actually did the maths. I was worried because Roadrunner7's account had made just this single change which seemed wrong, but is seemingly correct.  Richard W.M. Jones 20:49, 19 September 2006 (UTC)


 * I'm glad someone backed me up on this. I did make the Earth word linked also in my change, so that anyone could look up the facts about the mass of the earth and see for themselves that my caluculations are correct (isn't that cited enough?). Mr. Jones: Why did it seem wrong, what I did? When someone makes a change to some incorrect numbers in an article, the least you can do before changing it back, is to check the numbers yourself. If you don't know, then don't "fix". I thought the whole point of Wikipedia is that anyone can correct mistakes they find, or add facts. Just because it was my first contribution, it doesn't mean I'm wrong. Roadrunner7 09:35, 20 September 2006 (CET)


 * Unfortunately I've been spending a large amount of time recently reverting vandals who create one-shot accounts and then vandalise articles. In any case, welcome to Wikipedia, and please use the edit summary to summarise changes.  Richard W.M. Jones 08:00, 20 September 2006 (UTC)

"IPv6 Packet" chart problem
Someone who can edit .PNG files please fix a small problem with the chart laying out the packet header bits? The bit numbers down the side read 0, 64, 128, 192, 256, ...but there is no 320 at the bottom. IPv6 headers are in fact 320 bits (40 bytes). --Shyland 17:08, 30 September 2006 (UTC)

More than one :: ambiguous?
"Having more than one double-colon abbreviation in an address is invalid, as it would make the notation ambiguous" does not seem to me to be a sound statement. It would be possible to adopt the convention "if there is more than one double-colon in an address, then each of them represents exactly one 0000 group". I understand if that is not in fact the accepted convention, but I think the notation would not necessarily be ambiguous. But I'm not an expert here, just pointing out. David Brooks 02:16, 14 December 2006 (UTC)


 * No, that is not the case, if you have: "2001:db8::5555::1234" is that
 * "2001:db8:0000:0000:5555:0000:0000:1234" or
 * "2001:db8:0000:0000:0000:5555:0000:1234" or
 * "2001:db8:0000:5555:0000:5555:0000:1234"?
 * As such one can't compress an IPv6 address to have two double-colon's in it, which
 * would make it ambiquous.
 * User:JeroenMassar 20:10, 14 December 2006 (UTC)


 * I was saying it isn't necessarily ambiguous, which is what's implied in the text. Instead, it is ambiguous by definition. You could resolve the ambiguity as I suggested, but the standard just declares it ill-formed instead, and that's clearly fine. The resolution I gave as a possible alternative would declare your example ill-formed (too short). And I think you mistyped the expansion in your 3rd example (5555 -> 0000). David Brooks 22:32, 14 December 2006 (UTC)