Sure, but this technique is not in RFC 791 which is what I understand the ipv4-id I-D cites and is based on. For the purposes of the ident field, for a fragment (first, middle, or last) the DF value is a don't care.
Thanks, Thumb typed by Carlos Pignataro. On Apr 22, 2011, at 12:55 PM, "Templin, Fred L" <fred.l.temp...@boeing.com> wrote: > Section 8 of RFC4821 discusses host fragmentation using > the same technique Joe is describing. > > Thanks - Fred > fred.l.temp...@boeing.com > >> -----Original Message----- >> From: int-area-boun...@ietf.org >> [mailto:int-area-boun...@ietf.org] On Behalf Of Carlos Pignataro >> Sent: Thursday, April 21, 2011 9:08 PM >> To: int-area@ietf.org >> Subject: Re: [Int-area] Recycle IPv4 bits >> >> Joe, >> >> Please find one comment inline, which may have been discussed >> already in >> the thread, apologies if I missed it. >> >> On 3/31/2011 1:45 PM, Joe Touch wrote: >>> Hi, Deco, >>> >>> This proposal is a moot point; the FO needs to be zero for >> a packet to >>> be ATOMIC. see below: >>> >>> On 3/31/2011 4:41 AM, Teco Boot wrote: >>>> Having a discussion on recycling used IPv4 header bits, I made >>>> a snapshot on what was in the air at same point in time, somewhere. >>>> I found out the ID field of atomic packets was filled for almost >>>> all packets. >>>> >>>> IPv4 total: 151081 >>>> Atomic packets: 105357 (70%) >>>> On atomic packets: >>>> ID == 0 1557 ( 1,5%) >>>> ID != 0 103800 ( 98,5%) >>>> FO == 0 105357 (100,0%) >>>> >>>> The Fragment Offset was always set on zero, I read this as unused. >>> >>> That is incorrect. It is part of what makes a packet >> atomic, as per the >>> ipv4-id-update draft: >>> >>> (DF==1)&&(MF==0)&&(frag_offset==0) >>> >>> Let's look at the cases: >>> >>> DF MF FO >>> 0 x x CAN FRAGMENT >>> non-atomic packet that can be fragmented downstream; >>> that fragmentation would overwrite MF and FO >>> >>> 1 0 0 ATOMIC >>> basically this is a lot like saying >>> "this is the first and last fragment" >>> >>> 1 0 nonzero LAST FRAGMENT >>> packet has already been fragmented and >>> this is the last fragment >>> >>> 1 1 0 FIRST FRAGMENT >>> packet has already been fragmented, and this is the >>> first fragment and NOT the last (other fragments >>> with higher offsets are expected) >>> >>> 1 1 nonzero MIDDLE FRAGMENT >>> packet has already been fragmented, and this is >>> not the first fragment, and other fragments are >>> expected >> >> In these last 3 cases you include fragments (first, middle, last) with >> the DF bit set. This mimics IPv6's source-only fragmentation, >> but it is >> not clear to me how common that is. >> >> But if this is a spec exercise, RFC791 says 'An internet >> datagram can be >> marked "don't fragment."' Agreed that perhaps such datagram can be a >> complete datagram or a fragment (although I read the intention as >> meaning a complete packet), but the use case is that so that the >> receiver does not reassemble (hence meaning that it makes >> sense only in >> a complete datagram). The examples of fragmentation >> procedures in RFC791 >> do not set the DF bit. I know of systems that source-fragment without >> setting the DF bit, and a fragment can in turn be fragmented >> in flight. >> If the source is setting DF for fragments, is not following the >> procedure in RFC 791? >> >> Thanks, >> >> -- Carlos. >> >>> >>> Note that thus: >>> >>> ATOMIC packets are *defined* by having all the FO bits as zero. >>> >>>> What comes up in my mind: can we recycle the 13 fragment >> offset bits? >>>> Instead of ID field? At least it may be a well defined >> starting point. >>> >>> When the bits aren't zero, an otherwise ATOMIC packet is >> really a last >>> fragment. >>> >>> So if you try to use those bits, all you will accomplish is >> flooding the >>> reassembly cache. >>> >>> Joe >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
