Talk:IPv6/Archives/2008

IPv4 address exhausation

I think it needs to be added, it's not just NAT but the good management by the various NANIC (North American NIC) and the Europen NIC which have helped alleviate the problem as well as the cooperation of address holders in reclaiming all those address given out like candy at the beginning. I believe Xerox or someone had a whole Class A originally?

Why do people keep citing Cisco (a vendor that stands to make money with IPv6 deployment) that IPv4 will run out in 2009? Has Wikipedia become a lap dog for Cisco? This is absolute nonsense. In 2003, there were 100 blocks of /8 IPv4 addresses left and was set to last until 2023! —Preceding unsigned comment added by 69.105.224.69 (talk) 07:03, 8 November 2006

Yes, Cisco does stand to make money from IPv6 deployment, but the statistics they give appear to be sound. Looking at the current IPv4 address assignments from IANA, we can see that there are currently 71 /8s shown as "IANA - Reserved", which is the status of blocks which are available (some of the "various registries" space may also be available) however of those 71, 18 cannot be allocated (0/8, 127/8, and 240/4,) leaving 53 /8s plus whatever is unallocated in the "various registries" space left. Also, note this report on IPv4 address allocation, which says that there is currently the equivalent of 54 /8s available (the "IANA pool") and projects that the IANA pool will be fully allocated to RIRs by 2011 and that the RIRs will use up those allocations by 2012. Also, I don't know where the description of a /8 as "256-host" in your version comes from, but it is just plain wrong. -- AJR | Talk 13:56, 8 November 2006 (UTC)

Now, I guess even experts have this idea somewhat confused. IPv4 exhaustion is quite similar to the exhaustion of fossil fuels. It's not that IPv4 adresses will just "run out" like *poof*, killing the Internet suddenly. IPv4 exhaustion is a reality we live in right now. When you need to pay extra just to get a single static IP address, you are being robbed by IPv4 address exhaustion. When you look at the Internet and see a veritable NAT hell, you're being inconvenienced by IPv4 address exhaustion. When a few years from now on, when they start redividing the gargantuan address spaces allocated to a few organizations in the early days, and IPv4 addresses will stop making structural and geographical sense, you'll see IPv4 address exhaustion in action. And when routers will slow down with the extra burden of such chaos, IPv4 will become unviable, even if there are technically addresses that have been left unassigned. Go IPv6 NOW: 6to4 XD Wilderns (talk) 15:34, 25 February 2008 (UTC)

The entire exhaustion section is obsolete; the RIR's agree the present target date is 2010 to 2011. Recent ARIN announcement on deplation and IPv6

Autoconf

As I understand it IPv6 should remove the need for DHCP/BOOTP. Either I have misunderstood, or that should be covered here (please!).

Not entirely - IPv6 allows for autoconfiguration of IP addresses and routing but doesn't auto-configure stuff like DNS servers, DNS search domains, NTP servers, etc. So if you want to autoconfigure these things you need to use DHCPv6. However, I believe (someone currect me on this if I'm wrong) that a lot of the stuff like DNS servers have now been allocated anycast addresses so can be configured statically and should Just Work wherever you plug your computer into. User:FireFury

1.: Stateless configuration is done by router advertisement. Host gets an IPv6 address, that's all

2.: Stateful configuration is provided by DHCP in IPv6 also. DHCP can provide additional information like e.g. DNS.

Which way ist better ? It depends. For a quick and dirty installation stateless config may be sufficient. A larger site will require additional features of DHCP. —Preceding unsigned comment added by 193.138.96.5 (talk) 16:52, 20 March 2008 (UTC)

"I'm not quite sure I believe that..."

Every time I hear stuff about IPv6 I hear something I don't quite get, or don't believe. If I can just run some of these ideas past you guys, verifying (or not!) their accuracy.

• 1. IPv6 will eliminate dynamic IP systems. Well, I sure hope so myself, since that makes spammers' jobs one great chunk harder. And it's certainly true that ISPs will not need to offer dynamic IPs anymore. But will there be anything stopping them from continuing to do so?
  • No, there's nothing stopping them from assigning IPv6 addresses dynamically. In fact, there is a DHCP version being designed to do just that. Dynamic autocofiguration is likely to remain very popular even with IPv6 since the ISPs typically want to have maximum control over their network. The stateless autoconfiguration depends on the MAC address of the NIC, which can be faked easily.--Teemuk 08:19, 6 November 2006 (UTC)
    • Well, I'd say while there's no reason for them to stop dynamic address allocation, there will be no reason for them to continue. Allocating addresses dynamically doesn't help in balancing the network load. It's something we all came to accept as the natural way of things, but it doesn't have to be that way. It originally came from a dial-up ISP having say, 200 IP addresses, and 1000 subscribers. When someone dialed in, he was given an address from the available 200. It was a necessary course of action. Having lots of addresses, in IPv6 this would be an unnecessary complexity. And in fact, governments may even start legislative action to prohibit dynamic address allocation as a way to further prevent cyber-crime. Wilderns (talk) 15:52, 25 February 2008 (UTC)
