Jump to content

Talk:IPv4/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

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)

Fragmentation/reassembly confusion

I'm ashamed to admit I don't understand how a reciever knows what order to assemble IP packets in to get the original message.

Looking at the packet summary chart, I see two fields that looks like they could be used for this purpose: Identification and Fragment Offset.

"The next 16-bit field is an identification field. This field is primarily used for uniquely identifying fragments of an original IP datagram."

Another Wikipedia page says datagram = packet. So what's a fragment of an 'original IP packet'? Do you mean 'fragment of the original message'?

"The fragment offset field is 13-bits long, and allows a receiver to determine the place of a particular fragment in the original IP datagram."

Again, same question. And how is this different from the Identification field?

-Carl

When you split a large IP packet up into smaller "fragments" (usually at some router in the middle of the path from the source to the destination), the fragments all look like real IP packets - i.e. they have a full IP header. Almost all the fields will be the same value as in the original packet. (In particular, all the fragments will have the same identification field value.) The differences are:
    • The "total length" field will be smaller - set to the size of each fragment
    • The *more fragments" single bit flag will be one in all but the last fragment
    • The "fragment offset" field will be non-zero in all but the first fragment
Note that at the destination, in any incoming packet, if either:
    • The *more fragments" single bit flag is one, or
    • The "fragment offset" field is non-zero
that packet is a fragment. At the destination, to reassemble the fragments back into the original packet, look for incoming packets with the same value in the id field - they all belong to the same original packet. The offset and total length fields tell you where each piece goes, and how much it fills in. You can tell the total size of the original packet because in the packet with the "more fragments" flag clear, the value of the size field in that packet, plus the value in the offset field (multiplied by 8, IIRC), gives the total length of the original.
Note that you can repeat the fragmentation process (e.g. at a later router) - take a fragment, adjust the offset and total length fields, and create two (or more) new packets. The only complication is that if the "more fragments" flag was zero, set it to one in all but the last fragment. (It's relatively simple programming to write the code so that it doesn't need to know whether the packet it is fragmenting is a fragment, or a complete packet.) Note also that if a packet that was fragmented, and some of the fragments lost, is retransmitted with the same identification number, and also fragmented, fragments from the second copy can be used to fill in the "blank spots" from the first one.
Hope this helps! Now I guess I should cut-n-paste this into the page! :-) Noel 20:38, 21 Oct 2004 (UTC)


1) Is reassembly really done at the destination point ? What about encription down the road on a limited portion of the path, short to the destination ?

2) At the reassembly location, at which level of the IP stack is the reassembly performed ? I understand IP to be a best-effort mechanism which does not react to out-of-order or lost packets ? If the reassembly is not performed at the IP level, how can IP decide to break down a packet, when there is no garantee the transport protocol at the other end implements the reassembly function  ?

Arbiel 16:12, 24 January 2006 (UTC)

1) Yes, the reassembly is (really!) only done at the destination. As far as encryption. If the data is encrypted at the source then it doesn't matter since it will be reassembled at the destination. If a hop in the path is encrypted then it must be decrypted at the end of the hop. Leaving it encrypted would be utterly pointless since neither end knows how to decrypt it.
2) Segmentation and reassembly is always done at the IP layer.
Cburnett 01:19, 22 February 2006 (UTC)


Please dab ECN

In the IPv4#Header diagram, there's a link to ECN, which is a dab page. I'm guessing the link should be to Explicit Congestion Notification, but I'm not sure. Can somebody who knows for sure please fix the link. Thanks -- RoySmith (talk) 15:35, 25 February 2006 (UTC)

It was dab'ed in the table right next to it. :) Cburnett 01:15, 26 February 2006 (UTC)

Fragment offset

In the examples in this article the fragment offset is measured in bytes, however RFC 791 states that fragment offset is measured in groups of 8 bytes (64 bits). In my opinion this article should be updated...

--Patrickdepinguin 18:30, 7 June 2006 (UTC)

