Subject: [Technical Errata Reported] RFC8200 (5933)

From: RFC Errata System <[email-masked]>
Date: Tue, 10 Dec 2019 19:27:24 -0800 (PST)

The following errata report has been submitted for RFC8200,
"Internet Protocol, Version 6 (IPv6) Specification".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5933

--------------------------------------
Type: Technical
Reported by: Fernando Gont <[email-masked]>

Section: 4

Original Text
-------------
   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  The Hop-by-Hop Options header, when present, must
   immediately follow the IPv6 header.  Its presence is indicated by the
   value zero in the Next Header field of the IPv6 header.

Corrected Text
--------------
   Extension headers (except for the Hop-by-Hop Options header, or a 
   Destination Options header preceding a Routing header) are not processed,
   inserted, or deleted by any node along a packet's delivery path, until the
   packet reaches the final destination node (or each of the set of final
   destination nodes, in the case of multicast). 

   For packets that do not include a Routing Header, the final destination
   node is identified by the Destination Address field of the IPv6 header. 
   For packets that include a Routing Header, the final destination node is 
   identified by the Destination Address field of the IPv6 header only when
   the Segments Left field of the Routing Header is 0. 

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the final destination node (or each of the set of
   final destination nodes, in the case of multicast). The Hop-by-Hop Options 
   header, when present, must immediately follow the IPv6 header.  Its 
   presence is indicated by the value zero in the Next Header field of the 
   IPv6 header.

   A Destination Options header preceding a Routing Header is not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the destination node (or each of the set 
   of destination nodes, in the case of multicast) identified by the 
   Destination Address field of the IPv6 header. This means that  a 
   Destination Options header preceding a Routing Header will be
   processed by the first destination of the packet (specified by the
   Destination Address field of the IPv6 header at the origin node) and by 
   each node listed in the Routing Header.

Notes
-----
This errata clarifies two different issues:

* It clarifies that nodes other than the final destination do not insert o remove extension headers.

* It clarifies that the Destination Options header preceding a routing header *is* processed along the
   packet delivery's path, but the node(s) identified by the Destination Address of the IPv6 header.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8200 (draft-ietf-6man-rfc2460bis-13)
--------------------------------------
Title               : Internet Protocol, Version 6 (IPv6) Specification
Publication Date    : July 2017
Author(s)           : S. Deering, R. Hinden
Category            : INTERNET STANDARD
Source              : IPv6 Maintenance
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Dec 2019 22:32:47 -0500

Folks,

I gave the relevant text yet another look and, besides the possible
clarification regarding the "intermmediate destinations", I've found a
bug in the corresponding text.

Namely, the text in RFC8200 rules out the processing of a Destination
Options header along the packet delivery's path *by the nodes listed in
a Routing Header*. That's of course an error -- otherwise there's no
point in including a Destination Options  header that precedes a routing
header.

The errata I've submitted clarifies the first item, and fixes the second.

Thanks,
Fernando

On 10/12/19 22:27, RFC Errata System wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 Dec 2019 08:44:40 +0100

Le 11/12/2019 à 04:27, RFC Errata System a écrit :
>     inserted, or deleted by any node along a packet's delivery path,

packet delivery path, slow path... two very distinct concepts.  One is 
in the network with real cables, the other is in a chip or on a bus with 
copper on a printed board.

>    until the

This final destination is somehow a strange concept.  It can be a 
computer node that owns several addresses.  But this is difficult with 
virtualization.  Owning one address is difficult to prove as well.

In that sense, it would help to clarify the concept of 'final 
destination' by maybe using a tight relationship between an IP address 
and an identifier of a node.  Such an identifier could be a number in 
the BIOS, or something from a TPM or HSM (trust modules).

Otherwise, I can still interpret that clarification as allowing 
intermediary nodes to insert/remove EHs.

Alex

---

