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

From: Bob Hinden <[email-masked]>
Date: Wed, 27 Apr 2016 18:18:47 -0700

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.

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Apr 2016 23:21:47 -0300

On 04/27/2016 10:18 PM, 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 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.
> 
> 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).
> 

FWIW, I agree with the comments you made above. (the spec should be
clarified, and if there is going to be a change to allow the insertion
of EHs, that should be the result of an explicit proposal to change
rfc2460 or rfc2460bis).

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Mark Smith <[email-masked]>
Date: Thu, 28 Apr 2016 13:17:47 +1000

Hi Bob,

On 28 Apr 2016 11:19 AM, "Bob Hinden" <[email-masked]> 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 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.
> 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.

I agree with being more strict, although I personally don't find the second
and third paragraphs in the Extension Headers section on this topic (after
the diagrams) to be ambiguous.

I think there is some ambiguity about what specific actions are involved in
"forwarding" (of both unicast and multicast) which has probably created the
gap that people who want to add EHs have jumped thorough.

Different sections permit certain things during forwarding e.g., increment
hop count, change flow label etc., however I haven't come across a
specific section in this RFC or any others that specifically define the
complete set of actions involved in IPv6 "forwarding".

Regards,
Mark.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Apr 2016 15:26:35 +1200

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

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

    Brian

-------- Forwarded Message --------
Subject: (IPng 609) changes to Last Call'ed specs
Date: Sun, 27 Aug 1995 20:59:26 PDT
From: Steve Deering <[email-masked]>
To: [email-masked]
CC: [email-masked]

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

---

From: Tim Chown <[email-masked]>
Date: Thu, 28 Apr 2016 08:33:36 +0000

Hi,

> On 28 Apr 2016, at 04:26, Brian E Carpenter <[email-masked]> wrote:
> 

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

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 28 Apr 2016 14:33:50 +0000

> On Apr 28, 2016, at 10:33 AM, Tim Chown <[email-masked]> wrote:
> 
> Hi,
> 
> 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. 

s.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 28 Apr 2016 08:45:12 -0700

> However, I do not think leaving the rfc2460bis text in an ambiguous state on this topic is a good idea.

Bob,

I agree that this should be clarified and extension headers cannot be
inserted that change the length. It might be reasonable to allow
insertion if it doesn't change the packet length though-- specifically
I am thinking that a host might be able to set PadN to make space that
can be overwritten in the path for inserted EHs. This allows insertion
without changing the packet length or meaning of existing headers.

Also, per:

"IP Encapsulation must be used to meet any requirement for inserting
headers, for example, as defined in [RFC2473].

I don't think proposing encapsulation as an alternative to insertion
is normative. It won't necessarily have the same effect and it
introduces issues regarding encapsulation. I think this statement can
just be omitted from rfc2460bis without loss of clarity.

Tom

---

From: Tim Chown <[email-masked]>
Date: Thu, 28 Apr 2016 15:48:32 +0000

> On 28 Apr 2016, at 15:33, Stefano Previdi (sprevidi) <[email-masked]> wrote:
> 

And usage that is not being standardised within the IETF, or is it?  

Tim

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 28 Apr 2016 15:57:00 +0000

> On Apr 28, 2016, at 5:48 PM, Tim Chown <[email-masked]> wrote:
> 

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.

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 28 Apr 2016 16:23:01 +0000

Bob,

Maybe we should change the MUST NOT to a SHOULD NOT. The statement should explain that in many operational scenarios, insertion of extension headers by transit nodes can break PMTUD. However, in operational scenarios where this is not a problem, it is OK for transit nodes to insert extension headers.

                                                                         Ron

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Wednesday, April 27, 2016 9:19 PM
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>
> Subject: Inserting Extension Headers or not [was rfc2460bis question ]
> 
> 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 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
> 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).
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 28 Apr 2016 12:31:32 -0400

> On Apr 28, 2016, at 12:23 PM 4/28/16, Ronald Bonica <[email-masked]> wrote:
> 
> Bob,
> 

