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)

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 this paragraph only? Why did you remove IPv6 image? May I come back another paragraphs? If you don't justify removing. Acbaile5 (talk) 22:10, 30 March 2020 (UTC)

I will explain the same more academically. OK? Acbaile5 (talk) 22:15, 30 March 2020 (UTC)

I copied that one, as I think with some changes it could be used. NAT and private networks are a different question. Private networks first came when people (usually companies) had networks not connected, and not planned to connect, to the internet (rest of the world). They still needed IP addresses, so some were assigned. At some point, the idea of NAT, firewall, and private networks came together to satisfy keeping networks safe, and the shortage of public IP addresses, at about the same time. Even with IPv6, it is probably best to have a firewall to allow only appropriate traffic through. Gah4 (talk) 22:30, 30 March 2020 (UTC)

When IPv4 started in 1983, very few computers were on the net. It spread fairly fast to academic institutions, but even so maybe one or two hosts per department, mostly for mail. (Previously, mail was done through UUCP and dial-up phone lines.) Early on, much of the internet was 64k bit/s links, good for mail, and small file transfer. PCs with 16K RAM were popular, but not much thought to connecting them to the world, though maybe to a small local (small i) internet. (Now usually named intranet.) If you want to research the development of IPv4, ARPAnet, NSFnet, through to the public (not government run) Internet, and then to IPv6, that would be nice. Gah4 (talk) 22:30, 30 March 2020 (UTC)

Oh, I found this one indicating what one might call a computer in 1983. But more usual were VAX and such. Gah4 (talk) 22:30, 30 March 2020 (UTC)

Word "NAT" has sound similar to "NOT!!" with two exclamations. It looks like the sense of this technology: the men don't accept totally opened network. So, private networks must exist, and must be transparent inside particular network only. Acbaile5 (talk) 22:38, 30 March 2020 (UTC)

I added first paragraph that touches possible IPv6 danger only. I tried to write academically. Acbaile5 (talk) 22:34, 30 March 2020 (UTC)

Some centuries ago cheap books appeared. Now we don't burn these books like Library of Alexandria. Men simply publish a lot of fiction books, so it becomes really hard to find some book with true. Doesn't Google resolve analogic problem with Internet?

Why do I like global Internet? At first, because of global safety. Transparent world is much more safer then a set of closed communities. I don't like Ares, I don't like war. I understand that men need control and usually like blindness, but absence of war is principal moment. I accept existence of lying Google. Every smartphone is a PRESS on your mind - simply open any web page - and a stream of lie will come into your eyes, where ever you are. Isn't it using of Internet for men benefits? Now you want simply press without safety? Acbaile5 (talk) 23:32, 30 March 2020 (UTC)

@Acbaile5: You can write all you want about the internet being a "press" but unless and until you demonstrate the existence of reliable sources espousing this exact view, it's not suitable for Wikipedia. I strongly agree with the removal of both of your additions because besides the numerous grammar errors in them, they are woefully incorrect, and only go to show how ill-informed you are (this is why we must use reliable sources. Even someone with a degree in computer science like me cannot substitute his opinions for what reliable sources have written). For starters, NAT has not proven to be a deterrent to the assembly of global botnets and that problem will not be made worse by the removal of NAT. NAT is also not a "social" thing (that is absolutely not the meaning of a private network, nor will IPv6 mean the complete end of the use of local addresses). There's also no evidence whatsoever to suggest IPv6 will be the end of the client-server model (except perhaps for things explicitly intended for NAT traversal like Hamachi (software)). We are not here to WP:RIGHTGREATWRONGS and per WP:NOTAFORUM, please don't pursue this any further unless and until you provide reliable sources supporting your view.--Jasper Deng (talk) 23:46, 30 March 2020 (UTC)

NAT was convenient in that it provides some isolation without much complication in configuring, especially for the usual home network with only outbound connections. Except that some home uses, such as VoIP need to cross the NAT. However, a firewall is a much better solution than NAT. Personally, I run a unix-like machine with three ports, for two house subnets, including IPv6 routing. I don't know what more usual home routers do as far as IPv6. The use of private (not connected to the Internet) IPv6 networks would be a useful addition to the article. Gah4 (talk) 01:21, 31 March 2020 (UTC)

