Hi, I remember having read in one of the conversations that the intention for this was supporting experimentation with new transport layer protocols. Having the no-next header followed by the experimental protocol and payload would allow the end points to test the new protocol without the network requiring to know about it.
On Sat, Aug 3, 2013 at 2:35 AM, Brian E Carpenter < [email protected]> wrote: > 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 > > - [email protected] > > - desk: 217.531.8303 > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [email protected] > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- Gandhar Gokhale Networking Components Group LSI
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