I think it should remain MUST NOT.  In addition to PMTUD, there is the problem of inserted headers causing ICMP notifications being delivered to a host that is unaware of the case of the problem.

- Ralph

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Apr 2016 13:34:50 -0300

On 04/28/2016 01:23 PM, Ronald Bonica wrote:
> Bob,
> 
> Maybe we should change the MUST NOT to a SHOULD NOT. The statement
> should explain that in many operational scenarios, insertion of
> extension headers by transit nodes can break PMTUD. However, in
> operational scenarios where this is not a problem, it is OK for
> transit nodes to insert extension headers.

mmm... I guess you don't need ietf permission to violate the specs in
your own walled garden?

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: 神明達哉 <[email-masked]>
Date: Thu, 28 Apr 2016 10:57:15 -0700

At Wed, 27 Apr 2016 18:18:47 -0700,
Bob Hinden <[email-masked]> wrote:

> inserted. [...]

> state on this topic is a good idea.

I agree with these: The 'personal view' of yours also matches my
interpretation of the original intent.  I also agree it's better to
describe it explicitly.

I have one additional question: what about removing an extension
header?  The rationale for PMTU doesn't apply in this case, but it
would generally break AH, and I thought the "original intent" also
includes prohibiting non-source nodes from removing an extension
header.

> to rfc2460bis (after it is published).

I'm fine with this.

--
JINMEI, Tatuya

---

From: Michael Richardson <[email-masked]>
Date: Thu, 28 Apr 2016 14:41:06 -0400

Bob Hinden <[email-masked]> wrote:
    > rfc2460bis.  This topic was discussed in Buenos Aires and on the
    > mailing list.

I read the read of the thread.
There are three issues, I think, why back in 1995 we declared that
no headers shall be inserted or removed.

1) ICMP errors going to the wrong place.
   Are we specifically talking about ICMP too big messages, or are there
   other ICMP errors that the header-inserting router needs to know about?

2) causing packets to grow too much, causing PMTUD issues

3) breaking AH in transit.
   While AH can deal with mutable headers, it can not deal with
   new extension headers being added/deleted.
   While the SRH-types who want to insert headers seem to also intend
   to remove them before delivery, I'm concerned that this process might
   at times not be byte-for-byte identical, yet be semantically equivalent.
   (I don't have an example right now)

My initial take is that PMTUD via ICMP message is broken, and isn't getting
fixed anytime soon.  PLPMTUD works well (once you get it turned on), we just
need a way to generalize it to non-TCP/non-SCTP users, and provide it as a
kernel service to applications.

If we remove PMTUD as a reason, and we can believe that AH won't be
corrupted, then I think going from MUST NOT to SHOULD NOT is reasonable.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mark Smith <[email-masked]>
Date: Fri, 29 Apr 2016 08:11:04 +1000

>     > I would like to get closure on the question if inserting IPv6
extension
>    (I don't have an example right now)

4) troubleshooting modifications that cannot or cannot easily be attributed
to a specific node can be very time-consuming, require out of hours work
and are likely to require potentially disruptive packet capturing within or
downstream of each network element that could have modified the packet
(assuming it is possible to access that NE or link).

5) the source address has lost its semantics if more than one node is
responsible for the contents of the packet (within a layer) - it is now a
multi-source packet, yet only one source is recorded. This is what makes
troubleshooting hard, and causes things like PMTUD to fail - the inability
to completely attribute creation or modification of the parts of the packet
to the respective sources.

In the encapsulation model, devices that add to a packet(/frame) also add a
source identification field to record their identity as the source of those
additions.

Regards,
Mark.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 28 Apr 2016 15:20:05 -0700

Tom,

> On Apr 28, 2016, at 8:45 AM, Tom Herbert <[email-masked]> wrote:
> 

This is possible, but would have to be documented including how a host would know to do that.  I don’t think that is appropriate for rfc2460bis.

> just be omitted from rfc2460bis without loss of clarity.

