On 05/08/2013 16:37, Gandhar Gokhale wrote: > 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.
The network isn't required to know about new extension headers either. I can't imagine a firewall that discards unknown extension headers that doesn't also discard phantom bytes. Brian > > > On Sat, Aug 3, 2013 at 2:35 AM, Brian E Carpenter < > brian.e.carpen...@gmail.com> 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 >>> - 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 >> -------------------------------------------------------------------- >> > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
