Talk:IPv6/Archives/2011

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

bytes instead of octets

I would opp for the use of the term bytes(by eight), because thats more know amongst the public instead of octets. —Preceding unsigned comment added by 198.184.231.254 (talk) 12:32, 16 December 2010 (UTC)

While bytes are now commonly eight bits, that's still not universal. In the past byte sizes other than eight bits used to be much more common. Octet is well defined (it is *specifically* eight bits), and is what's used in all the standards. See also the discussion at octet. Also, are you suggesting the byte is some kind of portmanteau for "by eight"? That's flatly incorrect, byte has been applied to a variety of sizes, and the first known usage (as related to the IBM 7030 Stretch, was for a chuck of storage one to six bits in length to be used in an I/O operation (originally a "bite," but it had its spelling changed to reduce confusion with "bit"). And in the early days, a byte was rather more commonly six bits than eight. Rwessel (talk) 19:28, 16 December 2010 (UTC)
I second that on technical merits. In addition, the often heard notion that WP should use terms more familiar to the public is rather absurd for an encyclopedia that is supposed to relay knowledge. An encyclopedia should be technically correct, and not reinforce popular notions that are so often technically incorrect. If someone doesn't understand the term octet they can click on a link and read to understand it. Encyclopedic content should always challenge the mind, lead to further investigation, not be dumbed-down reflection of minimal understanding. Kbrose (talk) 20:09, 16 December 2010 (UTC)
Oppose change to byte. Keep octet. Byte was any portion of a word. Glrx (talk) 21:47, 16 December 2010 (UTC)
Networking standards and professionals prefer octet. Computer professionals use byte. Since there is overlap in these professions, many of the WP networking articles use both byte and octet - see EtherType for example. No one in this current day uses byte to mean anything other than 8 bits. Unless they've been asleep for the past 30 years, on one is going to be led astray if byte is used instead of octet. Octet is definitely the more obscure term and will detour some readers (to the octet article). This is not necessarily a horrible thing. I don't have a strong opinion on this. If we want to use octet it should be used consistently in network-related articles. --Kvng (talk) 15:19, 17 December 2010 (UTC)
Very true. And I don't care either whether we settle for byte or octet. Just as RFCs these days don't bother much about the distinction anymore. Nageh (talk) 17:24, 17 December 2010 (UTC)
Selectively linking to octet is a good idea. So is saying "octets (or bytes)", and providing equivalency in KB for amounts like "65535 octets." This kind of explanation helps a general audience without reducing the correctness of the article. --Pnm (talk) 22:30, 19 December 2010 (UTC)
The "or" in "octets (or bytes)" could be misinterpreted as an exclusive-or instead of an equality. Perhaps "octets (8-bit bytes)"? —Ruud 02:11, 20 December 2010 (UTC)
I'm ambivalent about putting bytes in at all, but if we did, this would probably be the best solution at the first use of octet. Rwessel (talk) 05:24, 20 December 2010 (UTC)
Hadn't thought of that, but in some contexts I can see how that could true. In such cases it seems like "octets (bytes)" would work too. --Pnm (talk) 03:03, 20 December 2010 (UTC)
Adding adding any form of (byte) parenthetical increases confusion. If we think that is necessary, I think we should switch to using byte or 8-bit byte instead of octet. --Kvng (talk) 15:01, 20 December 2010 (UTC)
I see how it increases complexity, but not confusion. What is it octets (bytes) would make them think? --Pnm (talk) 02:23, 22 December 2010 (UTC)
It probably is most likely to be interpreted as meaning that octet is a synonym for byte. As I'm sure you appreciate, it's not as straightforward as that. I feel the complexity distracts readers and invites editors to squabble. These comments are based on my experience dealing with "8P8C (RJ-45) constructs in networking articles. --Kvng (talk) 20:42, 23 December 2010 (UTC)
I'm still for octet. The C byte is not necessarily 8-bits. See Byte#Common uses and [1]. Keeping octet maintains consistency among other WP articles. The 5-bit Baudot byte is still used in marine communications. Some hardware memories have 9-bit byte lanes (not only DDRx ECC but also internal Xilinx RAM). Glrx (talk) 20:10, 28 December 2010 (UTC)
Why don't you say "...octets (an octet is an eight-bit byte)..." at first use.
This seems to me to make it completely explicit. —Preceding unsigned comment added by 80.168.147.222 (talk) 12:34, 28 January 2011 (UTC)