I thought so too. So I made it so, almost exactly six months later. :) I was very confused from multiple sources, so I just had to go read the RFC itself, then figured no one else should have to spend all that time...Hope what I wrote is clear.

--Bmpercy 19:16, 7 December 2006 (UTC)

IP Listing web sites

(Conversation moved from User talk:Corti)

Wondering why you called the link I added yesterday to IPv4 spam? I am a neutral third party (with plenty of WP experience) and I put it there because it seems to be the most inert one out there - I say inert meaning there don't seem to be any ads on it so no real benefit to the recipient (whom I have nothing to do with). I was hoping we could leave that one up so all these annoying .biz (and today .tk) wouldn't be there; it's a neat resource for people who aren't familiar with things like IPs to see what theirs is. — RevRagnarok Talk Contrib 12:23, 8 February 2007 (UTC)

I removed it since it has not encyclopedic value. There is no informational value in fining out one's IP: it gives not information about the concept.Matteo 13:29, 8 February 2007 (UTC)
I disagree. How can finding out someone's own address not be "informational value?" (And no, I'm not being abstract about it like Information Theory classes.) People are adding such links all the time, I think we should have a consensus of a "clean" URL that we can have so that people stop adding "real" spam ones. — RevRagnarok Talk Contrib 13:47, 8 February 2007 (UTC)
I disagree, the page is about IP addresses. The link you provided tell's me nothing about what is an IP. And again it is not clean link: as tons of similar site it supplies a simple info with a lot of advertising.Matteo 13:54, 8 February 2007 (UTC)
All I see on http://www.whatismyip.com/ is a Google search (probably subsidized). At the bottom are two links, one describing WinXP command line stuff (useful), and another explaining IP addresses, a page you seem to be denying. I have nothing to do with the site; if you can come up with one with less BS I would be glad to go with it. — RevRagnarok Talk Contrib 14:45, 8 February 2007 (UTC)
A really clean example would be for example [1] but I'm still not convinced that it belongs to the links list. Let's see if someone else put here his/her opinion ... Matteo 14:49, 8 February 2007 (UTC)
I dont see why you would need to know your IP address via a topic on IPv4... If someone didnt know how/is not clever enough to find their IP address they are not going to be on wiki under the IPv4 section. Just my 2 cents. Tyilin 10:03 16 February 2007 (GMT)

Fragment offset

It is not entirely clear from the article, if the fragment offset of later fragments includes the header length of earlier fragments or only the length of the data itself. I guess it includes the header length, just like the total length field in the header includes the header itself, but I can't be sure. This should be clarified.

It should also be made more clear that the maximum offset of 65528 does indeed exceed the maximum packet length of 65536, because the last fragment (with the theoretical offset of 65528) would itself have a certain length. Subwy (talk) 09:48, 20 July 2008 (UTC)

Wrong data

172.16.0.0/12 172.16.0.0 is a Class B IP Address its Subnet is 255.255.0.0 therefore its CIDR should be /16 not /12 —Preceding unsigned comment added by 68.224.182.210 (talk) 15:52, 20 April 2009 (UTC)

Classful networks were obsoleted long ago. RFC 1918 clearly states that it is 172.16/12. Wrs1864 (talk) 16:04, 20 April 2009 (UTC)

Bit 6=

Added note that rfc 1349 redefines bit 6 to minimize monetary cost —Preceding unsigned comment added by 150.101.153.91 (talk) 04:49, 22 April 2009 (UTC)

Yes, but the who field was redefined by RFC 2474, making RFC 1349 obsolete. I'll rework the section to make this clearer. Wrs1864 (talk) 12:46, 22 April 2009 (UTC)

Bit Numbering

It is incredibly confusing to go against established conventions regarding bit numbering within bytes by using 0 say to mean the MSB. I realise that this is inline with the language used in the relevant RFCs and that this is pointed out before the diagram of the IP header, but surely there has to be a way to fix this? Bits-on-the-wire is not a view that most users will ever see, as rather more users will meet up with IP as a block of bytes/words in RAM rather than encountering IP by looking down a scope.

