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

[Tim Chown <[e-mail]>]

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

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