Hi Vishwas I think you are reading too much into this, thus the issue is confused.
Vishwas Manral wrote: > Hi Vlad, > > Thanks a lot for your clarification, maybe I am unclear. I am > attaching a document I have attached, just have a look. > >> First, this only happens when the IPv4 host does not support path mtu >> discovery (DF bit is 0). In this case, inserting a fragment header >> at the translator in essence performs the fragmentation that was >> requested by the sender. I just so happens that in this case the >> fragment might have offset and M flag set to 0. > There are 2 sides of the problem. The first is that different > protocols use different definition of a fragment, which needs to be > clarified, because some assumption by a protocol may not work in many > cases due to the specification clarity. The second part is the use of > different policies for fragments. > > The idea I am stating is that one spec uses the Fragment header to > just signal its ability to perform fragmentation, No, it does in fact fragment the packets. It just so happens that it may result in a single fragment. The behavior here is not much different from some node on path returning ICMP Too Big with MTU less the 1280. The fragment is there to make translators work so that the translation of the DF bit is not lost while the IPv4 packet is traversing an IPv6 network. > while others > specs(AH & ESP for one) clearly lay down a differnet way for > identifying an IPv6 fragment and its subsequent treatment. As there > are different policies for fragments, the signaling may not work in > many cases(no I am not talking about policies but the clarification of > the term Fragment - example a Fragment with M = 0 and Offset = 0 > should be treated as a non fragmented packet). I do not see any > problem in clarifying exactly what an IPv6 fragment is so that we can > have a consistent set of specs as well as implementations. > >> Now you are getting in policies outside of the definition. The >> definition >> does not have to encompass all eventual uses. Otherwise we'll be >> updating >> a lot more specs. > No, I am talking about specs too besides practical network scenarios. > If we see a problem in a spec I do not see a reason we should hesitate > in fixing the problems (and its not unprecedented either). Ok, so are you concerned with what IPSec considers a fragment and how individual IPSec policies treat those fragments? > > 2. IPv6 Fragment > > The IPv6 specification [RFC2460] defines a fragment header as: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | Reserved | Fragment Offset |Res|M| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Next Header 8-bit selector. Identifies the initial header > type of the Fragmentable Part of the original > packet (defined below). Uses the same values as > the IPv4 Protocol field [RFC-1700 et seq.]. > > Reserved 8-bit reserved field. Initialized to zero for > transmission; ignored on reception. > > Fragment Offset 13-bit unsigned integer. The offset, in 8-octet > units, of the data following this header, > relative to the start of the Fragmentable Part > of the original packet. > > Res 2-bit reserved field. Initialized to zero for > transmission; ignored on reception. > > M flag 1 = more fragments; 0 = last fragment. > > Identification 32 bits is used for facilitating each fragment is > correctly reassembled at the receiver. > > An IPv6 fragment is defined to be an IPv6 packet, which contains the IPv6 > Fragment header as described above, having either the More flag or the > Fragment Offset set to have a non 0 value. Well, that's not quite right, since the middle fragments will have both a non-zero offset and More flag set. What the statement from you draft implies is that one or the other may be omitted, which is not the case. > > > > > Manral, et al. Expires December 25, 2007 [Page 3] > > Internet-Draft IPv6 Fragments June 2007 > > > In turn if an IPv6 packet contains a fragment header, with both the More > flag as well as the Fragment Offset fields set to, it is treated exactly > like an IPv6 packet without the Fragment header. This seems like a clarification that might be useful. -vlad -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
