RE: Inserting Extension Headers or not [was rfc2460bis question ]

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Stefano:

I do agree with that. 

Since having to add IP encapsulation is really damaging to IOT operation, it soon appeared that many implementations were skipping that step and inserting headers with no idea of the risks at stake. We started to document the potential issues with that behaviour and how to avoid those issues as much as possible.

Please have a look at https://tools.ietf.org/html/draft-hui-6man-rpl-headers-00 

Cheers,

Pascal


> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Stefano Previdi
> (sprevidi)
> Sent: jeudi 28 avril 2016 17:57
> To: Tim Chown <[e-mail]>
> Cc: Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
> Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ]
> 
> 
> > On Apr 28, 2016, at 5:48 PM, Tim Chown <[e-mail]> wrote:
> >
> >> On 28 Apr 2016, at 15:33, Stefano Previdi (sprevidi) <[e-mail]>
> wrote:
> >>
> >>> On Apr 28, 2016, at 10:33 AM, Tim Chown <[e-mail]>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>>> On 28 Apr 2016, at 04:26, Brian E Carpenter
> <[e-mail]> wrote:
> >>>>
> >>>> On 28/04/2016 13:18, Bob Hinden wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I would like to get closure on the question if inserting IPv6 extension
> headers is allowed or not, and should this be a clarification in rfc2460bis.
> This topic was discussed in Buenos Aires and on the mailing list.
> >>>>>
> >>>>> The relevant text from Section 4 "IPv6 Extension Headers" in
> >>>>> <draft-ietf-6man-rfc2460bis-04.txt>
> >>>>>
> >>>>> Extension headers must never be inserted by any node other than
> >>>>> the source of the packet.  IP Encapsulation must be used to meet
> >>>>> any requirement for inserting headers, for example, as defined in
> >>>>> [RFC2473].
> >>>>>
> >>>>> This text was added to the draft in version —01 published on 2
> November 2015.
> >>>>>
> >>>>> The question is if this text was the original intent of rfc2460.  That
> would allow it to be part of rfc2460bis going to Internet Standard.  If it is a
> change, then it should not be included.
> >>>>>
> >>>>> In my personal view (as one of the authors of rfc2460), I think it was
> the original intent to not allow extension headers to be inserted.  My
> thinking is that not allowing extension headers to be inserted is related the
> design of IPv6 that includes only supporting fragmentation at the source.
> IPv4 allows the addition of options resulting in changing the header length,
> but it includes per-hop fragmentation so any resulting MTU issues can be
> dealt with.  Even IPv4 fragments can be fragmented.  I think it is a
> consequence of IPv6 not allow per-hop fragmentation, that extension
> headers were not intended to be inserted along the path to the destination.
> >>>>
> >>>> I think this exactly correct. I did a bit of archaeology and found
> >>>> the message where Steve Deering summarised the issues resolved
> >>>> before RFC 1883 (the predecessor of RFC 2460) was published in
> >>>> 1995. I've attached it below - look just after "rejected at the
> >>>> Stockholm meeting" i.e. IETF 33. The comment that triggered it was in
> message (IPng 346) from Charlie Lynn sent 30 June 1995.
> >>>>
> >>>> [I knew my mail archives would be useful one day.]
> >>>
> >>> Stunning recollection powers Brian!
> >>>
> >>> The paragraph you point to, i.e.:
> >>>
> >>> 	"reasons for rejection: insertion of extension headers en-route
> breaks
> >>>   	PMTU-discovery and can result in ICMP error messages being sent to
> >>>   	non-guilty parties.  The desired effect can be achieved, and those
> >>>   	problems avoided, by using en-route encapsulation (with optional
> >>>   	Routing Header) rather than header insertion.”
> >>>
> >>> still seems valid to me, and thus I agree with Bob’s proposal. Whether
> the above rationale is also included is an additional question.
> >>>
> >>> For example, in section 2.2 ofdraft-ietf-6man-segment-routing-header, it
> states: "At the ingress node of an SR domain where the ingress node receives
> an IPv6 packet and encapsulates it into an outer IPv6 header followed by a
> Segment Routing header.”
> >>
> >>
> >> Correct. The discussion we’re having is not related to draft-ietf-6man-
> segment-routing-header but rather on a usage of the SRH that the industry
> is adopting and that includes header insertion.
> >
> > And usage that is not being standardised within the IETF, or is it?
> 
> 
> it would be good to standardize behaviors used by the industry even if these
> behaviors are not the ones originally planned at the time the spec has been
> written.
> 
> By standardization I intend dig out all details that needs to be carefully
> addressed.
> 
> s.
> 
> 
> >
> > Tim
> >
> >> s.
> >>
> >>
> >>>
> >>> Tim
> >>>
> >>>> Brian
> >>>>
> >>>>> Note, I think it would be fine for someone to document how to do
> extension header insertion, as long as they describe how it works, and how
> to deal issues like MTU problems.  This can be be an update to rfc2460bis
> (after it is published).
> >>>>>
> >>>>> However, I do not think leaving the rfc2460bis text in an ambiguous
> state on this topic is a good idea.
> >>>>>
> >>>>> Comments?
> >>>>>
> >>>>> Thanks,
> >>>>> Bob
> >>>>
> >>>> -------- Forwarded Message --------
> >>>> Subject: (IPng 609) changes to Last Call'ed specs
> >>>> Date: Sun, 27 Aug 1995 20:59:26 PDT
> >>>> From: Steve Deering <[e-mail]>
> >>>> To: [e-mail]
> >>>> CC: [e-mail]
> >>>>
> >>>> At the request of our ADs, I prepared the following list of
> >>>> agreed-upon changes and outstanding issues with the set of specs
> >>>> that underwent IETF-wide Last Call in June and July.  Please let me
> >>>> know of any errors or omissions.
> >>>>
> >>>> Steve
> >>>>
> >>>> ===================================
> >>>>
> >>>> IPv6 Specification
> >>>> ------------------
> >>>>
> >>>> The following changes were posted to the IETF list immediately
> >>>> following the Last Call, so I think we can consider them to also have
> been Last Called:
> >>>>
> >>>> - In the examples of how to lay out options, on page 29, two places
> >>>> where it says "Hdr Ext Len=1" should be "Hdr Ext Len=3"
> >>>> (reported by Hamid Asayesh).
> >>>>
> >>>> - In section 6, Flow Labels, I forgot to include the Priority field
> >>>> in the list of fields that must have the same value for all packets
> >>>> in the same flow (reported by Markus Jork).
> >>>>
> >>>> - The description of what the Jumbo Payload Length field covers
> >>>> should be made clearer (reported by Christian Huitema).
> >>>>
> >>>> The following changes were proposed by Charlie Lynn in the only
> "formal"
> >>>> response to the Last Call, and accepted at the first ipngwg meeting
> >>>> in
> >>>> Stockholm:
> >>>>
> >>>> - For options containing data that can change en-route (and which
> >>>> therefore have the third-highest-order bit of their Option Type set
> >>>> to 1), make it clear that *all* bytes of the Option Data field are
> >>>> to be excluded from the Authentication function, and explain that
> >>>> "excluded" means "treated as if they were all zero-valued bytes".
> >>>>
> >>>> - Change the Routing Header to enable it to be ignored by final
> >>>> destinations that do not understand the Routing Type.  In
> >>>> Stockholm, Deering proposed, and the attendees agreed with, the
> >>>> following revised format for the first 32 bits of the Routing Header, for
> all Routing Types:
> >>>>
> >>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>  |  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>>>  |                                                               |
> >>>>
> >>>> where
> >>>>
> >>>> 	Hdr Ext Len   is the length of the header in 8-octet units, not
> >>>> 	              including the first 8 octets
> >>>>
> >>>> 	Segments Left is the number of "legs" left to traverse in the
> >>>>                   route; if this value is zero, the receiver may
> >>>> 	              ignore this header (i.e., it indicates that the
> >>>> 	              route has been completed), whether or not the
> >>>> 	              receiver understands the Routing Type
> >>>>
> >>>> The following additional changes were agreed to either on the
> >>>> mailing list or in the Stockholm meetings:
> >>>>
> >>>> - "Improve" the host/router terminology.  What I propose to do is
> >>>> add a footnote to the terminology section saying something like this:
> >>>>
> >>>> 	* it is possible, though unusual, to have a device with multiple
> >>>>       interfaces configured to forward non-self-destined packets
> >>>>       arriving from some set (fewer than all) of its interfaces, and
> >>>> 	  to discard non-self-destined packets arriving from its other
> >>>> 	  interfaces.  Such a device must obey the protocol requirements
> >>>> 	  for routers when receiving packets from, and interacting with
> >>>> 	  neighbors over, the former (forwarding) interfaces.  It must
> >>>> 	  obey the protocol requirements for hosts when receiving packets
> >>>> 	  from, and interacting with neighbors over, the latter (non-
> >>>> 	  forwarding) interfaces.
> >>>>
> >>>> Comments?
> >>>>
> >>>> - Clarify the operation of Type 0 Routing Header by giving an
> >>>> example, showing the values of the header fields on each segment of
> the route.
> >>>>
> >>>> - Clarify the handling of options, extension headers, Next Header
> >>>> fields, etc. for fragmented packets by giving a few examples of
> >>>> packets before and after fragmentation (suggested by Dimitry Haskins
> and others).
> >>>>
> >>>> - Specify that fragments cannot reassemble to form a jumbogram
> >>>> (suggested by Craig Metz).
> >>>>
> >>>>
> >>>> ICMPv6 Specification
> >>>> --------------------
> >>>>
> >>>> - Add note warning about the possibility of upper-layer header
> >>>> being truncated from the returned packet in an error message, due
> >>>> to large number of extension header bytes, which can defeat
> >>>> delivery of the error message to the guilty upper-layer protocol
> instance.
> >>>>
> >>>> - Delete description of pseudo-header, replacing it with a
> >>>> reference to the description in the IPv6 spec (suggested by
> >>>> Alistair Bell and Marc Hasson).
> >>>>
> >>>> - Correct example of usage of the pointer in the Parameter Problem
> >>>> message on page 15, by changing "48" to "40" (reported by Dimitry
> >>>> Haskins and Francis Dupont).
> >>>>
> >>>> - Note that there is another exception to the "no ICMP error
> >>>> messages in response to multicasts" rule, which is "unrecognized
> option"
> >>>> Parameter Problem messages in response to options with high-order
> >>>> bits "10..." (reported by Dimity Haskins).
> >>>>
> >>>> Address Architecture Document
> >>>> -----------------------------
> >>>>
> >>>> - Add definition of "link-local address" to the terminology section
> >>>> (suggested by Jim Bound).
> >>>>
> >>>> - Specify that "::" is a legal text representation of the
> >>>> Unspecified
> >>>> (all-zeros) Address (suggested by Francis Dupont).
> >>>>
> >>>> ===================================
> >>>>
> >>>> The following suggestions in Charlie Lynn's formal response to the
> >>>> Last Call were rejected at the Stockholm meeting:
> >>>>
> >>>> - Add a bit to the Routing Header indicating whether or not it was
> >>>> inserted into the packet en-route, i.e., by a node other than the
> >>>> packet's originator.
> >>>>
> >>>>   reasons for rejection: insertion of extension headers en-route breaks
> >>>>   PMTU-discovery and can result in ICMP error messages being sent to
> >>>>   non-guilty parties.  The desired effect can be achieved, and those
> >>>>   problems avoided, by using en-route encapsulation (with optional
> >>>>   Routing Header) rather than header insertion.
> >>>>
> >>>> - Change ICMP error messages to contain explicit fields identifying
> >>>> the upper-layer protocol to which the error message should be
> delivered.
> >>>>
> >>>>   reasons for rejection: considered unnecessary complexity to handle
> the
> >>>>   rare case of truncation of transport header from the returned packet
> >>>>   because of too many extension header octets.  Such error messages
> are
> >>>>   still usable for problem diagnosis other than in the upper-layer
> >>>>   itself, e.g., if logged at IPv6 layer or observed in a packet trace.
> >>>>   Will add warning to the ICMPv6 spec about consequences of long
> >>>>   extension header on ICMP error message dispatching.
> >>>>
> >>>> - Change Security Considerations section of ICMPv6 spec to specify
> >>>> when and how to include an Authentication Header in ICMP error
> messages.
> >>>>
> >>>>   reasons for rejection: group consensus that this belongs in aa
> >>>>   IPsec spec instead.
> >>>>
> >>>> ===================================
> >>>>
> >>>> The following issues and suggestions have been discussed on the
> >>>> mailing list since the base specs went to Last Call, but no group
> >>>> consensus on these issues has been reached yet:
> >>>>
> >>>> - Fragmentation issues:
> >>>> 	- change the minimum reassembly buffer size to a number larger
> >>>> 	  than 576?
> >>>> 	- specify that sources of fragmented packets must use the minimal
> >>>> 	  number of fragments required to fit in the perceived PMTU?
> >>>> 	- specify that all fragments with the M bit set must be no less
> >>>> 	  than 7 octets shorter than the perceived PMTU?
> >>>> 	- specify that all fragments with the M bit set must be no shorter
> >>>> 	  than 576 octets?
> >>>> 	- ignore fragments that partially overlap other fragments of the
> >>>> 	  same packet, or discard any packet that arrives as partially
> >>>> 	  overlapping fragments?
> >>>>
> >>>> - Routing Header issues:
> >>>> 	- add a "Total Length" field to the fragment header, carrying the
> >>>> 	  length of the original, unfragmented packet?
> >>>> 	- forbid forwarding of packets with Routing Headers by hosts?
> >>>> 	  (if not, make it clearer that hosts are expected to forward
> >>>> 	  packets with Routing Headers, if they are intermediate targets
> >>>> 	  of such packets.)
> >>>> 	- specify the reversing rules for packets that are responses to
> >>>> 	  packets that carry a Routing Header?
> >>>> 	- forbid or discourage reversal of an unauthenticated Routing
> Header?
> >>>> 	- forbid or discourage acceptance of a packet with an
> unauthenticated
> >>>> 	  Routing Header?
> >>>>
> >>>> - Allow the transport-layer checksum to be omitted when the
> >>>> Authentication header (or the ESP header?) is being used?
> >>>>
> >>>> - Add a Congestion Indication bit to the base IPv6 header?
> >>>>
> >>>> - Add MUST/SHOULD/MAY conformance requirements for all IPv6 fields
> >>>> and functions?
> >>>>
> >>>> - Build a single Terminology document, to be shared (either by
> >>>> reference or inclusion) in all IPv6-related specs?
> >>>>
> >>>> - Allow the use of zero in the UDP Length field to indicate that
> >>>> the UDP length should be derived from the Jumbogram Option?
> >>>>
> >>>> Note: the above list does not include issues concerning those specs
> >>>> that have not yet been subjected to WG or IETF Last Call, e.g., the
> >>>> Neighbor Discovery spec.
> >>>>
> >>>> ------------------------------------------------------------------------------
> >>>> IETF IPng Mailing List		      FTP archive:
> ftp.parc.xerox.com:/pub/ipng
> >>>> IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-
> main.html
> >>>> Direct all administrative requests to [e-mail]
> >>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> - IETF IPv6 working group mailing list [e-mail] Administrative
> >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> -------------------------------------------------------------------
> >>>> -
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list [e-mail] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------