• 2. IPv6 will eliminate ISPs themselves. I heard this somewhere, can't remember where. I lack the theoretical understanding of telecommunication to tell whether or not this is likely.
  • No, I have no idea what would prompt such an assertion. ISPs will be just as necessary as they're today.--Teemuk 08:19, 6 November 2006 (UTC)

Your insight is appreciated. BrokenBeta [talk · contribs] 20:05, 4 November 2006 (UTC)

IPv6 NAT: Never say Never, and Architectural Nuances

No one really wants to use NAT with IPv6, but there have been a sufficient number of problematic transition scenarios discussed in the North American Network Operators Group (NANOG) and other forums that I consider it extremely unwise to say NAT will never be needed. Undesirable, certainly, just as NAT introduces a good many problems in IPv4.

As has been mentioned many times, Wikipedia is not the IETF or NANOG. There are multiple forms of NAT, and there are also things that aren't pure NAT but considered so by many people that aren't deep into protocol architecture. For example, many SOHO interfaces to the Internet may actually be stateful firewalls that proxy TCP sessions in different address spaces: registered IPv4 and RFC1918. While a proxy that has aggregatable IPv6 unicast space on one side and ULA on the other isn't truly doing NAT, I suspect a large number of users, of moderate sophistication, would believe that it is.

To put a flat statement that NAT will never be required, in the introduction to the article, is inviting argument about edge cases and exceptions, to say nothing of future requirements. NAT was not in the original IPv4 architecture, and indeed violates the End-to-End Principle. It still is a tool in a toolbox. Not all tools are desirable: I am trying to find the key to a misplaced padlock, but I may have to use bolt cutters and replace the lock. NAT and bolt cutters both can be ugly but necessary. Howard C. Berkowitz 20:00, 14 August 2007 (UTC)

--

Certainly, one of the objectives for developing IPv6 was to eliminate the perceived need for network address translation. Some recent IETF work has focused on documenting the positive results of that specific effort, e.g. RFC 4864, RFC 4966, etc. Furthermore, none of the scenarios discussed in NANOG or IETF have produced a sound technical argument that IPv6/NAT is the appropriate tool for solving the problems they have been discussing. Even the never-ending site-multihoming debate has so far not produced a compelling argument for accepting the need for IPv6/NAT. If there were such an argument, then IETF consensus would resolve around it eventually. If it hasn't happened after more then ten years of wrangling, it seems unlikely to ever happen.

Worries about inviting argument about edge cases and exceptions and future requirements (oh my!) are just that. Worries. When those worries evolve into substantial technical concerns, then the introductory preamble here should be amended to admit that the need for NAT has not been eliminated with IPv6. In the meantime, the article is simpler and more clear with the unqualified language. Jhwoodyatt 21:11, 14 August 2007 (UTC)

I'd have to sit down and think about it, but I suppose I've been playing in the IETF, NANOG, and IRTF for 20 years or so. I don't want to count the number of times that worries didn't turn into something real. Given that the informal IETF motto, according to Dave Clark, is "We don't believe in kings, presidents, or voting. We believe in rough consensus and running code," I can think of few times the IETF has been absolute. Luckily, I wasn't one of the usual suspects when we thought that we'd never need a routing table with more than 255 networks, or that hosts.txt would always serve, or the end-to-end assumption would never need to be violated, or RIP would certainly be adequate for routed networks of plausible size, and, as the T-shirt read, "IS-IS=0". Can we come to some sort of consensus, in the IETF spirit, that while NAT is undesirable in IPv6, it's unwise to predict the future? Also, I do consider it not an edge case, but an urban legend not likely to change, that stateful proxying firewalls are equivalent to NAT. Howard C. Berkowitz 21:30, 14 August 2007 (UTC)

