Talk:IPv4

This is the talk page for discussing improvements to the IPv4 article.
This is not a forum for general discussion of the subject of the article.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Archives: 1: 12 months

Computing: Networking Mid‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Top-importance).

Internet Top‑importance

	Internet portal This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet
Top	This article has been rated as Top-importance on the project's importance scale.

Telecommunications High‑importance

	Telecommunication portal This article is within the scope of WikiProject Telecommunications, a collaborative effort to improve the coverage of Telecommunications on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.TelecommunicationsWikipedia:WikiProject TelecommunicationsTemplate:WikiProject TelecommunicationsTelecommunications
High	This article has been rated as High-importance on the project's importance scale.

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)[reply]

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)[reply]

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)[reply]

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)[reply]

"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)[reply]

The /31 exception is now mentioned. ~Kvng (talk) 01:41, 25 November 2023 (UTC)[reply]

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)[reply]

It's briefly (or tangentially) mentioned as an example in the second paragraph of "Address representations". Mind matrix 13:47, 28 May 2023 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

1980s

The article suggest that in the 1980's address exhaustion was expected, based on laptops, PDAs, and smartphones. Laptops and PDAs do trace back to the 1980's, though as well as I know, not ones with IP addressing. From History of smartphones, smartphones are definitely later than 1980s. I do remember by late 1980's, the ability to connect IBM PC (ISA) machines to Ethernet, with PC-NFS and NCSA Telnet, and that might have included a small number of laptops, it seems surprising to me that it would be enough to predict exhaustion based on those. Gah4 (talk) 07:20, 3 November 2025 (UTC)[reply]

I lightly modified the text to conform more closely with reality. This conforms with the dedicated address exhaustion article. cheers. anastrophe, an editor he is. 18:29, 3 November 2025 (UTC)[reply]

Cart and horse

Chronic1 insists on adding information about RFC 760 to the first sentence of the lead. RFC 760 is mentioned as sort of an aside in the History section. I reverted suggesting that if this is indeed worthy of mention in the first sentence, we develop the body further before adding it to the lead. Chronic1 suggests that we retain their changes and somehow develop the body from that. I'm looking for input from other editors on how best to proceed. ~Kvng (talk) 16:13, 16 November 2025 (UTC)[reply]

WP:LEDE strongly "argues" (it's a formal guideline) that the lead is a summary of the body. If the body does not have any coverage or inadequate coverage - or if the body gives appropriate coverage but that coverage simply shows that it's not a significantly material set of facts/claims, then it does not belong in the lede - not until it's been satisfactorily developed in the body or shown not to be significant.

The late president Ronald Reagan wore tan/brown suits during his tenure as the leader of the free world. This made national news - the New York Times reported on it. Does that therefore mean that his article should lead off with that fact in the first sentence? No. It has to do with relevance, significance, coverage, and a multitude of other factors.

What we can learn from my comment is that I need to ease off on the four-hundred horsepower coffee. cheers. anastrophe, an editor he is. 18:48, 16 November 2025 (UTC)[reply]

Regardless of whether this information belongs in the lead, it needs to be verifiable. I attempted to verify the claim that IPv4 was initially proposed under RFC 760 by the Department of Defense against cited sources, and failed. The RFC, if we can consider it to be a source on itself, says that it was written by ISI for the DoD, not by the DoD. There is one statement in the article body speaking about the DoD and RFC 760, and its source only states that In March 1982, the US Department of Defense declared TCP/IP as the standard for all military computer networking. Nothing about specific RFCs, or which party proposed it.

I would support a statement about IP's DoD origins in the lead if it were supported by a source used in the body of the article, but it currently is not. DefaultFree (talk) 00:16, 17 November 2025 (UTC)[reply]

I have reverted these changes again for now. anastrophe and I find it runs afoul of WP:LEDE and, more seriously, DefaultFree is concerned about a WP:V issue. We potentially have a consensus here since Chronic1 doesn't have a specific policy supporting their edit. We can continue discussion and un revert if things take an unexpected turn. ~Kvng (talk) 14:39, 19 November 2025 (UTC)[reply]

Yes, that makes a lot of sense. I was not aware of WP:LEDE and want to apologise for the inconvenience. At least I learned something. Chronic1 (talk) 15:14, 19 November 2025 (UTC)[reply]