From: Tom Herbert <[email-masked]>
Date: Wed, 11 Dec 2019 07:50:48 -0800

> virtualization.  Owning one address is difficult to prove as well.
Agreed. This could also be contorted to mean that the lower part of
the stack in final destination node might be allowed to insert
extension headers in a packet before delivering to the application. I
think it's more direct to simply say that inserting or removing
extension headers is not allowed at any node. A source node creates
packet with them, it doesn't insert them. Similarly, the final
destination discards extension headers after processing them as part
of the normal terminal processing of the packet, it doesn't remove
them.

I suggest this text:

"The source node of a packet, identified by the source address, may
include extension headers in a packet when it is created. Extension
headers must not be inserted or removed, and the length of any
extension header must not be changed, by any node for the lifetime of
the IPv6 packet. Note that it follows from these requirements that the
length of an IPv6 packet cannot change once the packet has been
created by the source node.

Extension headers (except for the Hop-by-Hop Options header) must not
be processed by any node along a packet's delivery path, until the
packet reaches the final destination node (or each of the set of final
destination nodes, in the case of multicast).

For packets that do not include a Routing Header, the final
destination node is identified by the Destination Address field of the
IPv6 header. For packets that include a Routing Header, the final
destination node is identified by the Destination Address field of the
IPv6 header only when the Segments Left field of the Routing Header is
0.

The Hop-by-Hop Options header may be examined or processed by any node
along a packet's delivery path including the final destination node
(or each of the set of final destination nodes, in the case of
multicast). The Hop-by-Hop Options header, when present, must
immediately follow the IPv6 header. Its presence is indicated by the
value zero in the Next Header field of the IPv6 header.

A Destination Options header preceding a Routing Header must not
processed by any node along a packet's delivery path, until the packet
reaches the destination node (or each of the set of destination nodes,
in the case of multicast) identified by the Destination Address field
of the IPv6 header. This means that a Destination Options header
preceding a Routing Header will be processed by the first destination
of the packet (specified by the Destination Address field of the IPv6
header at the origin node) and by each node listed in the Routing
Header."

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Dec 2019 17:57:36 -0500

On 11/12/19 02:44, Alexandre Petrescu wrote:
> packet delivery path, slow path... two very distinct concepts. 

Not sure what you mean. The errata does not mention "slow path".

>> destination
> This final destination is somehow a strange concept. 

I used "final destination" to avoid confusion wrt "waypoints" in a
routing header.

> It can be a

Ńot sure where the confusion is.If you are the IP module that has been
assigned that final destination address, you are the final destination.

> the BIOS, or something from a TPM or HSM (trust modules).

Obviously, such concepts escape IPv6. IN IPv6 you ahve IPv6 addressses
assigned to hosts or routers. How you implement them is irrelevant.

> intermediary nodes to insert/remove EHs.

Could you please elaborate?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Dec 2019 18:19:10 -0500

On 11/12/19 10:50, Tom Herbert wrote:
[.....]
>> This final destination is somehow a strange concept. 

It's already used in other parts of RFC8200, albeit inconsistently.

> extension headers in a packet before delivering to the application.

What matters is IPv6. What sources IPv6 packets is the origin IPv6
module, and the destination of IPv6 packets is the IPv6 module at the
final destination.

> I
> extension headers is not allowed at any node. 

Yep, that's possible. FWIW, I reused as much of whats in RFC8200 as
possible.

The key is that since the phrase also includes "process", it can be
phrased as you suggest -- unless you unfold it in "insert or delete" and
"process", as you seem to suggest.

> header at the origin node) and by each node listed in the Routing

The text looks fine. I just hope that folks don't claim that, since the
EH-specific text only forbids "processing", insertion and deletion is
allowed (even when the catch-all text above says they cannot).

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Dec 2019 15:07:58 +1300

On 11-Dec-19 16:27, RFC Errata System wrote:
...

> Corrected Text