I think the current text in the introductory preamble, i.e. "eliminates the need for NAT," avoids attempting to predict the future by being written in the present tense. I would say that if a need for IPv6/NAT were to be identified in the future, then that would be a good time to amend the introductory preamble to reflect that fact. That said, perhaps "greatly reduces the perceived need for NAT" would be more NPOV? That would, at least, recognize that there are still other communities that remain unconvinced that they can live without IPv6/NAT. Jhwoodyatt 03:29, 15 August 2007 (UTC)

Jhwoodyatt, that's strikes me as an improvement that is much more NPOV. Please correct me if I misunderstand, but I think we are in agreement about another aspect that's been confusing in the introduction: it's misleading to overemphasize the ability of IPv6 apparently give a static address to every ant, but it's quite correct to say that the longer address provides great flexibility both in currently recognized forms of assignment, as well as not making it as difficult to deal with future requirements as it was in the "just-in-time" incremental enhancements in IPv4. I was at the Toronto IETF where the plenary came to consensus that 128 bit addresses were more future-proof than 64 bit.

To me, it is also future-proofing to avoid flat statements that NAT will never be needd. As CKD pointed out, the lack of need for NAT as a means of avoiding address exhaustion probably is noncontroversial, but address exhaustion is not the only reason we have NAT, and NAT-like mechanisms such as proxy firewalls, in the current Internet. Howard C. Berkowitz 11:25, 15 August 2007 (UTC)

CKD, your edit is excellent. Howard C. Berkowitz 23:32, 14 August 2007 (UTC)

"violates the End-to-End Principle"? In most cases it sounds like a feature if Joe Employee's desktop accidentally gets connected to the internet but is still not reachable, or if Joe Employee can't run P2P apps properly. One man's communication problem is another man's security policy at work. Also given IPv6's designed incompatibility with IPv4, some form of NAT/Proxying will be required for IPv6 only hosts to talk to IPv4 only hosts and such a scenario would likely be very common in the future if we really run out of IPv4 addresses AND ISPs choose to assign customers IPv6 addresses instead of RFC1918 IPv4 addresses (the latter being a well tested workaround/method that is likely to initially work better than the IPv6 equivalents). —Preceding unsigned comment added by 202.75.240.2 (talk) 08:20, 3 September 2007 (UTC)

Making sure Joe Employee is not able to run P2P apps, or securing company systems from attacks is not NAT, it's called IP filtering. It's the original meaning of a "network firewall" - controlling the passthrough of traffic between subnets and the Internet. Joe Employee's work PC can have its unique static IP address, and at the same time be perfectly safe and conforming to company Internet policy. True, NAT is quite comfortable in that sense that it filters everything out. :D As for IPv4 and IPv6 coexisting, it's something that is working even now, and it's not NAT, even though there is some "translation" of "network addresses" involved *hehe*. NAT is basically an irreversible translation (many into one, a private address range becoming a single Internet address), while IPv6 to IPv4 interoperation methods are "one to many", meaning every IPv4 address is in fact an address RANGE in IPv6! Wilderns (talk) 16:10, 25 February 2008 (UTC)

Still, NAT will always be a desirable tool for illegitimate Internet sharing. ;) You have 10 computers on a link that should only hold one according to the contract? Well, NAT is your answer, be it IPv4, IPv6 or IPv10. Wilderns (talk) 16:11, 25 February 2008 (UTC)

No checksum at network layer?

This is somewhat inaccurate -- the IPv6 standards specify that L4 protocols (TCP, UDP, etc) are to compute their checksums using a pseudoheader derived from a subset of the IPv6 network header. However, the pseudoheader does not include volatile fields such as TTL. —Preceding unsigned comment added by 128.220.159.20 (talk) 19:53, 5 February 2008 (UTC)

link typo...?

I've stared a hole in footnote 12 (currently): the ref is:

