Talk:IPv6

Wikipedia IPv6 enabled

(There was only a pre-existing heading here and no text or comments. My note here was in response to the heading.) Note that while the web servers for www.wikipedia.org have IPv6 addresses, it seems that the authoritative DNS servers do NOT have IPv6 addresses. This means someone on an IPv6-only network would not be able to look up the addresses to connect to Wikipedia. I noticed this when www.wikipedia.org failed the Internet.nl website test for IPv6. I do not know who to report this to or how to make that report. - Dyork (talk) 01:29, 8 March 2020 (UTC)

Try WP:VPT. Johnuniq (talk) 02:05, 8 March 2020 (UTC)

 Done(in terms of the issue being reported) Thank you for that suggestion. I have noted the issue there. - Dyork (talk) 02:36, 8 March 2020 (UTC)

• @Dyork and Johnuniq: phabricator:T81605 Long story short is, the Foundation wishes to first get IPv4 DNS on anycast, then get IPv6 support ready. This inherently gets around the problem of DNS geolocation databases. The great majority of caching DNS servers are able to essentially act as proxies for IPv6-only clients to do lookups.--Jasper Deng (talk) 02:37, 8 March 2020 (UTC)

@Jasper Deng: Ah, that makes sense. Thank you for the explanation. - Dyork (talk) 03:08, 8 March 2020 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on IPv6. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20090904062229/http://www.cablemodem.com/specifications/specifications20.html to http://www.cablemodem.com/specifications/specifications20.html
• Added archive https://web.archive.org/web/20090204051327/http://en.beijing2008.cn/news/official/preparation/n214384681.shtml to http://en.beijing2008.cn/news/official/preparation/n214384681.shtml
• Added archive https://web.archive.org/web/20131019144339/https://support.t-mobile.com/thread/27171 to http://support.t-mobile.com/thread/27171

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 01:35, 8 April 2017 (UTC)

fe80::/10 vs. fe80::/64

In this article the link-local address prefix is given as fe80::/10. Link-local_address says fe80::/64. Who is right? --RokerHRO (talk) 12:23, 28 July 2017 (UTC)

IANA has reserved fe80::/10 for link-local addresses (https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml) but the IPv6 implementation (RFC4291) only uses fe80::/64 out of that range. The change to Link-local_address was made by 178.250.166.134 in May 2017; the previous version went with IANA's /10 reservation. - Ttwaring (talk) 22:23, 28 July 2017 (UTC)

64 KiB

An edit on 26 February 2018 changed the start of IPv6#Jumbograms from

IPv4 limits packets to 65,535 (2¹⁶−1) octets of payload. An IPv6 node can optionally handle packets over this limit, referred to as jumbograms, which can be as large as 4,294,967,295 (2³²−1) octets.

to

IPv4 limits packets to 65,535 (2¹⁶−1) octets (64 KiB - 1 byte) of payload. An IPv6 node can optionally handle packets over this limit, referred to as jumbograms, which can be as large as 4,294,967,295 (2³²−1) octets (4 GiB - 1 byte).

I was asked about my revert on my talk. The edit introduces too many parentheticals. Also, anyone familiar with what KiB/GiB mean would not need the extra information. Johnuniq (talk) 00:10, 3 March 2018 (UTC)

As already mentioned on the user's talk page standardised prefixes for units were invented for a reason. Sure, one can do the mental math 2³² = 2³⁰⁺² = 2²x2³² = 4x2³⁰ but that's why gibi was defined as 2³⁰ so one doesn't need to do these calculations every time they come across a large number. One can write 4GiB and while reading not get lost in powers or unneccessary zeros/digits/decimals denoting powers/orders.

I agree the extra parenthesis in the edit are ugly. If anything we need to find a good/better way to express "less 1 byte/octet".

2001:569:79AE:3200:64B2:F010:5811:AFCB (talk) 20:46, 3 March 2018 (UTC)

I hope others join in but my feeling is that KiB/GiB is gibberish to all but a handful of techo types. However, if it were wanted, the way to say it might be in an additional sentence along the lines of "The payload for an IP packet therefore increases from almost 64 KiB using IPv4 to almost 4 GiB using IPv6." Hmm, "packet" is not right. That should be datagram. Johnuniq (talk) 22:29, 3 March 2018 (UTC)

I'm not a fan of binary kilo/giga either but we can't write 64KB or 4GB because it's technically incorrect eventhough all computer people would know what is meant by that. My point was that these bulk transfers will be used to transmit chunks of data (streamed video/audio, boot images, ...) and file sizes are normally given with prefix notation ("My JPG picture is 255KB big" - not "My JPG picture is almost 2¹⁸ octets big").