I'm seeing a problem here. The Segments Left field of the routing header
must be decremented at the end of each segment. That's processing the
RH in my book, and it will occur when Segments Left >0.

   Brian

> .

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Dec 2019 21:50:47 -0500

On 11/12/19 21:07, Brian E Carpenter wrote:
> ....

It seems the problem is not related with this text, but rather with the
fact that it omits RH-specific text as for the HbHO and DO headers.

i.e., HbhO, DO that precedes a routing header, and the routing header
are exceptions to the rule.

(The text regarding SL==0 is because it's essentially impossible to tell
where in the type-specific data of a RH the final destination will be).

So.. how about if the text above is expanded to "Extension headers
(except for the Hop-by-Hop Options header, the ROuting Header, or a
Destination Options header preceding a Routing header)"

...and then RH-specific text (similar as for HbH or DO that precedes a
RH) is added?

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Dec 2019 17:22:44 +1300

Yes, a note that updating Segments Left is legal would fix it I think.

Regards
   Brian Carpenter

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Dec 2019 11:12:33 +0100

Le 11/12/2019 à 16:50, Tom Herbert a écrit :
>>> -------------------------------------- You may review the report 
>>> below and at: https://www.rfc-editor.org/errata/eid5933
>>> 
>>> -------------------------------------- Type: Technical Reported 
>>> by: Fernando Gont <[email-masked]>
>>> 
>>> Section: 4
>>> 
>>> Original Text ------------- Extension headers (except for the 
>>> Hop-by-Hop Options header) are not processed, inserted, or 
>>> deleted by any node along a packet's delivery path, until the 
>>> packet reaches the node (or each of the set of nodes, in the
>>> case of multicast) identified in the Destination Address field of
>>> the IPv6 header.
>>> 
>>> The Hop-by-Hop Options header is not inserted or deleted, but
>>> may be examined or processed by any node along a packet's
>>> delivery path, until the packet reaches the node (or each of the
>>> set of nodes, in the case of multicast) identified in the
>>> Destination Address field of the IPv6 header.  The Hop-by-Hop
>>> Options header, when present, must immediately follow the IPv6
>>> header.  Its presence is indicated by the value zero in the Next
>>> Header field of the IPv6 header.
>>> 
>>> 
>>> Corrected Text -------------- Extension headers (except for the 
>>> Hop-by-Hop Options header, or a Destination Options header 
>>> preceding a Routing header) are not processed, inserted, or 
>>> deleted by any node along a packet's delivery path,
>> 
>> One is in the network with real cables, the other is in a chip or
>> on a bus with copper on a printed board.
>> 
>>> until the packet reaches the final destination node (or each of 
>>> the set of final destination nodes, in the case of multicast).
>>> 
>>> destination node is identified by the Destination Address field 
>>> of the IPv6 header. For packets that include a Routing Header, 
>>> the final destination node is identified by the Destination 
>>> Address field of the IPv6 header only when the Segments Left 
>>> field of the Routing Header is 0.
>>> 
>>> The Hop-by-Hop Options header is not inserted or deleted, but
>>> may be examined or processed by any node along a packet's
>>> delivery path, until the packet reaches the final destination
>>> node (or each of the set of final destination nodes, in the case
>>> of multicast). The Hop-by-Hop Options header, when present, must 
>>> immediately follow the IPv6 header.  Its presence is indicated
>>> by the value zero in the Next Header field of the IPv6 header.
>>> 
>>> processed, inserted, or deleted by any node along a packet's 
>>> delivery path, until the packet reaches the destination node (or 
>>> each of the set of destination nodes, in the case of multicast) 
>>> identified by the Destination Address field of the IPv6 header. 
>>> This means that  a Destination Options header preceding a
>>> Routing Header will be processed by the first destination of the
>>> packet (specified by the Destination Address field of the IPv6
>>> Header.
>>> Notes ----- This errata clarifies two different issues:
>>> 
>> computer node that owns several addresses.  But this is difficult 
>> with virtualization.  Owning one address is difficult to prove as 
>> well.
>> 

Right.

That means that a new item could be part of the list of limited domains
(currently Enterprise and Computer Farm).  That new item is the limited
domain made of layers of a single stack.  Within such a limited domain,
it might be allowed for stacks to 'mangle' packets and insert or delete.

> I think it's more direct to simply say that inserting or removing 

I agree.

> A source node creates packet with them, it doesn't insert them.
> Similarly, the final destination discards extension headers after
> processing them as part of the normal terminal processing of the
> packet, it doesn't remove them.
> 
> I suggest this text:
> 
                                               ^^ other: any _other_ node
> the IPv6 packet. Note that it follows from these requirements that 
> the length of an IPv6 packet cannot change once the packet has been 

I agree.  That is a typical requirement following from the Smart End 
Dumb Network principle.  It is also told as "packets are not modified 
en-route, with the only exceptions of decrementing the Hop Limit field, 
and the Segments Left field if present".

One example that modifies packets en-route is the modification of the 
src address.  This is forbidden.

Another example that does not modify packets en-route, but creates other 
packets by incorporating the untouched orignal is the ESP encapsulation 
of VPN Gateways.  This is allowed.

(I might be repeating what was told numerous times, already).

Alex

> packet reaches the final destination node (or each of the set of 
> final destination nodes, in the case of multicast).
> 
> destination node is identified by the Destination Address field of 
> the IPv6 header. For packets that include a Routing Header, the final
> destination node is identified by the Destination Address field of
> the IPv6 header only when the Segments Left field of the Routing 
> Header is 0.
> 
> The Hop-by-Hop Options header may be examined or processed by any 
> node along a packet's delivery path including the final destination 
> node (or each of the set of final destination nodes, in the case of 
> processed by any node along a packet's delivery path, until the 
> packet reaches the destination node (or each of the set of 
> destination nodes, in the case of multicast) identified by the 
> Destination Address field of the IPv6 header at the origin node) and 
> by each node listed in the Routing Header."
> 
>> destination' by maybe using a tight relationship between an IP 
>> address and an identifier of a node.  Such an identifier could be
>> a number in the BIOS, or something from a TPM or HSM (trust 
>> modules).
>> 
>>> * It clarifies that the Destination Options header preceding a 
>>> routing header *is* processed along the packet delivery's path, 
>>> but the node(s) identified by the Destination Address of the
>>> IPv6 header.
>>> 
>>> Instructions: ------------- This erratum is currently posted as 
>>> "Reported". If necessary, please use "Reply All" to discuss 
>>> whether it should be verified or rejected. When a decision is 
>>> reached, the verifying party can log in to change the status and 
>>> edit the report, if necessary.
>>> 
>>> -------------------------------------- RFC8200 
>>> (draft-ietf-6man-rfc2460bis-13) 
>>> -------------------------------------- Title               : 
>>> Internet Protocol, Version 6 (IPv6) Specification Publication 
>>> Date    : July 2017 Author(s)           : S. Deering, R. Hinden 
>>> Category            : INTERNET STANDARD Source              : 
>>> IPv6 Maintenance Area                : Internet Stream : IETF
>>> Verifying Party     : IESG
>>> 
>>> [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: Fernando Gont <[email-masked]>
Date: Thu, 12 Dec 2019 00:45:31 -0500

> Yes, a note that updating Segments Left is legal would fix it I think.

It would seems to me that more is needed. For instance, for RHT0 you had
to swap the address in the Destination Address with  with the next
segment in the RHT0 payload.

So I guess the text should look something like:

    A Routing Header is not inserted, or deleted by any node along a
    packet's delivery path, until the packet reaches the final
    destination node (or each of the set of final destination nodes, in
    the case of multicast). A Routing Header is not processed by any
    node along a packet's delivery path, until the packet reaches the
    destination node (or each of the set of destination nodes, in the
    case of multicast) identified by the Destination Address field of
    the IPv6 header.

?

I wonder if it might be better to keep the insertion/deletion part in a
single place, to avoid repetiton, and then just discuss processing, but
not insertion/deletion.  -- Or whether repetition is needed for each of
the "special" EHs, such that folk do not assume that the comments on
insertion/deletion do not applyto the "special" EHs.

Thoughts?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Dec 2019 12:38:11 -0500

On 12/12/19 05:12, Alexandre Petrescu wrote:
[....]
>>> with virtualization.  Owning one address is difficult to prove as well.
>>>
> (currently Enterprise and Computer Farm). 

THere's no IETF consensus for limited domains. SO I have no idea how
that could/should influence RFC8200.

[....]
>> extension headers is not allowed at any node.

We could do that, and then only comment on the "processing" bit for the
various Extension Headers.

> src address.  This is forbidden.

HOw is this related to what we're discussing?

> of VPN Gateways.  This is allowed.

That's encapsulation. We're talking about EH
insertion7removal/processing here.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Dec 2019 08:32:54 +1300

On 13-Dec-19 06:38, Fernando Gont wrote:
> THere's no IETF consensus for limited domains. 

Correct, but they do exist in the real world ;-)

> SO I have no idea how

Actually there are a lot of IETF standards with explicit support for local
features, and there are a lot of uses of locally significant parameter
values. So IPv6 *could have been* specified to support local features,
but it wasn't. That's where we are.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Dec 2019 09:12:15 +1300

> segment in the RHT0 payload.

Yes, decrementing Segments Left presumably applies to all routing headers,
but you are correct that other changes might be specified.

>     case of multicast) identified by the Destination Address field of