<ref>[http://www.stsc.hill.af.mil/CrossTalk/2007/07/0707KimMacha.pdf Providing the Tools for Information Sharing: Net-Centric Enterprise Services (Department of Defense Chief Information Officer Information Policy Directorate)]</ref>

and I see nothing wrong with it. The footnote appears with an extra open-square-bracket '[' however. It's gotta be something obvious, right? Pete St.John (talk) 17:17, 4 January 2008 (UTC)

after spamming the edit history with attempts (not so easy to see the footnote in preview), and experimenting at my user page, I moved the close-right-bracket ']' to before the colon. My theory is that the colon (in "Sharing: Net-Centric...") is getting parsed as a port number. So the footnote looks OK now but I'm not sure I understand. Pete St.John (talk) 17:41, 4 January 2008 (UTC)

The vastyness of addressable space

The fact that IPv6 addresses more computers than we foreseeably need does not refute it; old style addresses too few, and there are other issues in the choice of format (such as word size). However, if every core of emergent multi-core machines (on the order of a hundred on GPUs now) had a unique global identifier it would be interesting, right? It's imaginable that cores will be microscopic and you might have avagadro's number of them in your house. Pete St.John (talk) 23:18, 9 March 2008 (UTC)

Reference to obsolete rfc 2462

... in article should be replaced with rfc 4862. --Xerces8 (talk) 15:40, 21 March 2008 (UTC)

IPV6

• —Preceding unsigned comment added by Sandeepsoman (talk • contribs) 08:19, 1 May 2008 (UTC)

I recently tried to set up a second 802.11b access point in my house since I wasn't getting enough coverage from my first. Since I was knowledgeable I had set a simple key in order to provide a modicum of privacy if not security. But this new 802.11b access point was more sophisticated and offered a large collection of choices for how to setup security.

If I was confused, I could imagine the difficulty a home user faces. It's just easier to ignore the issue and just let the system run in the clear. This does work well enough and has the side-benefit of allowing others to borrow the connection which, so far, has been a social good. When traveling through a city there is a good chance you can use a nearby 802.11 connection.

This works well enough if we simply want to connect to a web server. But many of these access points also share a single connection among many users just like home "routers" for LANs. But once you go beyond the "web-potato" model of just browsing or sending email you find that you need special settings to work around "firewalls" and other barriers. You can't simply participate.

It would be wonderful if we could ignore all the complicated settings and protocols and just connect to the Internet. In fact, that's the way it was ten years ago when organizations that had a direct Internet connection and the net seemed safe.

But as corporations connected their local networks to the larger networks they were afraid of being too accessible and thus erected complex barriers between the company network and the rest of the Internet and allowed only selective access on the assumption that the Internet was like a library in a bad neighborhood.

While corporations often treated their isolation as a form of protection home users faced a similar problem in that their ability to participate was limited to having a single address. Network Address Translation is one technique way to work around this limit by second-guessing Internet protocols. But such approaches work only for a limited set of applications and make it difficult to develop new applications and services.

As long as you don't try to innovate and stick to what already works it seems that the Internet is working very well. But it is really a veneer that gives the illusion of innovation. Instead of simply creating new value all the effort goes into working past the difficulties of simply getting finding and connecting to other systems and we have lost control over what happens to the packets between the two end points.

Each new effort such as web services and P2P finds its own novel solutions which do not add to the synergy we found in the Internet Community. We find ourselves mining the past since those ideas are easy to explain and thus can be funded. New ideas and innovations have become too difficult. Tragically, we can't quantify the opportunities lost and the relatively small value we get from mining the past seems large but only because we don't know better.

                                                                            Sandeep soman
                                                                            sandeepsomanv@gnail.com

Disabling IPv6

I removed that section because it just linked to a bunch of "how tos", which don't belong on Wikipedia. Any objections? -- FatalError (t|c) 00:10, 18 April 2008 (UTC)

Wikipedia articles aren't supposed to be "how to" guides, but I don't see why linking to them is wrong. They contain information that can not be easily fit into the article, which is one of the things that WP:EL says external links are for. The section was short. I guess don't see a lot of reason to remove it, but I'm not going to fight to put it back in. Wrs1864 (talk) 22:41, 18 April 2008 (UTC)

I'm reinstating this section, but without links to the howtos. I think it's a reasonable compromise.Jec (talk) 08:00, 3 May 2008 (UTC)

Criticism?

I was a little surprised not to see more drawbacks of IPv6 given in the article. Several advantages are given, and the article twice calls IPv6 a "conservative extension of IPv4", which seems at least debatable. If the only thing discouraging the use of IPv6 is the availability of NAT, as the article seems to imply, why is adoption so low? Wmahan. 07:11, 11 September 2006 (UTC)

• Replacing software (including firmware);
• modifying applications;
• larger header size.

All three are mentioned in the article. --Jec 00:05, 29 April 2007 (UTC)

Quoting the availability of NAT as something that discourages IPv6 adoption is like... say, stating that we really don't need late stage cancer remedies when we have euthanasia. NAT is something that was never supposed to happen. It's an accident and a pita. Wilderns (talk) 15:41, 25 February 2008 (UTC)

I have seen the page~ A criticism of IPv6 that is quite good in context, and I feel that the article "IPv6" should have a section about the criticisms of IPv6. However, I know that adding the section will be very hard (since much research have to be done for writing) and controversial (due to some "expert" would like to revert). Therefore, I would like to ask any "expert" for adding the section. QQ (talk) 18:53, 22 May 2008 (UTC)

Criticisms are important to make sure the article is balanced, and I think too many of the problems with IPv6 are washed over. However, as mentioned above, many of the criticisms are already addressed and the particular article you have linked to seems to be, well, not very well informed. The extra couple dozen bytes in IP header for the larger addresses is not very important, considering the massive increase in bandwidth in the last 20 years. Contrary to the article's claims, the addresses were made that large in order to *reduce* router overhead and a lot of people involved in building routers were involved with the development of IPv6. The article talks about how you will have an "IP address that never changes" due to the MAC address, but that is incorrect. The MAC address is only the bottom 64 bits, and as mentioned already in this article, RFC 3041 addresses the privacy issues. The top 64 bits are set up to make routing to the destination network easy. The article complains about how the routing info in IPv6 makes things easier to locate where you live, but this is exactly the same as with IPv4, only IPv4 requires a more calculations slowing routing down. Basically everything I saw in that article struck me as criticisms based on misunderstanding/ignorance rather than real problems with IPv6. Wrs1864 (talk) 19:50, 22 May 2008 (UTC)

Then, do you think making a section about the criticisms of IPv6 is NOT NECESSARY? But I still think the section should be made, and making such section will be very, very difficult... QQ (talk)

As I said earlier, criticisms are important to make sure the article is balanced, and I think too many of the problems with IPv6 are washed over. I do think it is far more effective and useful to have the entire article written with a neutral point of view, with problems pointed out in the correct sections rather than have a 'rah-rah! go IPv6!" article with a "criticisms" section. A criticisms section may still be useful, but I just don't think it would be the first approach I would take. I also think that it is important to bring up *valid* problems. In the article you mentioned above, one of their complaints was basically "routing will be slower because the fragmentation information in IPv6 is put into an optional header". This is bogus because IPv6 is designed to have routers to not have to deal with fragmentation, rather it is done by the end points via Path MTU discovery. So routers will not only not have to check the optional header, but they will (in theory) be faster because they don't have to deal with fragments at all. A possibly more valid complaint is "does Path MTU discovery work well in practice?" If I recall correctly, the PMTU ICMP packet is spoofable, so it is possible to create a denial-of-service attack using them. The PMTU article lists two RFCs about how to deal with problems with it, which isn't a good sign in my opinion. Another more valid complaint is that the transition from IPv4 to IPv6 is not very easy, DJB has a nice rant page about it, although being a rant, isn't exactly fair or balanced. Basically, I think it is important to cut out the "rah-rah! go IPv6!" stuff, and back up complaints with well-reasoned, reliable sources (WP:RS). Wrs1864 (talk) 13:14, 23 May 2008 (UTC)

money spinner?

Well I doubt there is every going to be a demand for so many high speed addresses. Names would be easier to use now. Wonder why POTS scales :-)

