Talk:IPv6/Archives/2008

From Wikipedia, the free encyclopedia

Archive This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents

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)