Talk:IPv4

Clarify: Quintillion(Short Scale or long scale?)
The current text specifies a quintillion users to have a set of a quintillion adresses, this is ambiguous since both short scale 1018 or long scale 1030 could be meant. An unclear factor of 1012, if anyone knows how to recalculate the possibilites of addresses, please clarify this. --ananta 11:07, 26 February 2007 (UTC)
 * quintillion no longer appears in the article. ~Kvng (talk) 22:20, 10 August 2023 (UTC)

LS(R)R and SS(R)R
In the options area of the article there are two red links for LSRR and SSRR, an article exists for Loose Source Routing: Loose_Source_Routing

Some with more networking experience, should this be linked up? —Preceding unsigned comment added by 139.62.110.70 (talk) 19:24, 23 April 2008 (UTC)


 * These terms are no longer in the article. ~Kvng (talk) 22:20, 10 August 2023 (UTC)

Classful vs Classless
Under the 'addressing' section this page mentions classful networking as part of the addressing architecture redesign. This should be classless addressing not classful, as classful was part of the original standard. I didn't mess with it because it's linked, if someone wants to fix it. Also, 'Classful vs Classless' probably deserves its own heading, as the definitions are lumped under 'Allocations' which doesn't make a ton of sense (or it could just be linked off to the Classful Network page). —Preceding unsigned comment added by 174.44.144.200 (talk) 03:53, 25 February 2010 (UTC)


 * Classful appears to now be used properly in this section. ~Kvng (talk) 01:34, 25 November 2023 (UTC)

Addresses ending in 0 or 255 Revisited
The section on addresses ending in 0 or 255 is somewhat misleading, and much more complicated than necessary. The addressing rule is quite simple. You can't use the first address on a network because that's the network itself, and you can't use the last address on a network because that's the broadcast address. These addresses most often end in 0 or 255, but it isn't specific to Class C or /24 or any other network designation. You can't use the first and you can't use the last applies to all IP networks and subnetworks. Is it possible to get some consensus on a different rewrite of this section that addresses the general rule rather than working around specific cases? -- Dave Braunschweig (talk) 02:16, 4 December 2012 (UTC)


 * That section makes my head hurt. How about we gut it and rename it "Broadcasts" and include the information from RFC 1122 section 3.3.6 in the simplified manner you've suggested. -—Kvng 19:39, 6 December 2012 (UTC)


 * Completely agree. What's there now is more like "arcana you never needed to know". It should be titled "Network and broadcast addresses" or maybe "Reserved addresses" and express the rules in 1 or 2 simple sentences, max. PlaysWithLife (talk) 04:55, 23 January 2015 (UTC)


 * "networks with CIDR suffixes /24 to /32 (255.255.255.0–255.255.255.255) may not have an address ending in 0 or 255." That's not true for /31 (see RFC 3021) and /32. 2A00:8A60:1:F0:D5FB:B6AF:7404:9357 (talk) 07:20, 18 July 2018 (UTC)
 * The /31 exception is now mentioned. ~Kvng (talk) 01:41, 25 November 2023 (UTC)