OK

> insertion/deletion do not applyto the "special" EHs.

I would prefer spelling it out in detail to avoid doubt.

   Brian

---

From: Ron Bonica <[email-masked]>
Date: Thu, 12 Dec 2019 22:52:35 +0000

+1

Juniper Business Use Only

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Thursday, December 12, 2019 3:12 PM
To: Fernando Gont <[email-masked]>; [email-masked]
Subject: Re: [Technical Errata Reported] RFC8200 (5933)

On 12-Dec-19 18:45, Fernando Gont wrote:
> It would seems to me that more is needed. For instance, for RHT0 you 
> had to swap the address in the Destination Address with  with the next 

Yes, decrementing Segments Left presumably applies to all routing headers, but you are correct that other changes might be specified.

OK

> 
> I wonder if it might be better to keep the insertion/deletion part in 
> a single place, to avoid repetiton, and then just discuss processing, 
> but not insertion/deletion.  -- Or whether repetition is needed for 
> each of the "special" EHs, such that folk do not assume that the 
> comments on insertion/deletion do not applyto the "special" EHs.

   Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!REDMXseBMtBnWm9mHLtbVcZF-3UkNU3T_oo5-Hof3Vm5oA0V-nsqZhw_Jj57og_c$
--------------------------------------------------------------------