I feel that especially when individual fields are discussed, as opposed to the whole header, that this is particularly insidious. Suggestions on how to do the right thing?83.105.29.229 (talk) 12:36, 7 February 2009 (UTC)

Gosh, no. Users who learn about a protocol on Wikipedia must be able to read the RFC without useless confusion. Let's keep using the RFC order, not the ISO order, for TCP/IP related protocols.--Jec (talk) 01:32, 1 September 2009 (UTC)

/8 and /that

All the discussion I see on this use the /8 ... descriptions of IP numbers. But I see none of that here. /8 = and the like would be helpful for the general public to better understand issues involved. Tomlzz1 (talk) —Preceding undated comment added 13:50, 17 October 2010 (UTC).

This should be added to the Address representations section. I'll do so when I swing back to remove the table (see below). --Kvng (talk) 20:51, 18 November 2010 (UTC)

Address representations

Has anyone recently seen IP addresses represented to users in anything but dot-decimal notation? I have not and I'm inclined the remove the table of alternative representations in this section. --Kvng (talk) 20:48, 18 November 2010 (UTC)

"0x7f.1" - This address representation isn't from internet standard, but from POSIX.1-2001 (inet_addr). It's just widely used implementation. manpage msdn -- 84.204.161.204 (talk) 12:45, 25 November 2010 (UTC)
Thanks. I'm not convinced of notability but that covers Dotted hexadecimal and Dotted octal. I've added one of your refs to the article. Anyone have anything on Hexadecimal, Decimal or Octal? --Kvng (talk) 03:41, 29 November 2010 (UTC)
It has also been used by phishing sites to confuse users. --77.109.64.36 (talk) 10:09, 20 January 2011 (UTC)

I call BS on any representation other than the dotted-decimal. As per the RFC3986:

A host identified by an IPv4 literal address is represented in dotted-decimal notation (a sequence of four decimal numbers in the range 0 to 255, separated by "."), as described in [RFC1123] by reference to [RFC0952].

The article doesn't mention that the other representation are deviations. —Preceding unsigned comment added by 81.255.154.129 (talk) 17:40, 20 February 2011 (UTC)

Kvng, you reverted my cosmetic edits of the section discussed herein with the following commentary: “reverting changes inconsistent with ref.” What is it supposed to mean? What ref, the manpage on the <arpa/inet.h> interface of libsocket? First, we don′t have to maintain any syntactic consistency with references we use; we shouldn′t blindly borrow all syntactic quirks from references, but should rather use correct, appropriate syntax and formatting as defined by typographic conventions and the context. Second, that manpage is a technical reference for programmers; Wikipedia aims for general public, so this is another reason why we shouldn′t use C syntax in representing IP addresses. But let me explain myself in detail. My edits had a purpose — to fix formatting errors in the representations table; here′s the summary:

  • Remove the teletype formatting (<tt>) from all numbers, because there′s no reason to use this sort of formatting, I never saw it applied as such elsewhere. Numbers and dotted decimal IP addresses are written without any special formatting in the IPv4 article and throughout the Wikipedia, so we should be consistent: either drop the formatting or apply it everywhere, at least within the article boundaries.
  • Remove C programming language prefixes 0 and 0x from octal and hexadecimal numbers, respectively. Just as I said above, Wikipedia is targeted towards general public, 99% of which have no idea about these C-style prefixes. The prefixes would do no good but confuse people. We should write non-decimal numbers according to typographic conventions, as explain in Hexadecimal#Representing hexadecimal, i.e. C00002EB16. This is the only format appropriate for a general audience, since it requires no special knowledge (like that of the C programming language) and is obviously expressive. Actually, I forgot about the subscripts in my previous edits, but I shall fix my mistake in the edits to come.
  • Resolve “dot / dotted” inconsistencies. The table reads “dot-decimal”, but “dotted octal” and “dotted hexadecimal”. This is an inconsistency, we should settle on either of the two. I call the latter. If you disagree, then feel free to change all of them to “dot-...” (either all or none.) I know that both forms are correct, but it makes sense to use only of them in a single place, for the sake of eye candy.