Header Checksum
There is some confusion at IPv4. Two calculations are needed: The examples in the article do not make it clear which step is being performed. A recent edit replaced zero with the checksum in the "validate" step (good), but the "For example" first step uses a non-zero checksum. I don't have the energy to dig through the history and work out what happened at the moment so I'm just noting something is needed. Johnuniq (talk) 01:24, 22 October 2016 (UTC)
 * 1) The source and each router (when forwarding) need to calculate a new checksum using a header with the checksum replaced with zero.
 * 2) The destination and each router (on receiving) need to verify the existing checksum in the header. They do the checksum calculation and expect an answer of FFFF (zero after ones complement).


 * I have made some changes to make the statements in this section consistent with Internet checksum. ~Kvng (talk) 01:54, 25 November 2023 (UTC)
 * I have verified that Internet_checksum is itself consistent with RFC 1624 section 5 ~Kvng (talk) 20:46, 5 December 2023 (UTC)
 * Thanks. The current wording in this article is correct but a clarification is needed. The resulting sum will give 0xFFFF (if no errors) but that value is the same as zero in ones' complement which is what is being used. I can't find a good link but a fix to reduce the confusion would be to insert something like the underlined text in: A value of 0xFFFF (ones' complement zero) is expected. When the checksum is calculated (by the source or a forwarding router), the ones' complement of the sum is inserted in the header. When the check is made (by the destination or a receiving router), the software may or may not choose to ones' complement the result. The value will be 0xFFFF if that step is not performed, and zero if it is. Johnuniq (talk) 03:28, 6 December 2023 (UTC)
 * I agree that this is missing. In my opinion I'd even swap this around, since zero is the actual checksum value, if the checksum is correctly performed (the ones' complement is part of the checksum as far as I know). So the value should be zero if all steps are performed, and 0xFFFF if the devices calculates an incomplete result, so technically wrong. Cpiber (talk) 07:59, 6 December 2023 (UTC)
 * One other clarification: In one's complement representations, there are separate representations for 0 and a -0 (negative 0). 0xFFFF is -0. Calling something zero is ambiguous.
 * We should strive to keep all this gory detail in Internet checksum and summarized it briefly (and correctly) in this article. ~Kvng (talk) 15:34, 7 December 2023 (UTC)
 * Sorry for the late reply.
 * > Calling something zero is ambiguous.
 * No, it's not. zero is 0. negative zero is -0.
 * And I agree, details should be kept in the separate article. But then they should (1) agree and (2) the summary should either include enough detail to be correct or nothing at all. As mentioned in another post, the detailed article only mentions zero, as is expected. A value of 0xFFFF is not expected, unless the procedure is incomplete. Maybe all of these details should be in the detailed article, as you said (they aren't), and nothing should be in the overview except a link. Cpiber (talk) 08:26, 10 December 2023 (UTC)
 * Maybe not ambiguous to computer scientists but I think it is safe to assume that many readers have never heard of -0. ~Kvng (talk) 15:57, 10 December 2023 (UTC)

Phisher king notation.
I think this article could mention that IPv4 addresses can be expressed as a single large undotted number and some web browsers support that notation. It seems to be a popular trick with "phishing" spammers to camouflage the actual weblink target. E.g.: hxxp://1cmv5u@761244044/?&qrc=blahblah.com -->  hxxp://1cmv5u@45.95.169.140/?&qrc=blahblah.com (where 761244044 is the sum of powers for 140+169*256+95*256^2+45*256^3) 188.143.7.200 (talk) 10:30, 28 May 2023 (UTC)
 * It's briefly (or tangentially) mentioned as an example in the second paragraph of "Address representations". Mind  matrix  13:47, 28 May 2023 (UTC)
 * Briefly is a generous description. We need a citation to add more. I don't find documentation for this capability; this is the closest. ~Kvng (talk) 14:18, 31 May 2023 (UTC)
 * Back to the classful days, there are representations with zero, one, or two dots, in addition to the common three dots. They are designed after, though not required to be used with, class A and B address. Most commonly, localhost is written as 127.1, where 127 is the first octet, and the 1 the last three. With two dots, it is octet, octet, and two octets. Also, with many one can write a single hex constant, starting with 0x. The latter is most convenient for a subnet mask. I suspect this goes back to an early RFC, which is forgotten by now. Gah4 (talk) 20:15, 3 May 2024 (UTC)
 * Back to the classful days, there are representations with zero, one, or two dots, in addition to the common three dots. They are designed after, though not required to be used with, class A and B address. Most commonly, localhost is written as 127.1, where 127 is the first octet, and the 1 the last three. With two dots, it is octet, octet, and two octets. Also, with many one can write a single hex constant, starting with 0x. The latter is most convenient for a subnet mask. I suspect this goes back to an early RFC, which is forgotten by now. Gah4 (talk) 20:15, 3 May 2024 (UTC)

Change to IPv4 from "Internet Protocol version 4"
I propose this change on two facts which are

One. The article on IPv6 is named similarly and we should aim for parity on naming both

Two. The short form is more commonly used NotPixel (talk) 17:21, 3 September 2023 (UTC)

Comments here won't be considered. If wanted, please comment in the requested move below. Johnuniq (talk) 05:58, 6 May 2024 (UTC)
 * Oppose - I'd like to see evidence that IPv4 is more common than other forms. You must take into consideration that when sources say IP they're still most often referring to IPv4. IPv4 was previously just called Internet Protocol (IP); IPv4 did not come into being until IPv6 came along. While consistency within an article is important, consistency between articles is of lesser importance. ~Kvng (talk) 15:08, 8 September 2023 (UTC)
 * Oppose: Proliferation of technical acronyms or abbreviations should be combated in a general purpose encyclopedia. IPv4 means nothing to the vast majority in the general audience. nore does IPv6.  Even if you call a support person of many consumer Internet access providers, they often don't know what IPv4 or IPv6 is.  On the other hand, it is natural that specialists, networking and IT professionals, use abbreviations. They know what it means and prefer brevity, and can communicate effectively that way. That is true for any technical field, even non-technical. When someone randomly arrives on a page, the title should provide a general clue. In the same manner the IPv6 page should also be renamed to show that the subject area is the Internet Protocol. After all we don't name the page Internet Protocol just IP, despite most professionals would use the acronym in common discussions. Google searches for commonality of phrases should exclude technical sources written by specialists for specialists. It is simply not appropriate to include them. WP is not a work for specialists. WP must keep technical articles accessible to non-specialists. Specialists don't need Wikipedia to look up facts or background, both of which are rather terrible in most of these articles anyways, including this one.  No programmer would rely on information from a Wikipedia page. kbrose (talk) 17:05, 8 September 2023 (UTC)
 * Oppose - I presume there is a redirect for those that want to find IPv4, but otherwise this name better represents the article. Gah4 (talk) 20:10, 3 May 2024 (UTC)
 * Oppose - Rename IPv6 instead, I presume there is a redirect for those that want to find IPv4, but otherwise this name better represents the article.--Kgfleischmann (talk) 05:31, 6 May 2024 (UTC)

Recent edit adds incorrect information to Header section
In this recent edit https://en.wikipedia.org/w/index.php?title=Internet_Protocol_version_4&oldid=1186722017, @Kvng add the following sentence to the Header Checksum section:

A value of 0xFFFF is expected.

To my knowledge (and confirmed by their source article), the value should be zero instead:

If there is no corruption, the result of summing the entire IP header, including checksum, should be zero.

I'm not too familiar; maybe someone with more experience (or @Kvng themselves) can weigh in how to correct this discrepancy. Cpiber (talk) 15:48, 5 December 2023 (UTC)


 * Please see above ~Kvng (talk) 20:41, 5 December 2023 (UTC)
 * Thanks, I overlooked that entry. Cpiber (talk) 07:56, 6 December 2023 (UTC)

Requested move 3 May 2024

 * The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved per request. Favonian (talk) 11:38, 10 May 2024 (UTC)

Internet Protocol version 4 → IPv4 – Per WP:COMMONNAME and WP:CONSISTENT with IPv6. PhotographyEdits (talk) 11:37, 3 May 2024 (UTC) The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
 * Rename per nom. * Pppery * it has begun... 15:18, 3 May 2024 (UTC)
 * Support. Strange that this is different from IPv6. YorkshireExpat (talk) 17:42, 3 May 2024 (UTC)
 * Support per nominator. Vissel0126 (talk) 17:08, 5 May 2024 (UTC)
 * Oppose IPv4 is only the WP:COMMONNAME for those who already know what it is. If you pick a random person on the street and ask what IPv4 is, they likely will have no idea. And using IPv6 as an example, could just as well be used to argue for a change in that one. (I didn't look to see it there was anyone asking.) Gah4 (talk) 19:37, 5 May 2024 (UTC)
 * Oppose Per Gah4, IPv4 is only recognizable by those of us who are familiar with this topic. It's IPv6 which should be renamed. In fact, the article starts "Internet Protocol version 6 (IPv6)" showing that the full name is what makes sense. Johnuniq (talk) 02:32, 6 May 2024 (UTC)
 * All articles that have an abbreviation as the title explain the full title in the first sentence, this is not a valid reason to oppose the move. PhotographyEdits (talk) 07:04, 6 May 2024 (UTC)
 * Oppose - IPv4 is WP:JARGON. Consider moving IPv6 to resolve WP:CONSISTENT issue. ~Kvng (talk) 03:26, 6 May 2024 (UTC)
 * WP:JARGON has nothing to do with the title policy of Wikipedia. The name will continue to be explained in the first sentence, this is a non-issue. PhotographyEdits (talk) 07:16, 6 May 2024 (UTC)
 * Support. There is the Internet Protocol page for people who don't know about the version numbers. It links to IPv4 and IPv6. Ttwaring (talk) 13:55, 6 May 2024 (UTC)
 * Support per nom. mwwv (converse) 14:13, 6 May 2024 (UTC)