Talk:IPv6/Archives/2010

DNS Section has disappeared

The section on DNS has been moved to the "IPv6 address" topic. It might be good to note this here, or maybe even have a redirect for "IPv6 DNS" to the "IPv6 Address" topic. Currently, it is easy to miss where this section went to. Artiseamer (talk) 00:30, 29 January 2010 (UTC)

Done Jec (talk) 09:53, 1 February 2010 (UTC)

Transition Technologies and Implementations

Would it be worth listing some of the implementations of transition technologies on the page? For example Miredo ( http://www.remlab.net/miredo/ ) is an open source implementation of Microsoft's Teredo specification.—Preceding unsigned comment added by Ajmas (talk • contribs) 18:53, 28 June 2007

There's already too many links on this page (please prune!). And there's already a link to Teredo, where you'll find a link to Miredo. —Preceding unsigned comment added by Jec (talk • contribs) 23:28, 12 July 2007

I think it's a worthy mention, however in the text it may be worth mentioning in a simplified manner such as: "Teredo and it's open source alternative Miredo." Additionally, I would simply put Miredo as appended to the Teredo internal Wikipedia cross-reference line at the bottom of the page. Robert Wm "Ruedii" (talk) 19:58, 19 February 2010 (UTC)

Nack. Miredo is just one implementation of a public protocol (Teredo). It's notable since it's AFAIK the only non-Microsoft implementation, but it doesn't belong in this page.Jec (talk) 05:43, 2 March 2010 (UTC)

Number of IPv6 addresses per an IPv4 address in IPv4 to IPv6 conversion

It is not currently mentioned how many IPv6 addresses are allocated per a converted IPv4 address. I know this is a trivial matter, but as such it is worth a trivial mention. I'd calculate it out myself from the draft data, but my brain is foggy today, so if an expert could append in a line with the exact number, not counting the standard ipv6 broadcast addresses (for which you would say plus the reserved addresses for broadcast.) I'm sorry I couldn't do it myself, and just put up a request. Robert Wm "Ruedii" (talk) 20:03, 19 February 2010 (UTC)

Not sure what you are looking for, there is no such concept. There is no mapping from IPv4 to IPv6, the two are not interoperable without special transition technologies. Furthermore, there are no broadcast addresses in IPv6 either. Kbrose (talk) 20:26, 19 February 2010 (UTC)

Fault injection advertisement

Suggest removing the fault injection section.Jec (talk) 05:48, 2 March 2010 (UTC)

Definitely reads as an ad to me, and adds essentially nothing to the article. +1 for deletion. Groxx (talk) 16:26, 4 May 2010 (UTC)

Adoption Issues

This section is way too verbose for this article. I'm hesitating between making a radical summary of it (as in two or three paragraphs at most) or removing it altogether.Jec (talk) 05:52, 2 March 2010 (UTC)

The only relevant notion in this piece of text, in my opinion, is that adoption urgence is small in most areas and that much work has to be done to make IPv6 reach everywhere. There is seemingly no dire need to switch and no IPv6 killer app; it may make the transition painful if postponed too long. This hesitation to fully embrace IPv6 and convince consumers they will want this is not addressed elsewhere in the article, so to delete it would be wasteful. The section could use some firm trimming and pruning to make it readable again, though. —— _D^an_d^or ⁱ_D (talk) 20:06, 7 March 2010 (UTC)

Reference [30] doesnot imply Linux ipv6 primacy

Reference [30] on ipv6 page, namely, http://www.linux-ipv6.org/stable-6-ann.html, incorrectly purports to suggest that Linux in 1996 had alpha quality IPv6. This is not backed by any data, implicit or explicit as evidenced from Reference [30]. Consequently, i'd like to suggest deleting the row entry as it serves no factual purpose other than to create a false impression that Linux was the first to have ip6 stack. Saifikhan (talk) 05:50, 27 June 2010 (UTC)

Speculation as fact/data

Just reading this paragraph-

"Most equipment would be fully IPv6 capable with a software/firmware update if the device has sufficient code and data space to support the additional protocol stack. However, as with 64-bit Windows and Wi-Fi Protected Access support, manufacturers are likely to try to save on development costs for hardware which they no longer sell, and to try to get more sales from new "IPv6-ready" equipment. Even when chipset makers develop new drivers for their chipsets, device manufacturers might not pass these on to the consumers. Moreover, as IPv6 gets implemented, optional features might become important, such as IPv6 mobile."

I don't believe it; not because of my personal standpoint, but because 60% of this is neither true nor likely.

Firstly, commercial manufactures never have and never will make any attempt to reduce costs by implementing new standards without overwhelming incentives. Secondly, two thirds or more of the paragraph is in the conditional tense and the subject is nit hypothetical. IPv6 is a reality both tested and proven. 126.244.149.73 (talk) 14:27, 5 May 2010 (UTC)

I think you have misread the paragraph (which might argue for a rewrite). The "reduce costs" remark means "manufacturers won't bother retrofitting old gear," which it sounds to me as if you would agree with. But I agree that we need more facts, or at least more-authoritative speculation, in this area. A start, but "only a blog," might be http://www.readwriteweb.com/archives/the_internets_running_out_of_room.php. Jackrepenning (talk) 17:47, 28 July 2010 (UTC)

Criticism section?

Should this be added. See, for example. http://gerald-duck.livejournal.com/507801.html

This is just a blog. Randy Bush made some comments concerning the deployment of IPv6 that could be incorporated in the article, see http://www.iepg.org/2007-07-ietf69/070722.v6-op-reality.pdf (it has also been presented to RIPE meetings a.o.). Mro (talk) 04:52, 27 July 2010 (UTC)

IPV6 and Business Prospective

looking for some business prospectives of ipv6 —Preceding unsigned comment added by 62.30.139.210 (talk) 17:09, 8 August 2010 (UTC)

Mobile IPv6 efficiency

The following statement, "Unlike mobile IPv4, mobile IPv6 avoids triangular routing and is therefore as efficient as native IPv6", is so authoritative that it's requoted in the Mobile IPv6 page, sourced here, but (according to other Wikipedia pages) it's not actually true - mobile IPv6 connections are from external point -> home -> mobile connection (a triangular route) with a return as mobile connection -> external point (not triangular). So, if that's true, they avoid *some* triangular routing and they're clearly not as efficient as a normal connection. I'd prefer an expert agreed with this before changing the article, however, I'm just observing issues of consistency here. --64.103.25.233 (talk) 10:12, 30 September 2010 (UTC)

Nowhere is there any explanation of flow label use/application?

n/t —Preceding unsigned comment added by 169.234.5.37 (talk) 22:40, 22 October 2010 (UTC)

abuse / hacking / spoofing / Denial of Service?

What happens if an existing address is intentionally duplicated by some other device? Let's say an attacker pings all the hosts of a target, and then assigns those same addresses to their own devices. How do the routers know which one is the real address?

There needs to be a section discussing these security issues and how they compare to IPv4. DMahalko (talk) 16:17, 12 October 2010 (UTC)

Just pinging all hosts is not feasable in IPv6 due to the sheer amount of possible addresses. For known addresses and their possible (ab)use see IPv6 address#Stateless address autoconfiguration. —— _D^an_d^or ⁱ_D (talk) 20:31, 8 November 2010 (UTC)

Unreliable?

"IPv6 is an Internet Layer protocol for packet-switched internetworking and provides an unreliable end-to-end datagram delivery service."

Really do think this is supposed to be "reliable end-to-end datagram delivery service." —Preceding unsigned comment added by 205.156.36.16 (talk) 12:38, 2 December 2010 (UTC)

The technical term "unreliable" is used in the sense that delivery of the datagram is not guaranteed. The sender may not rely on the recipient getting the packet. The sentence is confusing to non-technical readers, so it could be clarified. Glrx (talk) 16:04, 2 December 2010 (UTC)

Glrx is correct: the delivery of an IP6 packet (or an IP4 packet, for that matter), is *not* guaranteed, and the packet may be lost, delivered out of order (IOW the sender can send A, then B, and the receiver get A first, then B), and duplicated (so the receiver may get more than one copy of the sent packet), or various combinations thereof, all without any indication that an error has occurred. If you're application cares about any of those sorts of failures, it must provide some way of dealing with them, as IP does *not*. TCP, as a protocol built on top of IP4/6, adds reliability (probably its major feature), by adding various checks, sequencing indications and retransmissions as necessary. UDP, which is a application-level data-gram protocol build directly on top of IP4/6, also is unreliable in the technical sense. Rwessel (talk) 19:52, 2 December 2010 (UTC)