To sum everything up: I had a bunch of strong reasons to do my edits. I will get ′em back with some revisions. If someone of you feels like reverting them back, then please supply a valid reason instead of “maintaining consistency with refs”, because we aren′t obliged to maintain any such consistency. And please be reminded: if you intend to revert only a part of someone′s edit, then you do revert only that part, possibly manually by hand; you don′t revert a whole bunch of edits because you disagree with just one of them. Have a nice day. 176.195.91.158 (talk) 20:50, 12 March 2012 (UTC)

"maintaining consistency with refs" means that the information in the table needs to be consistent with the source cited and upon which the information in the table is based. In this case, [2]. This man page describes the specific formats acceptable to library functions that parse IP addresses. According to the ref, the leading 0's and 0x's are necessary. By reverting your edits I was addressing a technical issue not a typographical one. I have reverted again so that the information is correct. If you believe your changes are correct and that the article and ref are incorrect, please find some other citations before making any changes. If you want to reinstate cosmetic changes without introducing technical errors, I will not quibble. --Kvng (talk) 18:47, 14 March 2012 (UTC)
I know that the 0 and 0x prefixes are necessary, but only in code written in C and derivatives. The article is not about IPv4 programming in C using libsocket from UNIX, but about IPv4 in general. And address representations are discussed in general context, not in context of C programming. As such, the 0 and 0x prefixes are redundant and out of place. We don′t use the C notation in general, we use mathematical notation instead, which is what I did in my last edit.
Also, didn′t you read the last paragraph of my previous message? It reads: if you intend to revert only a part of someone′s edit, then you do revert only that part, possibly manually by hand; you don′t revert a whole bunch of edits because you disagree with just one of them. What is it that you don′t understand? I made three edits, one of which was about numerical prefixes. Now tell me the reason you reverted two other of them for. 95.220.170.8 (talk) 15:13, 17 March 2012 (UTC)
The ref describes a library function that interprets IP addresses in text format. This library function is used, for instance, when you type an IP address into the address bar of your browser. The formatting described is relevant to users, not just programmers. The IP address for Google is 74.125.227.80. Open a browser and try typing http://0x4a.0x7d.0xe3.0x50/ in the address bar.
Please assume good faith of other editors. I did selectively manually revert your original edits. The changes I reverted either introduced errors or did not improve the article. In my experience, many editors will wholesale revert if they believe you have introduce an error. This is especially true for unregistered editors such as yourself. These responses are learned from fighting spam here on WP. Consider registering and don't assume anyone's out to disrespect you. --Kvng (talk) 16:58, 19 March 2012 (UTC)
Generally I support Kvng's reasoning — Wikipedia is not the place for a writer to demonstrate how technically hip they are. I've been a professional programmer, although not recently. I came for some basic answers to changes that have been made in the last years, and instead what I got was technobabble that will force me to go elsewhere to get my questions answered.
A pernicious trend invading other wikis too — for example the Minecraft game wiki — is to give an exhaustive iteration of when feature changes occurred. Casual users do not need to see graphs and interactive charts of software distributions that largely are no longer used! http://www.minecraftwiki.net/wiki/Ore. And it's hard to imagine who is entertained or enlightened by: "Lapis lazuli was introduced in Beta 1.2. Initially, it only dropped one dye per block. Jens Bergensten acknowledged that the ore was too rare[1] and increased the drop rate to 4-8 in the Beta 1.2_02 update. Prior to 1.9 prerelease 6, it could not be smelted to obtain the dye." 76.102.1.193 (talk) 15:49, 24 May 2012 (UTC)

Address representations

quote from the article: All/most of these formats should work in all browsers.

Well I'm using Safari 2.0.4 under Mac OS X 10.4.7 and only the Dot-decimal notation brings up a webpage (all the others bring up can't find the server) and even that one's not identical to wikipedia.org - it's a website from wikimedia that reads Wiki does not exist --elias.hc 23:33, 17 July 2006 (UTC)