IP version 5

After reverting this removal with a thoughtful rewrite and edit summary, this edit which removes it again seems rude. Frankly, it's already in the best place in the article at the moment. If the information is "misplaced," restructure the lead – or find a better place; don't delete it. --Pnm (talk) 00:51, 28 January 2011 (UTC)

The IPv5 information is just historical trivia, and certainly does not belong in the lead. Note that there's no discussion of IPv0..IPv3 either. A short statement in the history (motivations and origins) section is appropriate, and already there. Although it's a fairly awkward sentence. Rwessel (talk) 05:19, 28 January 2011 (UTC)
And I've gone ahead and replaced the old comment with the new text. It's short, to the point, and not nearly as awkward. Rwessel (talk) 05:27, 28 January 2011 (UTC)
IPv5 already redirects to Internet Stream Protocol. I'm moving the text there.Jasper Deng (talk) 06:01, 28 January 2011 (UTC)
I didn't realize it was mentioned in the body, too – that's great. It is historical trivia, and really doesn't need to be in the lead. I reverted this edit. The shorter version is preferable to me, too. It's perfectly acceptable to place a full sentence in parentheses. It's a nice way to handle a useful fact that could be omitted. --Pnm (talk) 03:03, 31 January 2011 (UTC)

SOHO routers

Mention is made in the article of support in operating systems, but many users and organizations connect via an inexpensive router. Which of these have IPv6 support? Comcast's experimental deployment includes firmware for late model Linksys routers. What resources are available for SOHO users to find IPv6 routers? -- SpareSimian (talk) 00:39, 1 February 2011 (UTC)

It'll be hard to say, as WP:NOADS prohibits a large amount of such links.Jasper Deng (talk) 06:35, 1 February 2011 (UTC)

terrible lead of article

WP:LEAD lays out guidelines on how many paragraphs, readability and what the typical layout should be, the current lead at least seems to be deliberately written to flout most of them. I tried to improve it, but kbrose simply reverted everything and then seemed to add an extra paragraph as well (it's supposed to be about 4 paragraphs long, it's more like 6 right now). Given the rate of viewing of this article I think that at least the lead needs to be greatly improved.

I'm not 100% sure because I'm pretty techy, but I think this article will read like complete doggerel to most readers from start to finish, whereas more or less anyone should at least be able to read the first paragraph.Rememberway (talk) 00:45, 2 February 2011 (UTC)

I agree-it seems written for people techies like you.Jasper Deng (talk) 01:08, 2 February 2011 (UTC)
I've tried to rewrite the lede to be a bit more accessible to non techies. Comments welcome. --agr (talk) 02:40, 2 February

2011 (UTC)

IPv4 Exhaustion

According to this exhaustion counter, IPv4 will be exhausted on March 3, 2011. —Preceding unsigned comment added by 131.91.187.36 (talk) 00:53, 24 November 2010 (UTC)

The statement "As of February 3rd, 2011, the IPv4 pool has been completely exhausted." is false. All /8 address ranges have been allocated to RIRs, yes, but not all possible IP address blocks have been consumed. Those last 5 /8 blocks count for over 16 million possible addresses EACH, so those final blocks alone will take months to allocate to final consumers. The whole section should be rewritten to reflect this - preferably by someone with a mid-line between me and the original author. 60.241.144.125 (talk) 01:32, 5 February 2011 (UTC)

What you're saying is completely correct. The remaining last 5 /8 blocks have been assigned to the RIRs, and the RIRs are going to continue in turn to hand out IPv4 addresses from within those /8's to any organisations and individuals that need IPv4 addresses until (around) June 2011. At that point the first RIR (probably APNIC) will finally be completely out of addresses. The other RIRs will run out later, and there's also going to be some ability for organizations to make do after that, they should be able to trade addresses and use NAT, but it's going to get progressively harder to work with, and IPv6 will likely be getting progressively easier to use and more and more widely activated.Rememberway (talk) 19:05, 5 February 2011 (UTC)

