Talk:IPv6/Archives/2007

'Factual error' fix

Mr. 216.217.194.30:

Regarding fixing my 'factual error': the fact is correct. You just re-worded it in another way. My point was that of the 4billion+ address, one could be assigned to every person on the Earth; and that this is not enough. I will let you keep the change; at least for now.

147.240

The whole article focusess to much on the irrelevant topic of address space and does not mention any of the real capabilities or reasons to adopt IPv6 --- multicast, simplified headers, quality of service, improved security, authentication and privacy, local-use addressing, and so on.

This is deliberate. Address space is the reason why we need IPv6 in the first place. Any other improvements are just things that we might as well include since we are changing the network layer protocol. --Jec 22:33, 6 February 2007 (UTC)

Bigger address space not (only) purpose of IPv6

I have slightly changed the wording of the second introductory paragraph to remove the idea that bigger address space is the *main* purpose of IPv6. However, as the whole paragraph remains, the idea that "bigger address space is an important aspect of IPv6" is intact. I think that's enough.

IPv6 brings a load of improvements, and bigger address space is the most user-visible one of them. As such, it is indeed important to point it out, as it is done. That said, I'm not familiar with the design history of IPv6. It may be that increasing the address space was the first aspect that led to the creation of the protocol.

I know this comes out as pedantic, but hey, isn't that what an Encyclopedia is all about? ;)

That said, the IPv6 Features section still lists bigger address space as the "main" improvement. I might change that too, if the current change doesn't provoke a flamefest.

Please don't -- the address shortage is the very reason why we're getting IPv6. Everything else is secondary.--Jec 22:41, 23 August 2006 (UTC)

Speaking as a technically inclined person who's neither familiar with the technology nor the policies around this, I have a question: If the limit of the 32-bit address space is the main (or even a large) driver behind v6, why is IANA handing out /32s to everybody and their little brother? Doesn't that lock the whole system right into 32-bits again? The article indicates that the natural way to think of v6 addresses is as a 64-bit network with a 64-bit number of machines on each. If there is a technological reason for 32-bit prefixes, this ought to be mentioned on the page, I'd think. (If it is strictly a policy thing, then it might not be germane).Iron Condor 17:28, 23 February 2007 (UTC)

Meh. I'm less excited about mitigating the supposed address shortage. With IPv4/NAT, we are effectively extending the global 32-bit host address space into a global 48-bit TCP and UDP address space in exchange for signaling asymmetry and loss of end-to-end transparency (see RFC 3424 for an explanation of what I mean by that). There are a lot of addresses in a 48-bit space, and it's not clear to me that scarcity of those will ever lead to significant routing/address-assignment inefficiencies. The real purpose of IPv6, it seems to me, is that it makes signaling asymmetry and end-to-end transparency optional again, instead of mandatory, as is the case today with IPv4/NAT. Of course, this is a controversial view, but this is the discussion page. Jhwoodyatt 01:14, 6 April 2007 (UTC)

My statement was inacurate. Most of the features of IPv6 that don't relate to the size of the address space have been ported to IPv4. The main reason to switch to IPv6 are those features that are directly due to the larger address size: end-to-end communication, simpler subnetting, autoconf. Hence, I claim that the larger address size is the main feature of IPv6 over IPv4. --Jec 00:04, 29 April 2007 (UTC)

Larger address space

I have issues with this sentence:

"A technical reason for selecting 128-bit for the address length is that since most future network products will be based on 64 bit processors, it is more efficient to manipulate 128-bit addresses."

First, I don't think we can categorically state what kind of architecture future network products will use. Second, the latter part of the sentence makes no sense; The manipulation is "more efficient" than what? It sure isn't more efficient than the manipulation of 64-bit addresses.

I'd like to see a reference for the claim or see it taken out completely. --Teemuk 13:27, 4 September 2006 (UTC)

I have rewritten this section and removed this sentence. Making things easy for 64-bit computers was never a design consideration as they were very rare in the early 1990s. Wrs1864 00:36, 3 January 2007 (UTC)

1 address per atom

Just for fun, I decided to examine the assertion, "statements that IPv6 provides enough address space to give an address for each atom in the universe or even for each atom on Earth are highly exaggerated". Our Earth article lists the Earth's mass as about 6e24 Kg, or 6e27 g. If we assume (for the moment), that most of the Earth is Hydrogen (that's certainly true for the universe, but probably not for Earth), then there's 6e27 x 6e23 (Avogadro's number) = 36e50 or about 4e51 atoms in the Earth. If we make a more reasonable assumption that the average atomic weight of an atom in the Earth is 40, then we still come up with 1e50 atoms. Sorry, we've run out of IPv6 addresses for atom-net :-) -- RoySmith (talk) 19:51, 31 October 2006 (UTC)