Perhaps changing the text to citing encapsulation as an example would work.

Other views?

Bob

---

From: Bob Hinden <[email-masked]>
Date: Thu, 28 Apr 2016 15:24:36 -0700

Jinmei-san,

> On Apr 28, 2016, at 10:57 AM, 神明達哉 <[email-masked]> wrote:
> 

I was planning to come back to that question, after we get through the inserting extension header question.

Thanks,
Bob

---

From: Mark Smith <[email-masked]>
Date: Fri, 29 Apr 2016 08:27:06 +1000

> >> 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.
> This is possible, but would have to be documented including how a host
would know to do that.  I don’t think that is appropriate for rfc2460bis.
> Perhaps changing the text to citing encapsulation as an example would
work.

+1

Ideally an example where an EH is added between the outer IPv6 header and
the inner one - actually GRE would probably do as one example.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Apr 2016 12:37:29 +1200

> I think it should remain MUST NOT.  In addition to PMTUD, there is the problem of inserted headers causing ICMP notifications being delivered to a host that is unaware of the case of the problem.

Agreed. A "should not" would be a change, a "must not" is a clarification of intent.

> mmm... I guess you don't need ietf permission to violate the specs in

Since the protocol police have been very quiet recently, that is a fact of
life. However, if we want to be explicit about it (after 2460bis) we could
write it up. Diffserv already allows domain-specific packet mutations; the
flow label tolerates mutations in certain circumstances. I don't see why
we couldn't also describe the circumstances in which other header mutations
are allowed. But first, define the precise meaning of "the open Internet."

   Brian

---

From: Tom Herbert <[email-masked]>
Date: Thu, 28 Apr 2016 18:56:36 -0700

> I think it should remain MUST NOT.  In addition to PMTUD, there is the problem of inserted headers causing ICMP notifications being delivered to a host that is unaware of the case of the problem.
+1. This is probably the biggest issue with inserting EH and really is
a strong argument that generally header fields should not be modified
in the network. If such a modification ever causes a packet loss in a
downstream node I don't see any way to address the problem. The node
making the modification would not receive an ICMP error or other
feedback; the source node would get an ICMP for a packet with headers
it didn't send and therefore can't take any corrective action either.

Tom

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 29 Apr 2016 07:49:13 +0000

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

> From: ipv6 [mailto:[email-masked]] On Behalf Of Stefano Previdi
> (sprevidi)
> Sent: jeudi 28 avril 2016 17:57
> To: Tim Chown <[email-masked]>
> Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
> Subject: Re: Inserting Extension Headers or not [was rfc2460bis question ]
> 
> 
> 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.
> >>>>>
> >>>>> 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].
> >>>>>
> would allow it to be part of rfc2460bis going to Internet Standard.  If it is a
> change, then it should not be included.
> >>>>>
> 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
> >>>> 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.
> >>>>
> >>> 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.
> >
> 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.
> 
> >>>> 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
> >>>>
> >>>> 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 list of fields that must have the same value for all packets
> >>>> in the same flow (reported by Markus Jork).
> >>>>
> >>>> - 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:
> >>>>
> >>>> 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:
> >>>>
> >>>> - 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).
> >>>>
> >>>> - Note that there is another exception to the "no ICMP error
> >>>> messages in response to multicasts" rule, which is "unrecognized
> option"
> >>>> The following suggestions in Charlie Lynn's formal response to the
> >>>> Last Call were rejected at the Stockholm meeting:
> >>>>
> >>>> - Change ICMP error messages to contain explicit fields identifying
> >>>> the upper-layer protocol to which the error message should be
> delivered.
> >>>>
> >>>> - Change Security Considerations section of ICMPv6 spec to specify
> >>>> when and how to include an Authentication Header in ICMP error
> messages.
> >>>>
> >>>> 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:
> >>>> - Allow the transport-layer checksum to be omitted when the
> >>>> Authentication header (or the ESP header?) is being used?
> >>>>
> >>>> - 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 IPv6 working group mailing list [email-masked] Administrative
> >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> IETF IPv6 working group mailing list [email-masked] Administrative
> >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Apr 2016 12:56:14 -0400