The size of a subnet in IPv6 is always 2^64 addresses

(claimed in the text). It is not true. IPv6 subnets can have any size. /64 subnet is mandatory for subnets with stateless IP autoconfiguration only.

193.179.199.50 (talk) 00:13, 11 January 2011 (UTC)

check RFC 3513, section 2.5.1 : "For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." Mro (talk) 20:37, 11 January 2011 (UTC)
Indeed IPv6 subnets can be just as well /32, /48, or even /96. The RFC excerpt here is irrelevant, because
it says nothing about subnets in general. Limiting subnets to /64 would be against most principles of IP networks
and would make global routing impossible. Pavlixnet (talk) 22:15, 13 February 2011 (UTC)
It does not make routing impossible, because "IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing." --Cybjit (talk) 22:29, 14 February 2011 (UTC)

Host Identity Procol

Hi, there a HIP, cool protocol similar to Mobil IP, but even more robust and more flexible, as it uses cryptography to achieve mobility. It practically makes Home Agent not needed in case of movements (but still are useful, in case two mobile nodes performed mobility action in exactly same time, and cannot send update requests to its peers).

I do not know what is a status of HIP, but I use it on some computers and is is wonderful. I for example do not need to remount my NFS mounts, or do not need to login again into ssh, jabber or irc servers when i move for example from home to school. And there is no triangular routing and no scalability problems like in MIP, so this works fullspeed (ignoring encryption and authentication, which isn't really any problem, as this is only done on end points).

This all works pretty well, and essentially acts like all-online VPN, but there is actual no tunnel, but lots of anonymous tunnels, which are handled transparently in real time. It works very good, but unfortunately HIP is not supported currently anywhere, and it is necessary to install necessary ipv6 extensions (actually ipv6/ipsec extensions), on both hosts (HIPL project or OpenHIP project, are two examples of software).

Anybody knows more about HIP, and would like to add something to article?

BTW. HIP can also work in IPv4, but even with NAT traversal extension its applications are limited. And even when using HIP over IPv4 it still uses IPv6 inside HIP package for real communication.

From other important informations, that from whole unicast IPv6 address space we have: selected pretty big chunk 2001:10::/28 (ala known as ORCHID), from which rest of prefix bits is used as an unique pseudo-random identifier which are connected with some cryptographic keys/hashes, so can be used safely to uniquely determine both sides of transmission regardless where they are located). —Preceding unsigned comment added by 149.156.82.207 (talk) 19:32, 8 February 2011 (UTC)

localhost

It is not mentioned explicitly here what localhost is in IPv6. I think it always is ::1 but I'm not sure and expected to find the right answer in this article.

It's covered in IPv6 addressing which is linked as a subarticle, and yes that's right.Rememberway (talk) 16:15, 17 February 2011 (UTC)

Edit war

I saw Arthur Rubin and an IP having an edit war. This edit war is pointless and does nothing. Please stop and discuss.Jasper Deng (talk) 05:38, 22 March 2011 (UTC)

Sites per operating system

I was wondering if it's useful to add sites per operating system like http://www.linux-ipv6.org or http://www.windows-ipv6.org to the links.

Please sign your comment, and I don't think so, as it would constitute a violation of WP:NOADS.
Agree, but please also sign your comments. ;) --SmilingBoy (talk) 07:00, 2 April 2011 (UTC)

World IPv6 Day

One editor keeps removing mention of World IPv6 Day from the intro claiming "World IP6 day is a PR stunt, and of little actual significance (see, for example, the heise Online results from last September). A small reference in readiness, deployment or milestones (as exists) is more than enough." The event has gotten lots of coverage in the trade press and many large organizations are backing it as an important step toward deployment, so I think it is of interest to general readers who will not plow the entire article, and therefore it belong in the intro. I'd be interested in other editors' opinions.--agr (talk) 16:04, 28 February 2011 (UTC)