Are you supposed to convert the mass to grams and then multiply that by Mr. Avogadro? I don't do chemistry (I do physics and maths), but the SI unit of mass is kg, so it would seem to me that you should do 6e24 × 6e23, instead of 6e27 × 6e23, if you want the units to be homogeneous. But, like I said, I don't do chemistry. ;) Stuart Morrow 21:38, 30 January 2007 (UTC)

Nevermind, I just looked it up, you were right, and I was wrong. Stuart Morrow 21:39, 30 January 2007 (UTC)

"Unique Addressess" missing a digit group?

I personally like the example used for demonstrating the number of unique addresses. However, the number appears to be incorrect. In a glance the number appears to be correct, but close inspection shows that it is missing a digit group, maybe? The number listed is 340,282,366,920,938,463,374,607,431,768,211,456 which is 3.40282366920938463374607431768211456e+35, correct? However, 2^128 is actually 3.4028236692093846346337460743177e+38 on my caculator. I'm not sure which digit group is missing, but my guess is the last one. Can anyone help with this? 63.101.242.220 22:22, 2 January 2007 (UTC)

Obviously, your calculator is rounding. That's pretty common - very few calculators actually have 128 bit accuracy.Iron Condor 00:48, 24 February 2007 (UTC)

My text editor says that the exact value does indeed have a repeated 463 group, so the recent change was incorrect. Wrs1864 22:26, 2 January 2007 (UTC)

RFC1918

The article should mention private IPv4 addresses as a stop-gap for IPv4 address conservation.. und1sk0 11:02, 6 January 2007 (UTC)

The article does mention NAT, which is primarily used with private addresses. NAT, by itself, really doesn't primarily reduce the IPv4 exhaustion so I guess reworking the article to more directly mention primvate address and mention NAT in conjunction to it would be good. Wrs1864 22:50, 7 January 2007 (UTC)

Too technical

This article makes very little sense to someone who's not familiar with network administration. Perhaps that's unavoidable with this subject matter, but I came here from the Windows Vista article to see what the heck IPv6 is and I still don't really have any greater idea of what it is than I did before. :) 205.157.110.11 22:16, 10 January 2007 (UTC)

• IPv6 is a technical standard pertaining to networking. Therefore I do not see how you could expect to read anything but a technical article about networking. If you weren't able to get an idea about what is this IPv6 thing really is, then you can picture it as a new version of IPv4 that makes available a whole gob of IP addresses, so many that it simply will not be possible to run out of available addresses, much like what is happening right now.

Error in Notation section?

Says here: "Thus, ::ffff:1.2.3.4 is the same address as ::ffff:102:304". I'm not IPv6 expert, but if last one is supposed to be hex then sure those addresses aren't same. 80.235.27.168 01:48, 1 February 2007 (UTC)

• What exactly is the problem? The first one is in decimal notation (well, the last 4 bytes), the second is in hex.--Teemuk 12:29, 6 February 2007 (UTC)
• Still, shouldn't the bytes be reversed when written as word? That is ::ffff:201:403 80.235.27.168 16:13, 8 February 2007 (UTC)
  • No. You're probably thinking about the way certain processor architectures store words in memory.--Teemuk 09:28, 13 February 2007 (UTC)

Question from a non-native speaker: There's a change in section "Notation" from "hexadecimal digits" to "hexadecimal numbers". IMHO

fd09cafe

is a hex number, consisting of eight digits. Hence I'd like to see the change reverted to the original text (eight groups of four hex digits). Comments?

• I agree it should be "digits" or maybe "numerical digits"; I'll revert it. As a side note, I guess strictly speaking fd09cafe would be a hexadecimal "numeral" representing a certain "number" (another numeral representing the same number would be 4245277438).--Teemuk 09:11, 19 February 2007 (UTC)

Error in Network Notation?

"For example, 2001:0db8:1234::/48 stands for the network with addresses 2001:0db8:1234:0000:0000:0000:0000:0000 through 2001:0db8:1234:0000:0000:FFFF:FFFF:FFFF"

Wouldn't it be from address 2001:0db8:1234:0000:0000:0000:0000:0000 to 2001:0db8:1234:FFFF:FFFF:FFFF:FFFF:FFFF ?

136.182.158.129 17:44, 2 March 2007 (UTC)

Leet Speak

Did anyone notice that the IP mentioned in the Addressing section ends with "1337" (leet)?  :) —The preceding unsigned comment was added by 204.13.204.2 (talk) 15:20, 7 March 2007 (UTC).

So, a serious question...

How can I get my billion or so addresses for my small business? Is there any way for me to allocate IPv6 addresses to my colocated server? --Kickstart70-T-C 02:54, 30 April 2007 (UTC)

You have to contact your ISP or hosting provider and request that they provision a block of addresses for you. This is assuming your ISP supports IPv6; many do not right now.

