Talk:Internet Protocol version 4

Old comment

The listed IP addresses no longer point to wikipedia.org - they do point to a Wikimedia Foundation 'wiki does not exist' page however. -- Mithent 17:59, 7 Nov 2004 (UTC)

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 10¹⁸ or long scale 10³⁰ could be meant. An unclear factor of 10¹², 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)

class B and x.0.0.0 and x.255.255.255

Name	IP address range	number of IPs	classful description	largest CIDR block
24-bit block	10.0.0.0 – 10.255.255.255	16,777,216	single class A	10.0.0.0/8
20-bit block	172.16.0.0 – 172.31.255.255	1,048,576	16 contiguous class Bs	172.16.0.0/12
16-bit block	192.168.0.0 – 192.168.255.255	65,536	256 contiguous class Cs	192.168.0.0/16
16-bit block	169.254.0.0 – 169.254.255.255	65,536	class B	169.254.0.0/16

The 169.254.x.x thing is in class B.... (I'm not very familiar with the subject though so I didn't change it) Also apparently x.0.0.0 and x.255.255.255 mean something so the combinations are only 16,777,214 and 65,534. "The numbers in the host ID cannot all be 255, as this address is used as an IP broadcast address. The host ID cannot be all zeros (0s) because this address is used to denote a network ID." Zephyr103 23:28, 27 August 2007 (UTC)

References to classes is obsolete; special meanings of an last octet of 0 or 255, in any event, have meaning only for Class C addresses. The correct way to interpret special meanings is that the host part of the address (i.e., the part following the prefix) can neither be all binary zeroes or all binary ones. Binary zeroes refer to the subnet as opposed to any host on it, and all-ones is the local broadcast Howard C. Berkowitz 01:24, 29 August 2007 (UTC)

I'd like to ask for clarification on the all-zeros host part thing (again). Assuming CIDR, I don't understand why the low-order-bits-all-zeros IP is a bad thing, or to put it another way "What precisely would it screw up"? The article now has an air about it that suggests that the all-zeros point has been explained, yet it has not. I could tentatively suggest one possible answer to my own question, "in some cases because software will fail because of bugs or software will forbid an all-zeros choice in the UI" from personal experience, but then if that's correct I'm assuming that that such software misbehaviour is just an accident of history. So I ask myself whether or not there is anything more behind this?CecilWard (talk) 22:00, 7 July 2010 (UTC)

The all zeros address is commonly used as the address of the network. In that case, there is probably no problem using it. Also, in the early days some used it for the broadcast address. SunOS uses it as the default broadcast address, for as long as I used SunOS. Otherwise, it is tradition not to use it. Gah4 (talk) 21:10, 31 May 2023 (UTC)

The article Subnetwork#Subnet_zero_and_the_all-ones_subnet is rather bettter written on this topic and gives something more nearly qualifying as an explanation. I've just found this belatedly, as I couldn't see a link to this rather more useful section in the all-zeros-ones section of the IPv4 article itself.CecilWard (talk) —Preceding undated comment added 22:44, 7 July 2010 (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#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)

An Article on The IPv4 in the Wiki journal of science

Hello,

Wiki journal of the science has published the following article last month:

A Survey on Internet Protocol version 4 (IPv4)

This article addresses all the aspect of the protocol.

I will replace the current content with the article starting the next week

Please tell me if there is any problem.Michel Bakni (talk) 20:21, 2 January 2023 (UTC)

@Michel Bakni I'm not sure if I understand this proposal. Do you propose to replace the entire contents of the current article with what you've linked? Seems a bit drastic. I'm more comfortable with making incremental improvements. What justifies wholesale replacement? Is there precedent for work like this? ~Kvng (talk) 14:56, 8 January 2023 (UTC)

Hello @Kvng:.

I am ok with incremental improvements, but it will lead to the same result eventually.

What justifies the change is that they cover the same subject, but the journal article was peer-reviewed and it is heavily supported by sources.

Regarding precedent for works like this, please check this category and this template {{Academic peer reviewed}}.

Best, Michel Bakni (talk) 17:31, 8 January 2023 (UTC)

I'm looking a little more deeply and I have some immediate concerns about a wholesale replacement.

1. Fragmentation and Reassembly content is covered in IP fragmentation. We don't need detailed coverage in this article.
2. Address Space Exhaustion content is covered in IPv4 address exhaustion. We don't need detailed coverage in this article.
3. A lot of the article is presented in list format. On Wikipedia WP:PROSE is preferred.

What do you propose WRT making incremental improvements? ~Kvng (talk) 02:46, 9 January 2023 (UTC)

Yes, no problem with me regarding the incremental improvements, I will start by the end of this week.

Just asking to be sure, there is no problem tagging the article with {{Academic peer reviewed}}, after the improvements are finished? Michel Bakni (talk) 11:56, 9 January 2023 (UTC)

Not a problem if the message is read carefully. If read quickly, it implies the Wikipedia article you are reading is the direct product of academic peer review. ~Kvng (talk) 02:07, 13 January 2023 (UTC)

@Michel Bakni did you get a chance to incorporate the contents from the peer-reviewed version into the Wikipedia article? OhanaUnited^{Talk page} 20:38, 31 May 2023 (UTC)

Hello, not yet, sorry!

I was busy, I will strt doing it next week.

Sorry again! Michel Bakni (talk) 20:48, 31 May 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)

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)

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

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)