I don't think it is a PR stunt, it seems more to be a way for the techies from these companies to convince the business parts that IPv6 is safe to deploy. Sure, press releases are being written, but this was not initiated by PR departments.
Because of the fear of broken users, none of the big content providers are enabling IPv6. Whether that fear is overblown is kind of beside the point, as they are not enabling IPv6 before this kind of test has happened.
And because content providers enabling IPv6 is a big deal for IPv6, I think a small mention in the intro is OK. --Cybjit (talk) 20:33, 28 February 2011 (UTC)
Will anyone care a year from now that "World IPv6 Day" happened? Hardly. It's merely a current event in the IPv6 deployment process. It's quite likely that many of the people going to Space Shuttle are, *at this moment*, interested in the current Discovery mission to the ISS, but it certainly isn't getting space in the lead there (nor should it). It's not like most of these sites don't have IPv6 access enabled already, it's just usually been off under something like ipv6.somedomain.com, rather than at somedomain.com - basically all anyone is doing is putting up the AAAA record for the latter. And if anyone thought there would be even a modest chance of significant problems (and previous significant deployments have shown very few), they wouldn't be participating, because the folks on their business sides wouldn't let them! So everyone is basically saying "Gee! Look at us! Look at IPv6!" IOW, it's a PR stunt. Now a bit of good PR for IPv6, telling people that it's here and works is not a bad thing, but it's not really noteworthy in the overall context of IPv6. Rwessel (talk) 23:42, 28 February 2011 (UTC)
Oppose mention in introduction. WID is not a significant part of IPv6 so it should get mention in the intro. If somebody had 10 sentences to say about IPv6, he shouldn't waste one on mentioning WID. There are more important things to say in the intro.
In the grand scheme of things, how important is the event going to be? A judgment about any significant impact should be made after the event and with some perspective. Maybe it will be important and maybe it won't. We should not speculate now.
Looking at some removed text:
Many prominent companies such as Facebook, Google, Cisco and Yahoo![1] will participate in World IPv6 Day on June 8, 2011 to test drive IPv6.
I have trouble with that statement. Many companies are using IPv6 right now; they don't need a special day to do a test drive.
From a practical standpoint, I suspect many users are still in IPv4 land. Call me backward, but my ISP doesn't even offer IPv6 yet.
Glrx (talk) 00:53, 1 March 2011 (UTC)
I was the one who initally deleted this, but I let it go upon correct sourcing. I however question its notability-I think it's just advertising and not relevant to most people who will come to read Wikipedia. Not everyone runs a datacenter.Jasper Deng (talk) 00:58, 1 March 2011 (UTC)
Many people who don't run data centers have heard that the Internet is running out of addresses and want to know what is being done about it. Our IPv6 intro describes the solution, but says nothing about what is being done to get it in use. World IPv6 Day may be a bust or it could be a tipping point. I don't know and neither does anyone else. It's of current interest and belongs in the intro where general reader might see it. We are not writing for 31st century archiologists.--agr (talk) 13:48, 1 March 2011 (UTC)
But Wikipedia is not here to advocate IPv6 deployment (important though it is that everyone gets a move on) by advertising the various efforts that people who run data centres can get involved in. "Our IPv6 intro describes the solution, but says nothing about what is being done to get it in use." That's as it should be: this article should be a broad overview of IPv6 concentrating on its technical aspects, context and genesis. Deployment and readiness should certainly be mentioned, and sure enough they have sections in this article and a whole spin-off article at IPv6 deployment. In the grand scheme of things, World IPv6 Day is just a milestone on the path to deployment of the technology rather than something of fundamental importance to the technology itself. For this reason, it merits a mention in the context of deployment rather than in the intro. Mentioning it in the intro would be unjustified recentism: we should be looking at IPv6 in the round rather than from the perspective of this transient period of deployment advocacy. 82.32.186.24 (talk) 12:25, 29 March 2011 (UTC)

Strangely enough, this domain redirects to this Wikipedia article. What's going on?Jasper Deng (talk) 05:22, 28 May 2011 (UTC)

Nothing too exciting. The site produces a 301 ("Moved Permanently") and offers "http://en.wikipedia.org/wiki/IPv6" as the new location. The Wayback Machine seems to show it as having been a modest site intended to promote IPv6, but it doesn't appear to have been updated in a few years. Presumably the owners decided to 301 the site rather than just shut it down. Rwessel (talk) 06:06, 28 May 2011 (UTC)