There are also several 6-to-4 gateways that will let you obtain an IPv6 address via a tunnel. The downside to these is that there's increased network overhead, which will slow things down. Take a look at sixxs.net for an example. I'm sure you can find more if you search. --Tjohns ✎ 11:23, 2 May 2007 (UTC)

HD-DVD Encryption Key

Please stop replacing the IPv6 address example with the HD-DVD encryption key. Regardless of your views on this issue, it simply doesn't belong in this article.

Let's keep unrelated pages (like this one) out of this. --Tjohns ✎ 10:33, 2 May 2007 (UTC)

It's a number. Out of the context of AACS, the number has no value and the key's originators have no say in how a number is used. Placing it in a stable article for the sole purpose of using the number is probably a violation of WP:POINT, but removing it from a stable article is equally unjustified. For all you know, the address that's there now is the product key for some movie just by random chance. – Þ  16:09, 2 May 2007 (UTC)

I agree about the "it's a number" part. Personally, I find the idea of invoking the DMCA over a simple number to be misguided.

However, it's quite clear in this case that number is being inserted in order to make a political statement. It wasn't chosen as a random number, and it's not relevant to the article. Wikipedia is not a soapbox. If the current example turns out to be some sort of product key by accident, I'm pretty sure it wasn't done intentionally. --Tjohns ✎ 20:30, 2 May 2007 (UTC)

In this instance, I agree with you because the article was already stable. But if I were writing this article from scratch and picked that number because it just so happens to be my favorite, I'd have no problem with it. It's no different to me than 69 or 42 in that regard. If I went around Wikipedia replacing every example with 42, people would rightfully be upset for reasons that have nothing to do with the number itself. – Þ 

I'd remove it on sight. There's quite enough childish point-pushing on the internets (and wikipedia in particular) already, benign or not. Chris Cunningham 10:16, 4 May 2007 (UTC)

I thought I'd put up this quote, linked from your user page: "Wikipedians have attached so much importance to some small detail that they fervently revert, dispute, and argue any change that happens to ruffle their editorial feathers". I think you need to chill out if seeing the wrong number every once in a while causes you such consternation. – Þ  05:39, 5 May 2007 (UTC)

The addresses used in the article have been chosen to obey the current IPv6 addressing architecture -- it's not an accident that they are in 2000::/3. Changing the addresses into some random hex number is certainly not an improvement.--Jec 20:41, 16 May 2007 (UTC)

Site-local addresses?

IPv6#Special_addresses lists some {unique unicast,site,link}-local networks, but Private_network#Private_networks_and_IPv6 states that these have been deprecated. Could anyone knowledgeable on this subject edit the article(s) to reflect the present state of things? Thanks in advance. --2002:d594:ab22::1 13:00, 2 May 2007 (UTC)

The description is quite correct. Link-Local addresses (fe80::/64) are only used in one network segment and they remain "valid". Unique Unicast is an addressing method used to prevent the hassle we've got with 192.168.1.0/24 on all possible IPv4 "private" networks by introducing a 40 bit random number after the fc00::/7 (fd00::/8 if one obeys to the standard's random method) prefix. The only outdated "private" addressing scheme is the former Site-Local range (fec0::/10), which has been deprecated in September, 2004. Rewrote the Private_network article to reflect the current status. Sigkill 13:35, 4 May 2007 (UTC)

Sentence to be corrected

At the beginning of the article, we see this:

By the winter of 1992, several proposed systems were being circulated and by the fall of 1993, the IETF announced a call for white papers (RFC 1550) and the creation of the "IPng Area" of working groups.

This should be changed because the seasons of winter and fall are not at the same time everywhere in the world so the sentence is not accurate. I would change it myself but for some reason, the article is locked. 65.92.247.173 01:00, 12 May 2007 (UTC)

Performance

In IPv6 advantages can we add a statement "IPv6 is faster than IPv4" IPv6 sets network speed record PassportDude 20:30, 2 July 2007 (UTC)

No, because it's not necessarily true:

* if you're limited by bandwidth, IPv6 may (or may not) be slower than IPv4 because of the larger header size;

* if you're limited by router per-packet overhead, IPv6 may (or may not) be faster than IPv4 due to the simpler header structure;

* if you're running over the public Internet, Ipv6 may (or may not) be slower than IPv4 due to the extensive use of tunnels.

Jec 02:17, 6 July 2007 (UTC)

Understand we neeed to be more specific. Lets just state the facts:

• A team of internet2 researchers "surpassed the current IPv4 records proving that IPv6 networks are able to provide the same, if not better, performance as IPv4"

(unknown editor, ~~~~ wasn't expanded due to still open <ref> tag. Sigkill 07:26, 3 August 2007 (UTC))

Merge with IPv6 internet

There's nothing to merge. IPv6 internet is content-free and what content there is all unsourced opinion and speculation. It should just be deleted. (unknown editor, ~~~~ wasn't expanded due to still open <ref> tag. Sigkill 07:26, 3 August 2007 (UTC))