It is not that there will be demand for that many addresses, it is that there will be demand than addresses in IPv4. You have to remember that IP addresses are given to ISPs, Companies, Universities, etc. in large blocks often 65,536, so there is a good deal of waste. SMakabwe (talk) 20:47, 31 May 2008 (UTC)

Split

The article is getting rather long and disorganized. So I would propose splitting it into, IPv6 Development and Implementation, and IPv6 Deployment. If its not split it needs at least some major clean up. --SelfStudyBuddy^TALK-- 16:43, 14 May 2008 (UTC)

• Oppose as proposed. There should be 1 IPV6 article, with subpages if necessary as you mentioned per WP:SUMMARY. There should be a single page located at IPv6 that explains what it is with {{main}} tags for the subarticles, not a dab page that will be confusing to users. Oren0 (talk) 16:59, 14 May 2008 (UTC)
  • Hadn't thought of WP:SUMMARY it probably works better in this situation anyway. I will just remove the split template. --SelfStudyBuddy^TALK-- 23:49, 15 May 2008 (UTC)
• I agree that this article is getting long and should have sections broken out. Wrs1864 (talk) 00:00, 16 May 2008 (UTC)
  • Thinking about this, I've long pondered breaking out the "IPv6 deployment" stuff into another article because it takes up a lot of room both in this article, and in IPv4 address exhaustion. The subject really doesn't belong in the latter article at all and appears to be more of "I don't want to believe the IPv4 addresses are running out because I don't want to switch to IPv6" rants. Yes, the problems with IPv6 need to be mentioned there, but pointing to an appropriate article would be better. Wrs1864 (talk) 15:21, 21 May 2008 (UTC)
    • I have gone ahead and moved the IPv6 related stuff out of IPv4 address exhaustion since it is really about IPv6. While it is kind of a clutter of things, it also adds some balance to this article which is far too much "rah! rah! go IPv6" to be neutral. Wrs1864 (talk)
  • I think splitting this article will be a disaster. IPv6 should come under one big embodiment and not be split up. This will help in research as people will see everything in one single space. If you anyone doesn't need it, then he/ she skips to what he or she needs. Secondly someone will have to know everything on what he/she is researching to find articles like this one (IPv6 Transition). I stumbled on this article which actually is the reason for the research but did not know and what to look for. I will be one of the many who will have a splitting problem.--Tony Klah —Preceding unsigned comment added by 196.201.34.165 (talk) 08:44, 26 May 2008 (UTC)
