Talk:IPv4

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)

It's hard to make it longer than a short sentence:

in a network range defined by a "network address" and a "netmask", the first address, which is the "network address" itself, and the last address called "broadcast address" have each a specific role and are thus out of the range of usable addresses; both addresses can be derived from the network address and the bitmask.

I remember a colleague in support who was stating to a customer that 172.16.0.255 could not work as an IP address, never, ever, so the sentence may have serious consequences: the customer complained. To be fair, /25 and /23 are pretty common, but most "users" have no idea of what a netmask is, they just throw "255.255.255.0" because that's all they know. popq %rsi (talk) 18:26, 9 August 2024 (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#Header Checksum. Two calculations are needed:

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).

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)

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#Verifying_the_IPv4_header_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". Mindmatrix 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)

That's what ip2long() does in PHP and what inet_pton() does in C. Actually, all IPv4 are treated as the 32-bit addresses that they are, everything was designed originally to take advantage as much as possible of binary-level optimisation popq %rsi (talk) 19:06, 9 August 2024 (UTC)

Change to IPv4 from "Internet Protocol version 4"

The following discussion 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.

---

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)

• 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)

@Kbrose and Kgfleischmann: Comments here won't be considered. If wanted, please comment in the requested move below. Johnuniq (talk) 05:58, 6 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.

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 #Header Checksum 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)

• 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)

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.