Thank you both for your responses. It seems that I was simply over thinking the
decision process.
As far as the implications, Brian, I think you are right. Either the Network
Admin will either be permissive-to or restrictive-to both events ("phantom
bytes" and unregistered extension headers). There's unlikely to be much middle
ground.
-------------------
- grant welch
- gwe...@riverbed.com
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Monday, August 05, 2013 12:30 AM
> To: Gandhar Gokhale
> Cc: Grant Welch; ipv6@ietf.org
> Subject: Re: Question regarding RFC2460, section 4.7 "No Next Header"
>
> 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
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> 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
--------------------------------------------------------------------
