Subject: Question regarding RFC2460, section 4.7 "No Next Header"

From: Grant Welch <[email-masked]>
Date: Fri, 2 Aug 2013 16:45:05 +0000

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.

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-masked]
- desk: 217.531.8303

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Aug 2013 09:05:10 +1200

>    contains 59, those octets must be ignored, and passed on unchanged if

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

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Gandhar Gokhale <[email-masked]>
Date: Mon, 5 Aug 2013 10:07:14 +0530

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-masked]> wrote:

> > 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.
> >
> > 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?
> >

-- 
Gandhar Gokhale
Networking Components Group
LSI

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Aug 2013 17:30:20 +1200

> 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

---

From: Grant Welch <[email-masked]>
Date: Mon, 5 Aug 2013 20:42:00 +0000

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
- [email-masked]

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, August 05, 2013 12:30 AM
> To: Gandhar Gokhale
> Cc: Grant Welch; [email-masked]
> Subject: Re: Question regarding RFC2460, section 4.7 "No Next Header"
> 
> > 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.
> 
> >> 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
> >>
> >> 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.)
> >> 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?
> >> 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-masked]
> >>>
> >>>
> >>> IETF IPv6 working group mailing list [email-masked] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6