Talk:IPv6/Archives/2013

Similarity to universally unique identifiers (UUIDs)

The main advantage of IPv6 over IPv4 is its larger address space. The length of an IPv6 address is 128 bits, compared to 32 bits in IPv4. The address space therefore has 2¹²⁸ or approximately 3.4×10³⁸ addresses, an equivalent length to that of universally unique identifiers (UUIDs).

Comments? Preceding comment added by User: 71.135.167.98 18:26 UTC, 30 December 2012 - tag by rwessel

Other than a coincidence between the sizes of the items, there's no real relationship. 128 bits is a nice even size, so lots of stuff ends up there that needs to be more than 64 bits (but not needing more than 128). 64 bits is clearly not enough for a GUID - the difficulty of creating collisions is related to square root of the number of IDs, and a 64 bit GUID would be expected to have collisions after only 2**32 IDs had been generated. OTOH, 64 bits would likely have been enough for IPv6 (and in fact it was a near run thing - the factions were about half for 64 bits and half for 128), but in the interest of agreement, many of the pro-64-bit folks agreed to 128 bits, despite the extra bandwidth overhead that imposed (and 128 bits had some advantages in areas like autoconfiguration). Nor is the comparison a useful analogy, since the size of the address space of GUIDs is not something that's meaningful to anyone. Rwessel (talk) 01:03, 31 December 2012 (UTC)

Why not 96 bits? That would have been the perfect compromise.--71.135.167.98 (talk) 05:37, 2 January 2013 (UTC)

I'm sure everyone would have hated an irregular size like that. While it would be OK for 32 bit systems, it's clearly a pain for 64 bit systems. Note that alignment of header fields was considered important for performance (and a noteworthy complaint about OSI), and a 96 bit address would have been difficult to pack well into the header. Rwessel (talk) 08:41, 2 January 2013 (UTC)

Mobile IPv6 conflicting information

On this page under Mobile IPv6: Unlike mobile IPv4, mobile IPv6 avoids triangular routing

On http://en.wikipedia.org/wiki/Mobile_IPv6 under Operational principles: When acting as transmitter, a mobile node sends packets directly to the other communicating node, without sending the packets through the home agent, using its permanent home address as the source address for the IP packets. This is known as triangular routing.

I don't know which page is correct, but I suspect one of them should be changed.

Thanks. Krolaw (talk) 09:57, 15 January 2013 (UTC)

Condense tag removed

While a few of the sections are very short, I don’t really think turning them into bullet points would be helpful, as the short ones are mixed in with the long ones. And in general these all seem to represent topics worthy of setting off (and many link to more specific articles). So basically I don’t see a problem. Accordingly, I am removing the condense tag. Rwessel (talk) 05:56, 21 February 2013 (UTC)

Privacy Extensions

Are PEX in Android 4 enabled by default? If so, we should update the text.Seasack (talk) 09:30, 3 July 2013 (UTC)

Low uptake - reasons?

Article should perhaps give some reasons why IPv6 has such low market penetration, in spite of being two decades old. The overriding reason, AFAICS, is that IPv6 being a totally different and untried topology from IPv4 raises the prospect of numerous security holes being discovered and exploited, thus site admins are reluctant to expose their internal networks to what they see as an unnecessary risk.

The core of this problem stems from IPv6 being based on a fundamentally obsolete networking model, in which every personal computer accessing Internet services had to be visible to other Internet hosts as a fixed IP address in the global space. In 1992 when IPv6 was first proposed this was the way things worked, but developments since then have led to the standard LAN topology consisting of client computers which are invisible to the Internet, communucating via a NAT router and single externally-visible IP address. The latter is in fact a far better scheme from the POV of security, and a switch to IPv6 will effectively 'put the clock back' to the mid-90s as far as LAN security is concerned, with each IPv6 computer behaving, securitywise, as if it were on a dial-up modem connection.

The preinstallation of tunneling protocols on revent OS releases worsens this situation, by providing a potential bypass route (Through IPv4 and UDP) around any IPv6-aware firewall at the LAN bondary. Thus, even the installation of IPv6 boundary security hardware does not necessarily address the above concerns.

Another consequence of this outdated arrangement is that individual computer IP addresses will become the property of the ISP rather than the site itself, and thus a change of ISP may mean the need to renumber all computers on a site if fixed addressing is used. --Anteaus (talk) 07:23, 30 November 2013 (UTC)

Numerous inaccuracies in the above "Low uptake - reasons?" text, almost to the point of not being worth replying at all. 1) IPv6 uptake by ISPs is slow because ISPs don't need it as long as IPv4 is still available. 2) IPv6 uptake in general is slow because there's no distinguishing features/benefits over IPv4. 3) Your security comment doesn't reflect actual NAT implications to the security model, see RFC2993 for reality check and realize that if you want a firewall you should install a firewall. Feel free also to check out large scale end-user IPv6 deployments such as Comcast which provide the same security profile with dual IP4/IPv6 turned on. 4) Finally, IPv6 actually enables more organizational and end-user freedom from IP address lock-in, as they can get a very large direct assignment from their respective regional registry rather than being stuck behind one IPv4 IP in the service provider block. - TcomptonMA 21:00, 5 December 2013 (UTC) — Preceding unsigned comment added by TcomptonMA (talk • contribs)

Shadow Network

The article refers to shadow networks, but never defines what these are. All it says is that they arise, as if out of thin air -- is that what it means? It needs to be much clearer.68.190.23.42 (talk) 22:31, 23 December 2013 (UTC)

Agreed. Updated. Rwessel (talk) 09:30, 24 December 2013 (UTC)