This is the
talk page for discussing improvements to the
IPv4 article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives:
1Auto-archiving period: 365 days
![]() |
![]() | This ![]() It is of interest to multiple WikiProjects. | |||||||||||||||||||||||||||||||||
|
![]() | Material from Reserved IP addresses was split to IPv4 address on 30 april 2018. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. Please leave this template in place to link the article histories and preserve this attribution. The former page's talk page can be accessed at Talk:Reserved IP addresses. |
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)
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)
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)
The section on addresses ending in 0 or 255 is somewhat misleading, and much more complicated than necessary. The addressing rule is quite simple. You can't use the first address on a network because that's the network itself, and you can't use the last address on a network because that's the broadcast address. These addresses most often end in 0 or 255, but it isn't specific to Class C or /24 or any other network designation. You can't use the first and you can't use the last applies to all IP networks and subnetworks. Is it possible to get some consensus on a different rewrite of this section that addresses the general rule rather than working around specific cases? -- Dave Braunschweig ( talk) 02:16, 4 December 2012 (UTC)
There is some confusion at IPv4#Header Checksum. Two calculations are needed:
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)
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 think this article could mention that IPv4 addresses can be expressed as a single large undotted number and some web browsers support that notation. It seems to be a popular trick with "phishing" spammers to camouflage the actual weblink target. E.g.: hxxp://1cmv5u@761244044/?&qrc=blahblah.com --> hxxp://1cmv5u@45.95.169.140/?&qrc=blahblah.com (where 761244044 is the sum of powers for 140+169*256+95*256^2+45*256^3) 188.143.7.200 ( talk) 10:30, 28 May 2023 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I propose this change on two facts which are
One. The article on IPv6 is named similarly and we should aim for parity on naming both
Two. The short form is more commonly used NotPixel ( talk) 17:21, 3 September 2023 (UTC)
@ Kbrose and Kgfleischmann: Comments here won't be considered. If wanted, please comment in the requested move below. Johnuniq ( talk) 05:58, 6 May 2024 (UTC)
In this recent edit https://en.wikipedia.org/?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)
The result of the move request was: moved per request. Favonian ( talk) 11:38, 10 May 2024 (UTC)
Internet Protocol version 4 → IPv4 – Per WP:COMMONNAME and WP:CONSISTENT with IPv6. PhotographyEdits ( talk) 11:37, 3 May 2024 (UTC)
This is the
talk page for discussing improvements to the
IPv4 article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives:
1Auto-archiving period: 365 days
![]() |
![]() | This ![]() It is of interest to multiple WikiProjects. | |||||||||||||||||||||||||||||||||
|
![]() | Material from Reserved IP addresses was split to IPv4 address on 30 april 2018. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. Please leave this template in place to link the article histories and preserve this attribution. The former page's talk page can be accessed at Talk:Reserved IP addresses. |
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)
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)
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)
The section on addresses ending in 0 or 255 is somewhat misleading, and much more complicated than necessary. The addressing rule is quite simple. You can't use the first address on a network because that's the network itself, and you can't use the last address on a network because that's the broadcast address. These addresses most often end in 0 or 255, but it isn't specific to Class C or /24 or any other network designation. You can't use the first and you can't use the last applies to all IP networks and subnetworks. Is it possible to get some consensus on a different rewrite of this section that addresses the general rule rather than working around specific cases? -- Dave Braunschweig ( talk) 02:16, 4 December 2012 (UTC)
There is some confusion at IPv4#Header Checksum. Two calculations are needed:
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)
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 think this article could mention that IPv4 addresses can be expressed as a single large undotted number and some web browsers support that notation. It seems to be a popular trick with "phishing" spammers to camouflage the actual weblink target. E.g.: hxxp://1cmv5u@761244044/?&qrc=blahblah.com --> hxxp://1cmv5u@45.95.169.140/?&qrc=blahblah.com (where 761244044 is the sum of powers for 140+169*256+95*256^2+45*256^3) 188.143.7.200 ( talk) 10:30, 28 May 2023 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I propose this change on two facts which are
One. The article on IPv6 is named similarly and we should aim for parity on naming both
Two. The short form is more commonly used NotPixel ( talk) 17:21, 3 September 2023 (UTC)
@ Kbrose and Kgfleischmann: Comments here won't be considered. If wanted, please comment in the requested move below. Johnuniq ( talk) 05:58, 6 May 2024 (UTC)
In this recent edit https://en.wikipedia.org/?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)
The result of the move request was: moved per request. Favonian ( talk) 11:38, 10 May 2024 (UTC)
Internet Protocol version 4 → IPv4 – Per WP:COMMONNAME and WP:CONSISTENT with IPv6. PhotographyEdits ( talk) 11:37, 3 May 2024 (UTC)