---

From: Loa Andersson <[email-masked]>
Date: Fri, 13 Dec 2019 12:03:17 +0800

Brian,

On 13/12/2019 03:32, Brian E Carpenter wrote:
> Correct, but they do exist in the real world;-)
> 

Undoubtedly - some years ago we had walled gardens as an example.

However, as long as we don't have a consensus it is hard to standardize
built on this concept.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 13 Dec 2019 10:08:50 +0100

Le 12/12/2019 à 06:45, Fernando Gont a écrit :
> not insertion/deletion.

I think indeed the insertion/deletion part would deserve a single place 
for its own.  It should be clear by reading it in one place that 
intermediaries (routers in a 15 hop path in the Internet, exhibited by 
traceroute) do not touch a packet originated by an end node other than 
decrementing the Hop Limit and Segments Left, if present.

>  -- Or whether repetition is needed for each of

Suffices it to say _all_ EHs in one place.  But then one has to define 
what is an EH.  'EH' is an acronym used exclusively in email 
discussions, currently.  I took it for an AH version when first saw it.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 13 Dec 2019 10:20:56 +0100

Le 12/12/2019 à 20:32, Brian E Carpenter a écrit :
>> On 12/12/19 05:12, Alexandre Petrescu wrote: [....]
>>>>> 
>>>>> This final destination is somehow a strange concept.  It can
>>>>> be a computer node that owns several addresses.  But this is
>>>>> difficult with virtualization.  Owning one address is
>>>>> difficult to prove as well.
>>>>> 
>>>> Agreed. This could also be contorted to mean that the lower
>>>> part of the stack in final destination node might be allowed to
>>>> insert extension headers in a packet before delivering to the
>>>> application.
>>> 
>>> Right.
>>> 
>>> That means that a new item could be part of the list of limited
>>> domains (currently Enterprise and Computer Farm).
>> 
>> SO I have no idea how that could/should influence RFC8200.
> 
> Actually there are a lot of IETF standards with explicit support for
> local features, and there are a lot of uses of locally significant
> parameter values. So IPv6 *could have been* specified to support
> local features, but it wasn't. That's where we are.