• Oppose There should only be one article for this. SMakabwe (talk) 20:50, 31 May 2008 (UTC)
• Oppose. I believe that I am the main author of this article.--Jec (talk) 18:07, 1 June 2008 (UTC)

Can you please explain why you oppose in a way that doesn't violate WP:OWN? Wrs1864 (talk) 19:01, 1 June 2008 (UTC)

Huh? In no way did I claim ownership, I just mentioned that I am not a random onlooker. The article is carefully structured: what is it, do people use it, what are those funny things with colons I keep seeing, how does it work, how do we get there. The proposed split broke this structure.--Jec (talk) 23:57, 2 June 2008 (UTC)

While you didn't claim ownership, you also didn't give any reason either. I don't see any reason why the simple questions can continue to be answered as per WP:SUMMARY. It also appears that not everyone agrees that the the article is carefully structured. Wrs1864 (talk) 11:58, 3 June 2008 (UTC)

• Oppose at this time. A lot of the article consists of blocks of the form "Heading .. one or two sentences", which are causing the article to appear longer than it needs to be. We should attempt to condense these and examine the results before any split happens. Andareed (talk) 22:15, 1 June 2008 (UTC)
• Copyediting is what this article needs. Template added.--Kozuch (talk) 10:06, 10 June 2008 (UTC)

Simpler processing by routers?

Due to the fact that CRC checksums are trivial to perform on network streams and are performed in hardware, I would assert that removing certain checksums would not improve speeds. Motoma (talk) 21:50, 20 July 2008 (UTC)

well, I think you are approximately correct, I just rewrote some other parts of the article that make rather misleading statements as well. Perhaps this should be rephrased into a paragraph that less state in the network has proven to be a very successful concept, according to Cyclades and Internet. Kbrose (talk) 23:09, 20 July 2008 (UTC)

I have rephrased the paragraph. Please check if you agree or have other suggestions. Kbrose (talk) 23:22, 20 July 2008 (UTC)

Practically no modern network app supports IPv6?

I removed the following from the article:

“ Despite this core design, development, deployment, promotion and encouragement work, practically no modern network aware applications have been adapted to use IPV6. ”

I can't see how this is true. LOTS of application on my Linux server can be compiled with IPv6 support that seems to be working great. I'd say it's a majority of them, actually, which to me is pretty far from "practically no[ne]"... Aeluwas (talk) 08:46, 3 July 2008 (UTC)

section about IPv6-only clients mentions IPv4-NAT, what a hell is that? link is needed —Preceding unsigned comment added by 194.44.21.57 (talk) 16:18, 24 July 2008 (UTC)

IPv6 deployment

I separated this lengthy and disorganized section into a separate article, see IPv6 deployment, which is only going to get longer as people deploy IPv6 around the world. Here we should only keep the MAJOR deployment events or developments, currently perhaps only the Olympics, which does appear as a significant IPv6 event. Perhaps the section here can also be better used to write about special (technical) deployment methods which are not covered by transition technologies. Kbrose (talk) 02:59, 5 August 2008 (UTC)

IPv6 and privacy

The article should mention privacy issues in IPv6 such as this one:

