Talk:Internet Protocol version 4/Archive 1

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

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 (en.wikipedia.org) 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 en.wikipedia.org 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)

External links modified

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: 18 January 2022).

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

External links modified

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: 18 January 2022).

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

External links modified

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: 18 January 2022).

  • 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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Internet_Protocol_version_4/Archive_1&oldid=1186875754"