Joe Touch wrote: >> 2. Giving the exact length of "original datagram" in octets to >> differentiate the origianl datagram from a possibly added padding >> is unnecessary, since the length of the original datagram can be >> deduced from its own length field, carried in the IP header of >> the original datagram itself. > > This is true only if the original IP datagram is included in its > entirety. That's not the case for MTU-sized original datagrams, or > any datagram which is otherwise truncated (e.g., for performance).
Joe, FWIW, what Mark suggested was not that the proposed new length field for the Original Datagram field would be unnecessary, but rather to add some explanatory text to the draft on why that length field does not need to require a higher resolution than the current 4-octett resolution. Specifically, a 1-octett resolution could be used to more easily separate the non-padding bytes from the padding bytes in the Original Datagram field. But again, the existence and actual number of padding bytes can also be derived using the length field of the encapsulated IP header. (If the IP datagram is not fully included, then there is no padding. Otherwise, the padding bytes can be calculated by subtracting the length specified in the encapsulated datagrams IP header from the length of the Original Datagram field.) It was just a suggestion to explain this a bit more in the draft to help the reader understand it more quickly. Kind regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