I haven't researched the correctness of this, but HTTP 1.1 can supply the hostname (wiki.riteme.site) in the request to which the web server can use for virtual domains. I'd be willing to bet that this is what wikipedia uses, which would mean that any thing other than wiki.riteme.site wouldn't be recognized. Cburnett 06:04, 10 December 2006 (UTC)

Request for expansion of this section I came to this page looking for information about just how one specified a range of addresses using the /8, /12, /16, etc notations. Would this be an appropriate section for that information? If so, it would be great if someone added it in. Benthatsme 14:44, 23 May 2007 (UTC)

I'm not quite sure what you mean by a range. Consider, though, that a IPv4 address is 32 bits long. The CIDR notation you use defines the fixed prefix part, so a /8 has 24 bits of subordinate bits, an /12 has 18, and a /16 has /16. The range, therefore, is from the prefix followed, in binary. by all zeroes to the prefix followed by all ones Howard C. Berkowitz 22:51, 15 August 2007 (UTC)
The listing of RFC 1700 for the 0.0.0.0 as a source address was incorrect - and RFC 1700 is obsolete. I corrected it to RFC 5735. AlanR (talk) 16:13, 4 January 2013 (UTC)

Can the current / historic number of routable IPv4 addresses be given in this article

Can a new section be created in the article where the current and/or historical number of routable IPv4 addresses is given? By routable, I mean that the IP address is assigned to an entity for use on the public internet (regardless if the IP address is being used or has been assigned to an end user or machine host). — Preceding unsigned comment added by 64.231.142.134 (talk) 16:29, 4 January 2015 (UTC)

Compressed IPV4 formats

What about the compressed representations of the addresses? Eg.

8.8.8.8 can be represented as 8.8.2056 or 8.526344 or just 134744072

This is useful when you want to use the short hand for 127.0.0.1 which is 127.1 This works pretty much everywhere. I'm not sure the name of it however. — Preceding unsigned comment added by 124.171.68.253 (talk) 03:29, 25 January 2016‎

