Talk:IPv4

The listed IP addresses no longer point to wikipedia.org - they do point to a Wikimedia Foundation 'wiki does not exist' page however. -- Mithent 17:59, 7 Nov 2004 (UTC)

Fragmentation/reassembly confusion

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

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

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

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

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

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

-Carl

When you split a large IP packet up into smaller "fragments" (usually at some router in the middle of the path from the source to the destination), the fragments all look like real IP packets - i.e. they have a full IP header. Almost all the fields will be the same value as in the original packet. (In particular, all the fragments will have the same identification field value.) The differences are:

- The "total length" field will be smaller - set to the size of each fragment
- The *more fragments" single bit flag will be one in all but the last fragment
- The "fragment offset" field will be non-zero in all but the first fragment

Note that at the destination, in any incoming packet, if either:

- The *more fragments" single bit flag is one, or
- The "fragment offset" field is non-zero

that packet is a fragment. At the destination, to reassemble the fragments back into the original packet, look for incoming packets with the same value in the id field - they all belong to the same original packet. The offset and total length fields tell you where each piece goes, and how much it fills in. You can tell the total size of the original packet because in the packet with the "more fragments" flag clear, the value of the size field in that packet, plus the value in the offset field (multiplied by 8, IIRC), gives the total length of the original.

Note that you can repeat the fragmentation process (e.g. at a later router) - take a fragment, adjust the offset and total length fields, and create two (or more) new packets. The only complication is that if the "more fragments" flag was zero, set it to one in all but the last fragment. (It's relatively simple programming to write the code so that it doesn't need to know whether the packet it is fragmenting is a fragment, or a complete packet.) Note also that if a packet that was fragmented, and some of the fragments lost, is retransmitted with the same identification number, and also fragmented, fragments from the second copy can be used to fill in the "blank spots" from the first one.

Hope this helps! Now I guess I should cut-n-paste this into the page! :-) Noel 20:38, 21 Oct 2004 (UTC)

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

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

Arbiel 16:12, 24 January 2006 (UTC)

1) Yes, the reassembly is (really!) only done at the destination. As far as encryption. If the data is encrypted at the source then it doesn't matter since it will be reassembled at the destination. If a hop in the path is encrypted then it must be decrypted at the end of the hop. Leaving it encrypted would be utterly pointless since neither end knows how to decrypt it.

2) Segmentation and reassembly is always done at the IP layer.

Cburnett 01:19, 22 February 2006 (UTC)[reply]

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)[reply]

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)[reply]

Right on my PC?

Say if all that fragment gathering happens right on my little PC.

Yes, it does. All RFC-compliant IP hosts perform reassembly. --Brouhaha 02:54, 26 August 2006 (UTC)[reply]

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)[reply]

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

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)[reply]