IPv6

is this to do with the NWO? — Preceding unsigned comment added by 82.37.4.13 (talk) 14:40, 1 June 2011 (UTC)

???Jasper Deng (talk) 14:55, 1 June 2011 (UTC)
IPv6 and the NWO are two different things. TLUICTO (talk) 15:43, 3 June 2011 (UTC)

Misleading information about the IPv6 address space

I read many places on the internet that the address space of the new IPv6 protocol is around 340 undecillion, and that is such an unbelivable number of addresses that we will never run out of addresses again. I see that this is also currently mentioned several places on the IPv6 wikiedia page But this gives a very misleading picture to the general public of how much more space we actually have for new devices with the IPv6 protocol.

First, (and this is an absolute theoretical maximum, according to the IPv6 protcol specification itself,) only the first 64 bits are used for routing purposes. This means only 2^64 different places can be on the IPv6 internet, as a theoretical maximum. The last 64 bits are reserved and can contain a MAC-address or random bits or other things, but they can not be used to route packets to different places.

If you have only have one /64 and you want to put 1000 different devices on the IPv6 internet using only this /64 subnet, you will find out that are in deep trouble. All 1000 of them must be on the same physical net, and this could give a lot of packet collisions on that net. For if you want to route between different physical subnets for your 1000 devices, you cannot use any IPv6 compliant router equipment for this, if you only have one /64 subnet.

Second, it is still misleading to say that the new net can have 2^64 different reachable devices. Most end users will be given a /48 or a /56. Many huge users will have more than a /48 also. If we say the average user have control over a /48, this only gives room for 2^48 or 281,474,976,710,656 different users, and each user typically have less than 10 devices.

Third, the IPv6 internet will become practically unroutable long before we reach even a tiny fraction of this thoretical limit of 2^48 users. Many central routing devices operate with a limit of 22-24 bits used for routing.

Below is my take of how to rewrite the section "Larger addres space", under the "Comparison with IPv4":

84.49.97.50 (talk) 02:09, 9 June 2011 (UTC)

The above seems to be a misunderstanding of the / notation. /48 or /56 refers to the length of the prefix assigned to a network, not the length of the portion of the address which the network gets to assign. A network with a /48 prefix can potentially support up to 280 addresses; a network with a /56 can support up to 272 addresses.
As for the network being unroutable, nothing says that the entire first 48 bits of the address has to be treated as a flat space. If most IPv6 addresses used on the public network are provider-assigned, transit providers will generally be routing on fewer than 48 bits. Though I certainly agree that the ability of the Internet routing system to scale significantly from its current size is somewhat in question. Suffice it to say that the growth of the IPv6 network probably won't be limited by the number of address bits, though it may well be limited by other factors that are not well understood at present.
63.68.157.171 (talk) 01:25, 29 June 2011 (UTC)Keith Moore
"All 1000 of them must be on the same physical net, and this could give a lot of packet collisions on that net."
There has be no packet collisions since switches replaced hubs more than ten years ago.
— Preceding unsigned comment added by 212.73.30.50 (talk) 12:24, 1 July 2011 (UTC)
This is not strictly true anyway; it's entirely possible to have multiple machines all in the same /64 but on separate LAN segments using proxy_NDP - it is also nonetheless possible to further subnet a /64 providing the cost of not having SLAAC is acceptable to you. -- Olipro (talk) 09:41, 6 July 2011 (UTC)

Larger address space

The most important feature of IPv6 is a much larger address space than in IPv4. The length of an IPv6 address is 128 bits, compared to 32 bits in IPv4.[2] But only the first 64 bits are used to find a route to a specific device on the internet. (The last 64 bits can contian a mac-address or just random bits.) Then of those 64 bits used for routing, only the first 48 are used to differentiate between entities. Each person/company/entity are usually given at least 16 bits to use for their own subnet if they so desire. The address space therefore supports 248 or 281,474,976,710,656 different entities. This is 65 536 times the number of single IPv4 addresses. By comparison, this amounts to approximatly 41000 times the 6.8 billion people alive in 2010.[3]