I'm not sure it has a name, AFAIK it's never been defined in an RFC, except perhaps as an existing practice. The question has come up before, and my best guess is that some of this is left over behavior from early parsing routines which did little checking, which is probably where the "ability" to specify all or part of an address in hex or octal came from as well (somebody used scanf or strol to parse the address, or something like that, and then did a simplistic merge of the results). All of that is now mostly used to obfuscate IP addresses of malware in URIs. IOW, it's more a bug than a feature. Rwessel (talk) 05:33, 25 January 2016 (UTC)
I think it is correct to say there is no standard, just some practices that arose from particular implementations that tried to be generous about interpreting their input. Some relevant documents describing the situation are:
https://tools.ietf.org/html/draft-main-ipaddr-text-rep-00
http://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html
Dot-decimal notation
In summary (ignoring the octal/hex mess):
a.b.c.d → bytes a.b.c.d
a.b.c → bytes a.b + 16-bit host c
a.b → byte a + 24-bit host b
a → 32-bit number
Johnuniq (talk) 06:55, 25 January 2016 (UTC)
Unfortunately we can't actually ignore the octal/hex mess, as the first reference you posted states - not only is it common, it conflicts with actual usage in certain IANA documents. IOW, it's a mess. The current Address representations actually comes close to documenting all the (common) possibilities (mainly omitting the intermediate two- and three-part forms). I think, however, that the critical take from the IEFT document is:
The 4.2BSD inet_aton() has been widely copied and imitated, and so is a de facto standard for the textual representation of IPv4 addresses. Nevertheless, these alternative syntaxes have now fallen out of use (if they ever had significant use).  The only practical use that they now see is for deliberate obfuscation of addresses: giving an IPv4 address as a single 32-bit decimal number is favoured among people wishing to conceal the true location that is encoded in a URL.  All the forms except for decimal octets are seen as non-standard (despite being quite widely interoperable) and undesirable.  (emphasis added)
I don't object to adding the missing coverage to Address representations, although I don't think it's all that important, I do think we should add that the format is not well defined in the standards, and that "All the forms except for decimal octets are seen as non-standard (despite being quite widely interoperable) and undesirable". Rwessel (talk) 07:54, 25 January 2016 (UTC)
As you would know, describing the octal/hex stuff is easy although very confusing for people not used to C's odd procedures. Each of the numbers mentioned above (a, b, c, d) is interpreted as hex if it starts with "0x" or "0X", or is interpreted as octal if it starts with "0". Some systems interpret "089" (invalid octal) as if it were octal anyway, while others regard a string like 1.2.3.089 as a name because it is not a valid address. It's fun to play with commands like ping -n 1 192.168.010.0X10 because ping will tell you how it has interpreted the string (that example tries to ping 192.168.8.16). One unfortunate situation is that there is not much that can be added to the article and be suitably sourced. It should be mentioned somewhere, but I don't know where. Perhaps there is an article on the security issue where malicious sites attempt to disguise what they are doing with obfuscated IP addresses? I don't know if they still do that. Johnuniq (talk) 09:40, 25 January 2016 (UTC)
Well, the spam quarantine database on my email server has hundreds of emails every day with links like: http://yourbankename.com@3627735278/mail everyday (that one will take you to gmail, if you actually tried it (and that can be much better buried). The IETF would probably be a good, if not great source, IMO. Rwessel (talk) 10:20, 25 January 2016 (UTC)
Thanks, so address obfuscation it's still being tried. The IETF is the gold standard, but a wikilawyer would argue that a draft is not definitive and that many of the things we have discussed here are not supported by the document. However, I'm not going to argue like that. Johnuniq (talk) 10:50, 25 January 2016 (UTC)
Somewhat interestingly, it looks like RFC 1738 (definition of URLs) actually prohibits all the alternative forms (section 3.1: "host - The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by ".". "). Nor are user names and passwords allowed for HTTP URLs (so the "@" trick shouldn't work). Obviously rules honored mostly in the breach... Rwessel (talk) 11:15, 25 January 2016 (UTC)

Hello fellow Wikipedians,

I have just added archive links to one external link on IPv4. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 10:41, 27 February 2016 (UTC)

Hello fellow Wikipedians,

I have just modified one external link on IPv4. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 18:48, 12 September 2016 (UTC)

Total Length

I've just updated the description of the Total Length field in the header. The previous version implied that this field contains the size of the packet for fragments as well, which is incorrect. In the case of fragments, this field only contains the size of the current fragment, namely, two fragments of the same packet can have different total lengths. Feel free to update language, though. I suck at technical writing. — Preceding unsigned comment added by 2620:0:1000:3008:B4CB:B615:EB0:44B8 (talk) 17:27, 1 March 2017 (UTC)

Hello fellow Wikipedians,

I have just modified 2 external links on IPv4. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 08:58, 10 November 2017 (UTC)

Addresses ending in 0

I responded to a citation request today asking for a reference for addresses where host id is all zero being reserved as per the description on the page. I cited RFC 950 that originally reserved certain 0 subnets (but is obsoleted by CIDR) and then realised that this was not the question being asked. It is simply why the first address in any subnet (except point to point) is reserved. That turns out to be a slightly longer answer. I have cited RFC 943 (Assigned Numbers) which originally prevented this, but things change. Also relevant is RFC 1812, with its discussion of directed broadcasts which became a use for this reserved address. RFC 2644 officially changes that, and directs such packets to be silently dropped. All good reasons why the number is reserved, but no single source really applies. Should this be expanded? Or will RFC 943 do? Sirfurboy (talk) 11:40, 15 November 2019 (UTC)

And I still didn't cite the original one. RFC 923 appears to be the first one to reserve this address!Sirfurboy (talk) 11:57, 15 November 2019 (UTC)

Number of IPv6 addresses

@Sper56: has added some good information about IPv6 but I find the claim that 7.9×1028 additional addresses have been added to be dubious. The number is approximately 296 which is obviously lower than the full IPv6 address space as much of the space is reserved. That might be made clearer, but then I am not sure the number is correctly 296 (even though another Wikipedia page has this number - unsourced - too). 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 296, nor does it prevent the allocation expanding again in the future, so it is not clear to me what we are counting here. What do we mean by this number? Do we even need it? Thanks again for the edits. -- Sirfurboy (talk) 10:54, 13 December 2019 (UTC)

The calculation here is not trivial. If it can't be readily substantiated by reliable sources, I don't think this is needed. I have changed this to compare address size in bits. ~Kvng (talk) 14:58, 31 December 2019 (UTC)
Actually kbrose (talk · contribs) already removed it here[3]. I think adding back in the size in bits is fine too, thanks. Further detail on that belongs in the IPv6 page, not here. I have removed (again) an uncited claim that IPv6 has been in commercial deployments since 2006. What are we counting as commercial deployment? It is also maybe more detail than we need in the IPv4 article because, as with the calculation, we have to go into some detail as to what "commercial deployment" actually means. -- Sirfurboy (talk) 15:41, 31 December 2019 (UTC)
Commercial (as a contrast to experimental) IPv6 deployment may reasonably be pinpointed to the beginning of permanent allocations by RIRs after 2006, when the 6bone project officially ended, which is now indicated in the article, and documented by RFCs. But it is only of interest to provide a historical progress marker to understand the transition history from IPv4. More than what's there about IPv6 is not really necessary, because this article is about IPv4. Last not least, the number of address is really not of interest, IPv6 was not designed to satisfy some requirement. The number of existing addresses in IPv4 is also not of interest or even knowable. Kbrose (talk) 17:23, 31 December 2019 (UTC)

Total Length field in the IP Header

The maximum length of an IP Datagram is limited by the Total Length field in the IP Header. The field has a length of 16 bits which indicates 65535 bytes, plus 1 byte padding to complete the 4 byte datagram structure = 65536 bytes (Data Field + padding + IP Header). Since the IP Header takes at least 20 bytes, the datafield cannot be up to 65536 bytes as indicated in the top right drawing on this page. The text next to the parenthesis should be "65536 minus IP Header" or the parenthesis should include the IP Header. The description of the Total Length field in the article is correct. Can anyone edit this or convince me that I'm wrong? Kees de Caluwe (talk) 09:23, 24 August 2022 (UTC)

You are right. Indeed you can't use the 1 byte pad either as you cannot describe it which is why the largest UDP payload size is listed as 65,507 bytes. I just checked Stevens 1993 and he does not put a number in his diagram for payload size. I am not sure if any sources do draw a size as I have not consulted others yet. I can easily pull out the wrong figure from the graphic. Less sure if I can insert a new number in the same style as I did not create it. I will do what I can now, and if it has no number, that will be congruent with Stevens, so not really a problem. Sirfurboy🏄 (talk) 09:51, 24 August 2022 (UTC)
I was able to edit the svg and put in the correct figure. I also corrected the missing a in "fragment". I see the correct file in media viewer now here: [4] but the page still shows the old version for me. I expect it is cached. Does anyone know if I need to do anything or do I jjust wait for the cahce to clear? Sirfurboy🏄 (talk) 10:35, 24 August 2022 (UTC)
You don't have to do anything. We are discussing the image in the lead, File:IPv4 Packet-en.svg where you changed the data block to be "Up to 65515 bytes" rather than "Up to 65536 bytes". I see the 65515 value in the article now. You may need to purge your browser's cache to see the new image (perhaps Ctrl-F5, see WP:REFRESH). Johnuniq (talk) 11:26, 24 August 2022 (UTC)
Thanks for confirming. I see the new version too now. I did indeed refresh browser cache before writing that and at that point it wasn't updating, but there are, of course, other places things get cached but all is fine now. Sirfurboy🏄 (talk) 13:04, 24 August 2022 (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? OhanaUnitedTalk 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)

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

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)

Recent edit adds incorrect information to Header section

In this recent edit https://wiki.riteme.site/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)

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)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Talk:IPv4/Archive_1&oldid=1262260507"