![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
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)
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
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)
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)
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)
(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)
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)
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)
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)
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)
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).
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)
I call BS on any representation other than the dotted-decimal. As per the RFC3986:
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:
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)
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)
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)
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)
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
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)
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)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).
Cheers.— cyberbot II Talk 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).
Cheers.— InternetArchiveBot ( Report bug) 18:48, 12 September 2016 (UTC)
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).
Cheers.— InternetArchiveBot ( Report bug) 08:58, 10 November 2017 (UTC)
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)
@ 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 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)
Hello,
Wiki journal of the science has published the following article last month:
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)
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)
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 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).
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
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)
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
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)
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)
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)
(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)
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)
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)
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)
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)
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).
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)
I call BS on any representation other than the dotted-decimal. As per the RFC3986:
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:
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)
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)
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)
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)
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
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)
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)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).
Cheers.— cyberbot II Talk 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).
Cheers.— InternetArchiveBot ( Report bug) 18:48, 12 September 2016 (UTC)
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).
Cheers.— InternetArchiveBot ( Report bug) 08:58, 10 November 2017 (UTC)
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)
@ 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 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)
Hello,
Wiki journal of the science has published the following article last month:
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)
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)
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 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).