I don't have a problem with the suggested additional sentence mentioning KiB/GiB. Another proposed wording: "The payload for an IP packet therefore increases from 64 KiB (less 1 byte) using IPv4 to 4 GiB (less 1 byte) using IPv6."

2001:569:79AE:3200:35C4:2CDF:990A:B0CA (talk) 09:40, 4 March 2018 (UTC)

I'd like to also point out this sentence in IPv6#Packet_format: "Without special options, a payload must be less than 64KB. With a Jumbo Payload option (in a Hop-By-Hop Options extension header), the payload must be less than 4 GB."

2001:569:79AE:3200:35C4:2CDF:990A:B0CA (talk) 06:21, 6 March 2018 (UTC)

• Support version without KiB and GiB. The two-to-the-n notation makes the 16-bit and 32-bit limits crystal clear; the KiB and GiB notations require conversion to make that clear despite the notation being precise. The Ki/GiB notation is also jarring. I dislike KiB notation in general. For current engineering purposes, the differences are small enough to be insignificant. Brickbats to the marketing guys at the disk drive manufacturers. Glrx (talk) 00:39, 4 March 2018 (UTC)

• Support version without KiB and GiB - I have seen previous consensus that these binary units, for the reasons Johnuniq mentions at the outset here, are rarely helpful in the context of Wikipedia articles. It's a shame since they are a more concise representation in cases like this but we can't assume enough reader familiarity for them to stand alone. ~Kvng (talk) 13:30, 5 June 2019 (UTC)

prefix delegation

As I understand it, Comcast delegates /60 for home users (that would be WP:OR as my home network works this way), and /56 for business users. (This is easier to find in Comcast documentation.) If someone can find an actual WP:RS (I looked but couldn't find one), it would be nice to add. Also, for other ISPs. Gah4 (talk) 09:18, 2 June 2019 (UTC)

Laudable removal of unsourced information

Well done: Special:Diff/903991159/906389147

~ ToBeFree (talk) 15:24, 15 July 2019 (UTC)

Address Space Size

The article states 7.9×10^28 times the IPv4 allocation but also claims that this number differs from the 2^128 theoretical address space because much of the space is reserved. These numbers don't seem to add up. The first number is approximately 2^96. IPv4 has an allocation of 2^32 (also less reserved numbers). 2^96 times the size of 2^32 = 2^128, so this number is saying nothing different to the 2^128 claim.

If the claim is meant to read that total global unicast routing is 2^96 addresses, that would be in line with current allocation, more or less, but is not the total available as the allocation was larger before and could be again. RFC 3513 allocates the whole of 2000::/3 to unicast addressing, although this was later obsoleted by RFC 4291. Yet RFC 4291 does not clearly bring us to 2⁹⁶, nor does it prevent the allocation expanding again in the future, so it is not clear to me what we are counting here.

Also does this even belong in the lead? The lead needs to be a short summary of the article. Numbers can be discussed in the article but this number does not summarise anything obvious. I would just delete it, but it may be I am missing something here. -- Sirfurboy (talk) 17:45, 31 December 2019 (UTC)

Agreed. That sentence can be deleted. Ttwaring (talk) 18:40, 31 December 2019 (UTC)

 Done Noting for anyone else reviewing this talk page that Sirfurboy made this change in January 2020. (For what it’s worth, I think it was a good change.) - Dyork (talk) 01:16, 8 March 2020 (UTC)

Someone said ...

In 1970-s, when IPv4 was developed, the population of Earth was 4 billions (it became twice more during previous 50 years). Developers of IPv4 must understand that 4 billions of addresses will not be enough for every host on the planet. Short 32-bit address was chosen with intention of future implementation of NAT and private networks. Short 32-bit address makes NAT and private networks necessary. That is the goal of short 32-bit address. Long 128-bit address eliminates this. Gah4 (talk) 21:59, 30 March 2020 (UTC)

I believe the above is not historically correct. When IP was developed, computers were expensive. I suppose the designers should have seen what might happen, and planned ahead for it, but they didn't. At that time, many machines used (at least) 32 bit words, or some used 16 bit words but could do 32 bit arithmetic in two operations. It was a convenient size. One example of how much they didn't plan is allocating a whole class A network, 127/8, for the loopback address. Initially, there were only three classes, with /8, /16, and /24 nets, not quite optimal for the existing sized organizations. Gah4 (talk) 22:06, 30 March 2020 (UTC)

So, why did you remove entire chapter? Why not only this paragraph? Why did you remove IPv6 image? May I come back another paragraphs? If you don't ground removing. Acbaile5 (talk) 22:10, 30 March 2020 (UTC)