On 03/08/2013 04:45, Grant Welch wrote: > To whom it concerns, > > I found the latter portion of the section of interest. > > ...If the Payload Length field of the IPv6 header indicates the > presence of octets past the end of a header whose Next Header field > contains 59, those octets must be ignored, and passed on unchanged if > the packet is forwarded.
It seems to me that this is simply an expression of the general principle that the network should be transparent to packets from end to end. I doubt there is anything more to it than that. It goes with the general requirement that forwarding nodes must transmit all extension headers transparently (the topic of draft-ietf-6man-ext-transmit). Brian > > Which led me to ponder what the use cases were in mind to preserve data that > one could argue as potentially superfluous. I feel like I have done due > diligence in trying to answer why, but have come up empty. And, I couldn't > find a better place to post my question, so you will have to accept my > deepest apologies if this is the correct forum to ask it. (My searches > included Google, published papers, and the ietf.org website.) > > To more formally phrase my questions let me extrapolate my interpretation. > RFC2460, section 4.7 makes it necessary to preserve the IP packet payload > regardless of the fact that the 'Next Header' field seems to have stated that > there will be no more data. That is not necessarily true of course because > semantically speaking it's just saying there's no more headers. So, one might > forgo all standard or documented transport level protocols and use the 'No > Next Header' option to signal to network hardware to stop further > interpretation of the data and to force middleboxes to preserve the data. > > Is this a correct interpretation? Are there other ramifications that I am > missing? > > This portion of the RFC was written back in 1995 and I cannot find any > documentation about the decision process to amend it in. Does anyone have any > recollections about the process? If there were expected use cases at the time? > > Again, my apologies if this is the wrong forum. If so, might you direct me > toward the correct one? > > Thanks for your time. > > ------------------- > - grant welch > - gwe...@riverbed.com > - desk: 217.531.8303 > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