By default, IPv6 stateless autoconfiguration creates a 64 bit hostid for each interface based on the mac address [...] There is a privacy issue with this however, because this identifier is created in such a way as to make it globally unique, the machine (and therefore in almost all cases the user) can be tracked by third parties such as web sites, even if they move from one network prefix to another, such as with a laptop.[1]

pgr94 (talk) 13:01, 2 September 2008 (UTC)

IPv6 ranges

What will ranges look like in IPv6? Like someone on dialup disconnects and reconnects and they get a different IP in the same range? I've read that IPv6 basically isn't doing it predictable like IPv4 but that the part that changes for range is sometimes near the beginning and sometimes near the end. William Ortiz (talk) 05:05, 7 September 2008 (UTC)

See here Internet Protocol Version 6 Address Space and here IPv6#Special addresses. --Kgfleischmann (talk) 06:17, 7 September 2008 (UTC)

Pretty confusing, especially the first link. William Ortiz (talk) 14:09, 7 September 2008 (UTC)

Well, the first link is no tutorial, but the authoritative source for the ranges. The second is free to be improved. --Kgfleischmann (talk) 15:57, 7 September 2008 (UTC)

Major cleanup

Over the last months, a number of people have added extra information to the features section, which has become way too long.

A case in point is the addition of information about flow identifiers, which are currently not defined in IPv6 (they are sent as 0, and ignored upon reception).

None of this stuff belongs in the features section, and I'm removing it. If people believe they should be in the article, please add a new section in the article body, not in the background section. Jec (talk) 17:08, 14 September 2008 (UTC)

Addition of books

Hello, as the proud author of the following book, I would like to ask an addition of the following:

Jun-ichiro itojun Hagino, "IPv6 network programmning"

• JP edition: translation by Ayako Ogawa, ISBN 4-7561-4236-2, http://www.ascii.co.jp/books/books/detail/4-7561-4236-2.shtml, Feb 2003
• EN edition: ISBN 1-55558-318-0, Oct 2004
• TW edition: ISBN 957-527-727-9, http://www.drmaster.com.tw/info.asp?NO=PG20170, Aug 2004

for more info, see http://www.itojun.org/book.j.html. tnx!

itojun

Sorry no original research.. now fuck off123.255.38.129 (talk) 01:53, 24 October 2008 (UTC)

IPv6 only hosts linked from this page

http://www.ipv6.bieringer.de got removed from the page, it is linked as the IPv6 Calculator page. This page shows one some information about ones IPv6 address. As it is an IPv6-only host (only a AAAA record, no A record) it cannot be reached over IPv4. It indeed thus won't work when you don't have IPv4 connectivity. But it *does* work when you have IPv6 connectivity. One can verify this when having only IPv4 connectivity by going to: http://www.ipv6.bieringer.de.ipv4.sixxs.org this is the URL which passes through the IPv6 Gateway and allows one to view IPv6 only sites with IPv4 only connectivity or IPv4 only sites when having IPv6 only ;) Discriminating IPv6 because you can't reach the site from IPv4 is a bit ehmm weird ;)

Thus: don't remove sites which link to IPv6 only resources unless you have a really deeply argumented reason.

!!!*DON'T* add ipnow.org, it doesn't even have an IPv6 address!!!

$ host -t aaaa www.ipnow.org www.ipnow.org CNAME ipnow.org $ host -t aaaa ipnow.org ipnow.org AAAA record currently not present

Thus it will *NEVER* be able to tell what the IPv6 address of the client is!

People adding it should be marked as vandalism IMHO.

confused over dialogue on "IPv6 only hosts linked from this page"

It is hard to know who is saying what above; no signatures? no date stamps?

I am also wondering whether or not it would be useful to mention the Internet of Things which needs IPv6? Perhaps it would be nice to use it to soften the introduction to the article? --Михал Орела (talk) 06:23, 11 November 2008 (UTC)

Keeping URL references up to date?

I have just checked the footnote reference for IPv6 deployment for Mac OS X v10.3. The external link gives "document not found error". This is now formally noted.

noted *** Document not found error message *** 2008-11-14 for Mac OS X v10.3

This is a general problem when linking to OS release documents?--Михал Орела (talk) 03:19, 14 November 2008 (UTC)

Syntax /xx unclear

The meaning of the slash followed by numbers was not exactly clear to me when i read the article. I mean the following entries towards the bottom of the article, such as:

::/128,  ::1/128, fe80::/10, etc.

I think it means something like total length in bits together with the implied zeroes, but I have not seen this notation before and it would be nice if the article gave a hint what it meant. Other than that, the article was very helpful, thanks!

