Talk:IPv4

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing (Rated C-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.
 

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)

Clarify: Quintillion(Short Scale or long scale?)[edit]

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)

Fragmentation/reassembly confusion[edit]

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)


Fragment offset[edit]

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)

Please dab ECN[edit]

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)

Address representations[edit]

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)

IP Listing web sites[edit]

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


class B and x.0.0.0 and x.255.255.255[edit]

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


LS(R)R and SS(R)R[edit]

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)

Fragment offset[edit]

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)

Bit Numbering[edit]

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)

Wrong data[edit]

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=[edit]

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)

Classful vs Classless[edit]

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)

/8 and /that[edit]

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[edit]

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)

Addresses ending in 0 or 255 Revisited[edit]

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)

That section makes my head hurt. How about we gut it and rename it "Broadcasts" and include the information from RFC 1122 section 3.3.6 in the simplified manner you've suggested. -—Kvng 19:39, 6 December 2012 (UTC)