I don't think many folks are actually making use of the private IPv6 addresses. I know for sure that the WMF is using public IPv6 addresses for servers with private IPv4 addresses. Leslie Carr once told me that IPv6 can be just as secure as IPv4 NAT with appropriate firewalling. But it's been a while since I've checked out books on this subject. There might be some coverage now.--Jasper Deng (talk) 02:41, 31 March 2020 (UTC)

Well the might be, but not telling anyone about them. That is the whole advantage of a private net. In IPv4 days, I was working with someone installing our (expensive) product in some company. One part of installation is sending some configuration data outside. It seems that this company had no way to get e-mail out, so it had to be faxed. (Well, maybe 20 years ago.) It is said that election processing systems are not connected to the Internet, though likely internally networked. But then again, IPv4 is probably fine. Gah4 (talk) 05:25, 31 March 2020 (UTC)

The only way to find out is to see if sources report on it, though. A good resource would be a handbook like the For Dummies series on practical networking.--Jasper Deng (talk) 06:27, 31 March 2020 (UTC)

@Jasper Deng: No, it looks like intention to hide the potential danger of IPv6 from Wiki readers. You simply don't want that people see any idea about it, that's why you eliminate it from Wikipedia. It is not justifying, it is censorship.

Grammar errors are present because English is not my native language. You may correct grammar errors. But I don't see technical errors.

"woefully incorrect", "ill-informed" — :) Sorry, it is not technical justifying. It looks like eliminating of inconvenient thoughts, far away from eyes.

Removing of NAT is distant target of IPv6. We will not see it, but our descendants will see it. IPv6 is intentional building of broken bridge. It will collapse. When a lot of users will have absolutely freedom of communication in IPv6 - it will collapse. Private networks and NATs in IPv4 deter absolutely freedom of communication. But nothing will deter this freedom if everybody will have globally routed address. Long 128-bit address of IPv6 is the goal of this absolutely freedom. The problem has social nature. Men want to control. Absolutely freedom of communications in IPv6 removes the possibility of control. Consequence: men are angry, men want to destroy IPv6. IPv6 provokes this conflict. This conflict will appear in future. IPv6 is intentional weapon of this conflict. IPv6 is built for it.

IPv4 gives possibilities of control. But, it looks, that is not enough for you. It looks you want to eliminate possibility to say opinion free in Internet. It seems, it's too much freedom for you.

Server is necessary when private networks exist, when clients can not establish connections directly. Server is one point where user's activities are concentrated. It is much more simpler to watch and control one certain point instead of any number of unpredictable points in absolutely transparent network. Server becomes unnecessary when clients can establish connections directly. Men will not be able to watch and control these direct connections. That is the reason why men will want to destroy this freedom of communications.

Acbaile5 (talk) 13:20, 31 March 2020 (UTC)

@Gah4: "NAT was convenient..." — That does not explain why NAT does not give possibility to know which port number is assigned to your request when translation takes place. It's done to eliminate the possibility to establish incoming connections to the clients in private networks. It must stay. Private networks must stay semi-closed.

"However, a firewall is a much better solution than NAT" — You offer the same freedom. Of course, firewalls will exist in IPv6, network can not be fully opened. But users will be able to open any necessary port. That will give absolutely freedom of communications that NAT deters.

Acbaile5 (talk) 13:31, 31 March 2020 (UTC)

@Jasper Deng:"... IPv6 can be just as secure as IPv4 NAT with appropriate firewalling" — Yes, of course, it can be, but it will not be :) . Because of the opposite intention. Appearing of IPv6 is not accident. IPv6 is intended for destroying the globality of Internet. So, I don't believe that IPv6 will be used accurately. Generations will change, and our descendants will see collapse of global network.

You still did not explain why you removed nice image of IPv6 like time bomb. It seems you understand what this picture means.

It seems, we need some community against IPv6 - to have right to imprint the danger of IPv6 into the wiki, for our descendants.

Acbaile5 (talk) 13:44, 31 March 2020 (UTC)