Christian Vogt wrote: > 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.
Ahh - agreed, as per below. Thanks, Joe > 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