Mark Smith <[email-masked]> wrote:
    >> 3) breaking AH in transit.  While AH can deal with mutable headers, it

    > 4) troubleshooting modifications that cannot or cannot easily be
    > attributed to a specific node can be very time-consuming, require out
    > of hours work and are likely to require potentially disruptive packet
    > capturing within or downstream of each network element that could have
    > modified the packet (assuming it is possible to access that NE or
    > link).

I take your point very clearly.
In some sense, I'm including this as "breaking AH", as this is my major
concern.  Something happens in the middle, and packets break, and we can't
find out why/where it happened.

But, given that we have mutable headers, isn't this an issue ANYWAY?
Can we trust that only routers that are inserting headers (via encapsulation
or not) are really the only ones that are potentially broken?

Or to put it another way: given where we are in IPv6 deployment, particularly
for some of the more exotic (non-IPv4-like) features, is there any field
experience that the encapsulation actually helped do the diagnosis?  Or
is our experience limited to disasters that happened in IPv4-land?

I have a side modification to the proposal that I'll put in another email.

    > responsible for the contents of the packet (within a layer) - it is now
    > a multi-source packet, yet only one source is recorded. This is what
    > makes troubleshooting hard, and causes things like PMTUD to fail - the
    > inability to completely attribute creation or modification of the parts
    > of the packet to the respective sources.

I don't agree that it's what makes PMTUD fail.
Stupid ICMP filters at large insitutions is what killed it.
I could name the product which is regularly misconfigured by people who
aren't reading this list, nor any NOG list, but I won't.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Apr 2016 13:08:29 -0400

If we decide that it's okay insert extension headers, then I suggest that
only extension headers that have a Option Type top-two-bits that are
"01" should be insertable.
The third bit, mutable, MUST be set, I think.

(You may be able to convince me that it should "11" rather than "01")

My logic is that current devices that observe 2460 will drop packets with
this Option Type, which is a really good defense against that header that was
inserted, failing to be removed.

Second, newer devices that observe 2460bis, could instead of dropping that
extension, could rather remove/omit that extension header completely.  This
would probably permit AH to continue to work even if the header wasn't
removed.

(I'd love to also change the behaviour of AH so that one would ignore AH
headers if one hasn't got a matching SPI#. That's what kept us from using AH
to secure ND back in the SEND days)

The LLN uses of insertable extension headers benefit greatly by inserting
what they need, and not worrying about removing things before they get to the
host.

=====

And, it seems that "10", which creates ICMP Parameter Problem messages
for multicast destinations, allows for amplication attacks, and we should
deprecate that behaviour, period.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 29 Apr 2016 19:05:31 +0000

Hello Mark:

Ø  4) troubleshooting modifications that cannot or cannot easily be attributed to a specific node can be very time-consuming, require out of hours work and are likely to require potentially disruptive packet capturing within or downstream of each network element that could have modified the packet (assuming it is possible to access that NE or link).

DetNet has the concept of Replication and Elimination, which created intermediate sources and sinks, and certainly observed that need.

We noted that answer is not necessarily to avoid playing with header. It can also be to provide traceability on what happened to the packet, who did what.

https://tools.ietf.org/html/draft-dt-detnet-dp-alt-00#section-4.2.7.2 provides a way of doing that in the detnet space that avoids unwanted chattiness.

Cheers,

Pascal

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Apr 2016 22:08:10 -0300

On 04/28/2016 09:37 PM, Brian E Carpenter wrote:
> write it up.

I fully agree. What I meant is: the fact that you could potentially make
something work in a walled garden doesn't seem an argument to legitimize
that behavior -- particularly when I guess we're supposed to be
standarizing more for the general case than for the walled garden case.

> Diffserv already allows domain-specific packet mutations; the

Have this mutations the same potential implications as the
insertion/removal of EHs?

Thanks,