Update: This has now been clarified in the article, thank you very much to whoever changed this!

Answer

The number after the slash is the number of bits that are required to remain constant in a grouping (or subnetting) operation. It's not an IPV6 only aspect: 10.1.2.0/24 is like 10.1.2.0 with a subnet mask of 255.255.255.0 (24 = 3*8)

something/128 means "just this address" (just like /32 or 255.255.255.255 in IPV4) fe80::/10 means "every 128 bit number whose first ten bits are the same as the first ten bits in "fe80" - "1111-1110-10"

/128 means "the address made by all zeroes"

1/128 means "the address made by all zeroes except 1 as rightmost bit" —Preceding unsigned comment added by 146.48.99.74 (talk) 13:36, 11 December 2008 (UTC)

DNS root wording

Kbrose - this is the second time you have reverted my wording. I think you are mistaken. It has been possible for two hosts to "fully communicate" over IPv6 for over a decade. Adding IPv6 to the DNS root is orthogonal to that. —Preceding unsigned comment added by 128.118.27.75 (talk) 17:45, 15 December 2008 (UTC)

I think the phrase "fully communicate" is somewhat ambiguous. While technically it is true that you could communicate without using DNS lookups, DNS is a pretty key part of what the average user sees as "the internet". I think we should avoid splitting hairs or belaboring this point too much, I would say the wording with "fully communicate" is better. Wrs1864 (talk) 17:52, 15 December 2008 (UTC)

The whole purpose of the entry in the table is to state that DNS was the last missing piece to "fully communicate" without technical tricks. I didn't originally write the phrase, but it is the phrase used in the referenced announcement, and it is more fitting than yours, since it is already stated that DNS is now functional (at least for some domains). This paragraph is not the place to debate technical details of what is required for communications, and the statement simply augments the AAAA records addition with an explanation of the potential benefit to non-expert users. Your changes only reiterate the obvious, namely that IPv6 DNS is in place. Kbrose (talk) 18:51, 15 December 2008 (UTC)

I've changed the wording to what I feel is a compromise between your two positions. Not native speaker, please review, etc. --Jec (talk) 02:46, 16 December 2008 (UTC)

Depending on one's definition, DNS isn't the last piece to "fully communicate" over IPv6; you also need stable routing, non-broken pMTU discovery, etc. DNS is an important piece, but not the final one. Further, the wording implies that it was not possible for two hosts to communicate over IPv6 prior to 4 Feb 2008, which is not true. The phrase "fully communicate" does not appear in the IANA annnouncement, only in Iljitsch van Beijnum's article. —Preceding unsigned comment added by DerekMorr (talk • contribs) 21:01, 15 December 2008 (UTC)

Problems with routers not handling packets (can you say "ECN"?), broken routes and such will always exist, just like they do for IPv4. I do not read that sentence as saying that you could not communicate at all. Like kbrose, I didn't not originally write the sentence, but I don't see anything worth changing about it. Wrs1864 (talk) 21:19, 15 December 2008 (UTC)

*Sigh* I see I'm not going to get anywhere with this, and I have no doubt that the two of you will revert any further changes I make. I still maintain that "fully communicate" is wrong and misleading. DerekMorr (talk) 22:14, 15 December 2008 (UTC)

And I rest my case. I'm curious, though, Kbrose -- who appointed you guardian of this page and of "common sense" ? —Preceding unsigned comment added by DerekMorr (talk • contribs) 13:23, 16 December 2008 (UTC)

Address space information should be moved to "2.1 Larger address space"

Seeing as the last 3 paragraphs of the information in the intro have to do with the address space, shouldn't it be put into section 2.1 - "Larger address space". Do I have a point, or should these be kept in the intro because thats the sort of information people want to see right away? ETSkinner (talk) 19:48, 29 November 2008 (UTC)

It definitely needs reworking, people are obsessed with the large address space and can't get enough of the number comparisons it seems, never mind how meaningless they may be and despite the fact that the large space is only one of the design considerations of IPv6, and the actual allocation space is only 64 bits large at best. There are more interesting things to put into the lede. Kbrose (talk) 20:17, 29 November 2008 (UTC)

I've been removing this crap for two years now, but people keep adding it in again. Feel free to try, I'm fed up.--Jec (talk) 02:47, 16 December 2008 (UTC)

Moved most of it to features section, but kept the summary statement of the fact. Kbrose (talk) 18:21, 19 December 2008 (UTC)