I agree IPv6 could have been specified to support local features, and
that's where we are.  It is a positive note.

I would like to extend it with another positive note.

RH0 (Routing Header type 0) was mandated in RFC2460.  It was
subsequently used in other specs and implementations, like Mobile IPv6.
  It hurt to see it disappear in RFC8200, but there must be reasons for
that.  These reasons seem important.

Other spec and implementation trying variations of routing headers is
RPL.  It is today in the same state: no widespread deployment, has
security issues, but is rather ok in a limited domain.

I now wonder whether the SRH concepts take these reasons into account
(RFC5095ish on security of Routing Header), and lack of deployment on a
wide scale.

If not, then we risk arriving at the same situation as with RH0: spec
it, implement it, realize its lack of security and deployment, and then
get rid of it.  I do not know what are the encouraging things about SRH
such as to hope it will be better than RH0 and will not lead to an
RFC15095ish that deprecates SRH.

The idea to remove Segments Left altogether from RFC8200 is something
that could be considered.

Alex

> 
> Brian
> 
>> 
>> 
>> 
>> [....]
>>>> I think it's more direct to simply say that inserting or
>>>> removing extension headers is not allowed at any node.
>>> 
>>> I agree.
>> 
>> We could do that, and then only comment on the "processing" bit for
>> the various Extension Headers.
>> 
>> 
>>> 
>>>> A source node creates packet with them, it doesn't insert
>>>> them. Similarly, the final destination discards extension
>>>> headers after processing them as part of the normal terminal
>>>> processing of the packet, it doesn't remove them.
>>>> 
>>>> I suggest this text:
>>>> 
>>>> "The source node of a packet, identified by the source address,
>>>> may include extension headers in a packet when it is created.
>>>> Extension headers must not be inserted or removed, and the
>>>> length of any extension header must not be changed, by any node
>>>> for the lifetime of
>>>> the IPv6 packet. Note that it follows from these requirements
>>>> that the length of an IPv6 packet cannot change once the packet
>>>> has been created by the source node.
>>> 
>>> I agree.  That is a typical requirement following from the Smart
>>> End Dumb Network principle.  It is also told as "packets are not
>>> modified en-route, with the only exceptions of decrementing the
>>> Hop Limit field, and the Segments Left field if present".
>>> 
>>> One example that modifies packets en-route is the modification of
>>> the src address.  This is forbidden.
>> 
>>> Another example that does not modify packets en-route, but
>>> creates other packets by incorporating the untouched orignal is
>>> the ESP encapsulation of VPN Gateways.  This is allowed.
>>