Port Number Width Expansion

One question I had for my everday work. Does the IPv6 standard widen the port width? IPv4, as we all know, uses 16-bit port numbers. Was this carried over or possibly increased to 32 or 64-bit either by official standard or rule-of-thumb?

No, TCP and UDP carried over IPv6 still use 16 bit wide port numbers, these protocols haven't been changed during the IPv4/IPv6 transition. Sigkill 07:26, 3 August 2007 (UTC)

DOD purchase information obviously wrong

Under Deployment Status, the article states that the US Gov spent money to purchase 247 billion addresses, giving reference [9].

Reference [9] points to an article that states, among other inaccuracies, that a /16 is 247 billion addresses.

The slash-notation refers to bit-mask size; a /16 mask on a 128-bit address leaves 112 bits of address space (2¹¹² or appr 5.19E+33 addresses.)

I didn't find a record of the actual purchase. A /16 sounds plausible, and the *smallest* purchase that I could see the DoD making would be a /48. The organization I work for is considerably smaller and manages a /32.

Besides, all allocations will be masked by whole numbers. There is no power of 2 that will give 247 billion addresses, although 2³⁸ comes close with app. 275 billion.

Edit: Found a correction to the linked article for [9] at http://www.gcn.com/print/26_15/44566-1.html, but I don't seem to be able to edit the references. —Preceding unsigned comment added by Cafal (talk • contribs) 15:16, 7 September 2007 (UTC)

In the IPv6 address space, any organizational allocation smaller than a /64 (over 18.4E+18 addresses) is going to be very rare. 207.160.138.138 19:20, 6 September 2007 (UTC)

hey i have a seminar on ipv6 plz send more content for that plz help meeeeeeeeeeeeeeeee —Preceding unsigned comment added by 219.64.85.47 (talk) 17:05, 27 September 2007 (UTC)

Valid Point?: Practicality and Necessity of Domain Names

With 32 bit IP addresses...
-Memorization of an IP address is not too daunting
-When possible, an undoubtedly large percentage of server admins would probably rather have people just know the IP address instead of paying for name hosting. (e.g. a small revision control system, forum, game server, etc that is only known by a few people)

With 128 bit addresses, things change. Memorization is 4 times as difficult (memorization difficulty isn't really quantifiable, but you know what I mean). Most people will be required to write or store addresses. If name hosting wasn't used before, it is now needed more so than with 32 bit addresses.

Since, according to the article, "The main improvement brought by IPv6 is the drastic increase in the number of addresses available for networked devices," this is a fundamental problem that comes with IPv6 implementation.

I'm suggesting making a Disadvantages (or Criticisms, etc) section that lists problems that will come with IPv6. With some written support in response to this wiki-"thread", I'd gladly make one. Just off the top of my head, another issue we could put under the section is the compatibility problems applications/systems would have with the update. Abandoned software would become antiquated.

Teimu.tm 22:31, 16 July 2007 (UTC)

RFC 1650

The link to RFC1650 in the tiny historical intro [please extend, history is good for your tehcnical brains! And sure, technical stuff is also good for my historical brains!] takes me to a document about MIBs, SNMP, managed objects. Could someone check the reference? thanks in advance145.99.165.66 (talk) 23:06, 13 December 2007 (UTC)Cecilia

I think you were looking for RFC 2460. It's mentioned later in the intro. ~a (user • talk • contribs) 05:49, 19 December 2007 (UTC)

Lack of background information

The flow of information in this article stinks. It just kinda jumps right into talking about IPv6 w/o giving any background information. A good article should start with a basic background on the topic, since most people reading will have come w/o much previous knowledge about the subject (that's why they're here!). -Jaardon 07:20, 23 April 2007 (UTC)

Discussion of IPv6 Extension Headers seems missing

Either that or I can't find it. In the section titled "IPv6 Packet" there is a brief mention of an "Options Header" to take place of the IPv4 Options field, which would be a good place to discuss or link to a discussion of the various Extension Headers. Seems unlikely, but has it just not been written yet? If not, should I take a stab at it? Michaelshiloh 18:49, 9 January 2007 (UTC)

Misuse of term VLAN

The reference in the article to VLANs implicitely defines a VLAN as any LAN segment, which is incorrect. The reference should be replaced with a generic LAN. und1sk0 05:59, 8 January 2007 (UTC)

U.S. Federal Government Deadline for IPv6

One of the big catalysts for IPv6 migration in the U.S. is the federal government's June 2008 deadline for agency backbone networks. There is one mention of this in the article, and I added some additional info. But more details on this are probably needed. It could be a major shot in the arm for IPv6 migration.—Preceding unsigned comment added by GovStuff (talk • contribs) 15:17, 16 May 2007