84.49.97.50 (talk) 02:07, 9 June 2011 (UTC)


Another section I would like to mention is this:

Addressing

The most important feature of IPv6 is a much larger address space than in IPv4. IPv6 addresses are 128 bits long, compared to only 32 bits previously.[4] While the IPv4 address space contains only about 4.3×109 (4.3 billion) addresses, IPv6 supports approximately 3.4×1038 (340 undecillion) unique addresses, deemed enough for the foreseeable future.[5]


The last reference here (http://pthree.org/2009/03/08/the-sheer-size-of-ipv6/) is a prime example of a guy who has misunderstood how many more devices we will have room for with IPv6, and it should not be used as a source.

This gives a wrong picture, first since only 64 bits is used for routing, so only 2^64 different adresses can be possibly routed to in a meaningful way. And since each end user typically gets a /48 it means that only 48 of the 128 bits are used to find out which user to route to. So this means maximum 2^48 or 281,474,976,710,656 different users. Even of each user can have many devices, this is very different from the 340 undecillion unique addresses pictured in the above paragraph.

84.49.97.50 (talk) 02:05, 9 June 2011 (UTC)

Replies

Mind you this is not different than the situation with IP4. Far fewer than the theoretical 2**32 are possible because of the inefficiency in address assignments. The actual number of devices on the IP4 internet is inflated by the widespread use of NAT. Rwessel (talk) 05:18, 11 June 2011 (UTC)
The limitations in both cases have more to do with policy rather than theory. Rwessel (talk) 05:19, 11 June 2011 (UTC)
No, no, no. The last 64 bits can be used to route packets. And, average users won't be allocated /48's - there's a reason why /56 is the recommended size. The average user will not get such large allocations. It seems you are thinking that each device needs its own subnet - that's not true.Jasper Deng (talk) 03:50, 9 June 2011 (UTC)
If you look at this PDF: http://www.eu.ipv6tf.org/PublicDocuments/guidelines_for_isp_on_ipv6_assignment_to_customers_v1_2.pdf you will see that they recommend a /48 to the majority of the normal subscribers. It also says that a /64 is only when the subscriber is sure he/she is only going to have one device on the net, and that is why they reccomend a /48 for normal subscribers, and a /47 for huge subscribers. It may be technically possible that the last 64 bits can be used to route packets, but that is not what is done by those who implement the ipv6 standard. I think I read in an RFC also that it was not recommended to do that, but now I can't remember wich one it was. 84.49.97.50 (talk) 16:18, 9 June 2011 (UTC)
This is based on an outdated RFC. The last 64 bits are used for routing elsewhere.Jasper Deng (talk) 16:36, 9 June 2011 (UTC)
I disagree. A plain reading of the IPv6 address#Unicast address format is a 64-bit network prefix (which is routed) and a 64-bit interface address (which is not routed). If an interface address is built from the MAC (not good for privacy), then 48 bits of address space are burned (the remaining 16 can be used for housekeeping). The above criticism is that there are severe constraints on the 128-bit address space. If the addressing were as dense as the numerologists imply, then we'd be putting 264 devices on a single IPv6 subnet. Glrx (talk) 16:59, 9 June 2011 (UTC)
Of course though, it is not a limit on the # of devices that can connect on a single subnet, and, large organizations might use DHCPv6 servers (to make sure the correct DNS servers are used, for instance), and that is irrelevant of the MAC address. MAC addresses also could be either 48 or 64 bits long, also providing even more ambiguity in that notion. At ARIN's IPv6 wiki, it mentions ISPs allocating /128's - i.e., single addresses, to customers, as well as /64 and /56. In any case, the criticism is a violation of WP:OR and WP:SYNTH, especially the one on how much users can use IPv6 in reality, which is ambiguous.Jasper Deng (talk) 17:05, 9 June 2011 (UTC)
I believe his thrust is well taken; the address space claim is overstated. We do not have to quote every WP:RS -- and certainly not ones engaging in hyperbole. Many of his comments do reside in WP:RS: IPv6 specs on network address and router docs; compare to your statement that interface numbers can be routed: even your ordinary address examples stop at /128 /64 addresses. The WP:OR and WP:SYNTH claims are too narrow. WP:CALC should allow us to say there are 233 people on the planet; if each of them had 216 network addresses (a /48), then only 1/32000 of the IPv6 address space would be consumed. (Nobody is saying that is a sensible policy.) Glrx (talk) 17:57, 9 June 2011 (UTC) (Brain bubble modified Glrx (talk) 14:36, 11 June 2011 (UTC))
The reason why I cited OR and SYNTH was because the IP had been posting specific #s of /48s vs. IPv4's addresses, which is original research as the IP apparently calculated them on his/her own. And if we begin to run out of address space, the allocation guidelines could be simply revised.Jasper Deng (talk) 18:04, 9 June 2011 (UTC)

Summary so far

Technically the new address space in IPv6 supports supports 2128 or approximately 3.4×1038 addresses. But that is a meaningless number to base comparisons on. Because the last 64 bits of the address space in IPv6 is to be the interface ID and there will never be 264 interfaces connected to one /64 subnet. So if we want to compare this new address space to the old IPv4 address space, a more fair comparison would be to say that IPv4 has a theoretical maximum of 232 devices, where IPv6 has a upper limit of 264 times the average number of devices per /64 subnet. If you want to compare the address space to the number of people on the earth, you should consider how big portion of the address space each user is likely to get. Under the IPv4 regime it was usually 1 IP (or not even that) per end user. Under IPv6 it seems to be at least a /56 per user, and may be even a /48 per user according to European guidelines cited above. So if you want to compare the new address space to the number of people on the earth, it is reasonable to compare the number of /48s with the number of people on the earth.

I think it is important that people is informed about that theoretical number of /48s available (if the address space is 100% effectivly used) are only about 40 000 times the current world population. Under IPv4 the address space was only 14% effectivly used, and under IPv6 we expect a bigger under-utilization of the address space, just because it is such a big address space to begin with. So if 10% of the IPv6 addresses can be effectivly used, then a maximum of only 4000 times the current world population of /48s are available. This is a far cry from the picture you get if you just dumbly compare the population to the huge number 2128. 84.49.97.50 (talk) 01:25, 13 June 2011 (UTC)

You may not know for sure. I have to tell you, for the 4th time, that /48 is not the most likely allocation size. Also, even if your idea is valid, the #s you are supplying are nothing but WP:SYNTH. Also, some ISPs may only give a single address to some users.Jasper Deng (talk) 02:17, 13 June 2011 (UTC)
The numbers I give are pure math that everyone can do with a calculator. I would say it is more like WP:CALC. 84.49.97.40 (talk) 03:52, 13 June 2011 (UTC)
No - see my reply below about uncertainty.Jasper Deng (talk) 03:57, 13 June 2011 (UTC)

Here are some quotes to help establish what is likely to be the allocation size for end users:

- Home network subscribers, connecting through on-demand or always-on connections should receive a /48.
- Small and large enterprises should receive a /48.
- Very large subscribers could receive a /47 or slightly shorter prefix, or multiple /48's.
- /48 in the general case, except for very large subscribers
- /64 when it is known that one and only one subnet is needed by design
- /128 when it is absolutely known that one and only one device is connecting.

84.49.97.40 (talk) 03:52, 13 June 2011 (UTC)


The thing is is that we can never know which one for sure, so the numbers you calculated above can't be inserted. Besides, many organizations get a /48 and use multiple users on their same block. It is just too ambiguous.Jasper Deng (talk) 03:56, 13 June 2011 (UTC)

When you compare numbers, it is a given that you must do some rough estimates. To compare the population with a count of /48s is a much better comparison than a count of all /128s. The latter is in my opinion to wrongly mislead the public into beliving the address space is bigger than it really is. So what do you suggest we do about this then? 84.49.97.40 (talk) 04:24, 13 June 2011 (UTC)
Give only the idea of it, like "However, the number of users supported by IPv6 is much less, because end users are often given blocks from /64 to /48 in size," without any of those numbers. Or, if you are convinced there is little deviation, use only one or two significant figures.Jasper Deng (talk) 04:26, 13 June 2011 (UTC)

@84.49.97.40: Why do you cite RFC 3177 when it has been obsoleted and replaced by RFC 6177? Concerning the effective address size I agree that something should be said about the number of supported end users/end sites, somewhere along the lines of Jasper. I only skimmed this discussion in my 5 min time in between so please check the revised RFC to see what you can do. Thanks, Nageh (talk) 06:46, 21 June 2011 (UTC)

I don't believe tht is still going on. The esential problem, regardless of what you might find slecively quoting from one RFC or another, is that you are not comparing like with like. The first deployed version of IPv4 was limited to 253 netowrks. That was expanded later but there is still wasted space as a natural consequence of subnetting. What, then, is the difference between IPv4 wasting space in this manner and Ipv6 doing the spame. What is the differnce not in terms of what you think, infer, or you wish to assert, but in terms of RS that makes a clear and explicit assertion that there is some clear point of any significance at all to be made. Crispmuncher (talk) 17:10, 21 June 2011 (UTC)
I'm a bit puzzled about your minor hostility (but will ignore it). I only became aware of this discussion as of now, and I recognized the outdated RFC, sorry. I understand what you are stating, that the situation is all the same with IPv4 A/B class networks and IPv6 /64 subnetworks, and I agree. Curiously, the very argument that you provide applies to the 5*10^28 addresses per person statement in the article. From that POV, also the address allocation with /64 subnet sizes in IPv6 is poor. I think it should be made more clear in the subsection that end sites are allocated /64 blocks and that even if every person is allocated an entire subnet there is still an overwhelming number of end-nodes that can be addressed in that subnet.
Anyway, I am not going to reply again on this topic. Nageh (talk) 17:47, 21 June 2011 (UTC)
Apologies. That hostility wasn't really directed at you but an expression of mild irritation that the same (and in my view poorly developed) argument was still burbling away after a couple of weeks. After looking at the history I see that that wasn't really the case anyway, it had dropped off and then you made an isolated comment, but that was not my impression when making those comments. Crispmuncher (talk) 14:42, 1 July 2011 (UTC).

IPv6 glue records?

Could someone please explain this term? It would be best to flesh out the article, as it refers to the term but nowhere is it defined. 108.18.128.85 (talk) 04:12, 23 July 2011 (UTC)

I changed the term into a link to the proper section in the DNS article. Kasperd (talk) 08:53, 29 July 2011 (UTC)

I have edited documentation on this page

Sincerely, IPv6 documentation prefix. – 2001:db8:: (rfc | diff) 06:24, 8 October 2011 (UTC)

Refactored deployment section

i am working on the deployment section to make sure it is a summary of the deployment page.--TheAnarcat (talk) 00:58, 20 October 2011 (UTC)

done. --TheAnarcat (talk) 02:39, 20 October 2011 (UTC)

potential resource

Power in Numbers: China Aims for High-Tech Primacy by DAVID BARBOZA and JOHN MARKOFF published New York Times December 5, 2011; excerpt ...

They show maps of China and the world, pinpointing China’s IPv6 links, the next generation of the Internet. China already has almost twice the number of Internet users as in the United States, and Dr. Wu, a computer scientist and director of the Chinese Educational and Research Network, points out that his nation is moving more quickly than any other in the world to deploy the new protocol. IPv6 — Internet Protocol version 6 — offers advanced security and privacy options, but more important, many more I.P. addresses, whose supply on the present Internet (IPv4) is almost exhausted. “China must move to IPv6,” Dr. Wu said. “In the U.S., some people don’t believe it’s urgent, but we believe it’s urgent.”

141.218.36.43 (talk) 21:42, 6 December 2011 (UTC)

  1. ^ Participants to the World IPv6 Day
  2. ^ Cite error: The named reference rfc2460 was invoked but never defined (see the help page).
  3. ^ [http://www.census.gov/main/www/popclock.html U.S. Census Bureau]
  4. ^ RFC 4291 IP Version 6 Addressing Architecture, R. Hinden, S. Deering (February 2006)
  5. ^ [http://pthree.org/2009/03/08/the-sheer-size-of-ipv6/ The sheer size of IPv6]