Subject: proposed text for header injection revision 05

From: Michael Richardson <[email-masked]>
Date: Tue, 19 Jul 2016 06:13:15 -0400

for 2nd paragraph:

An approach an intermediate node/router may take to include an additional
extension header in an IPv6 packet that it did not originate is to
encapsulate the original packet in a new IPv6 header.  As the
source address of this IPv6 packet would then be the router, any
number of additional extension headers may be placed after this new header,
prior to the original packet.  A system making use of this mechanism will
have to specify how to construct the rest of the IPv6 header, in particulate,
such a specification needs to carefully consider what the destination address
will be.

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

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 20 Jul 2016 08:04:06 +0000

Hi,

I clearly prefer and support Mark's suggestion of removing entirely the second paragraph.

s.

> On Jul 19, 2016, at 12:13 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> for 2nd paragraph:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jul 2016 20:29:48 +1200

> I clearly prefer and support Mark's suggestion of removing entirely the second paragraph.

If we do that I want to see the famous "processed" clarified to make its
intended meaning unambiguous:

    With one exception, extension headers are not processed, modified, inserted
    or deleted by any node along a packet's delivery path, ...

The second paragraph is a compromise that avoids that clarification.

   Brian

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 20 Jul 2016 09:28:49 +0000

+1

Frank

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
Sent: Mittwoch, 20. Juli 2016 10:04
To: Michael Richardson <[email-masked]>
Cc: Mark Townsley (townsley) <[email-masked]>; [email-masked]
Subject: Re: proposed text for header injection revision 05

Hi,

s.

> An approach an intermediate node/router may take to include an 
> additional extension header in an IPv6 packet that it did not 
> originate is to encapsulate the original packet in a new IPv6 header.  
> As the source address of this IPv6 packet would then be the router, 
> any number of additional extension headers may be placed after this 
> new header, prior to the original packet.  A system making use of this 
> mechanism will have to specify how to construct the rest of the IPv6 
> header, in particulate, such a specification needs to carefully 
> consider what the destination address will be.
> 
> 
> --

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Jul 2016 10:02:46 +0000

Same here.

Mark's point that in the real world encapsulation is not necessarily THE technique extends beyond Segment routing. All the open implementations of RPL that I am aware of do header insertion. And are pretty happy with it.

There's an effort in the ROLL community (useofrplinfo draft) to figure out how encapsulation would work, and there's a prototype based on openWSN, but that proves extremely difficult in some cases, and expensive in energy.

Cheers,

Pascal

> From: ipv6 [mailto:[email-masked]] On Behalf Of Frank Brockners
> (fbrockne)
> Sent: mercredi 20 juillet 2016 11:29
> To: Stefano Previdi (sprevidi) <[email-masked]>; Michael Richardson
> <[email-masked]>
> Subject: RE: proposed text for header injection revision 05
> 
> +1
> 
> Frank
>

---

From: [email-masked]
Date: Wed, 20 Jul 2016 12:55:12 +0200

>    or deleted by any node along a packet's delivery path, ...

that text seems to say that in the exception case extension headers can be modified, inserted or deleted.
I'm pretty sure that's not what we want to say. ;-)

> The second paragraph is a compromise that avoids that clarification.

yes, I fear that the suggestion of deleting that paragraph will lead us into the same round of disagreements that led up to that compromise.

let's assume we cannot find consensus on removing the paragraph, nor can we find consensus on adding the "processed" clarification.

I don't mind tweaking the second paragraph if that's required.
currently it says:

   The current approach to allowing a header to be inserted is to
   encapsulate the packet using another IPv6 header and including the
   additional extension header after the first IPv6 header, for example,
   as defined in [RFC2473].

Michael proposed:

or simply:

  One approach to inserting Extension Headers by a node other than the source of the packet
  is to encapsulate the packet using a new IPv6 header and including the additional
  Extension Headers as specified in section 3.1 of RFC2473.

any others? a case of the beer for the winner! ;-)

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2016 00:56:01 +1200

Below...

>   Extension Headers as specified in section 3.1 of RFC2473.

Yes, that occurred to me during the meeting. "The current approach..." implies
that it is almost BCP, but "One approach..." leaves the field open.

Can we compromise on that? I hope so.

   Brian

---

From: <[email-masked]>
Date: Wed, 20 Jul 2016 16:06:29 +0000

Hi Ole, all, 

I'm for removing that text as it does not add any recommendation at all. 

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : mercredi 20 juillet 2016 12:55
> À : Brian E Carpenter
> Cc : Michael Richardson; [email-masked]; Mark Townsley (townsley)
> Objet : Re: proposed text for header injection revision 05
> 
> yes, I fear that the suggestion of deleting that paragraph will lead us
> into the same round of disagreements that led up to that compromise.
> 
> let's assume we cannot find consensus on removing the paragraph, nor can
> we find consensus on adding the "processed" clarification.
> 
> additional

---

From: Jen Linkova <[email-masked]>
Date: Thu, 21 Jul 2016 10:02:57 +0200

> I'm for removing that text as it does not add any recommendation at all.

Seconded. I can not see what we are trying to achieve by having that
second paragraph. It does not add any value and should be removed.

-- 
SY, Jen Linkova aka Furry

---

From: [email-masked]
Date: Thu, 21 Jul 2016 10:33:29 +0200

Jen,

> second paragraph. It does not add any value and should be removed.

Not to pick on you, but can you pretend to represent the people who want the second paragraph removed for a little while?

The below text represents a compromise between those who want an outright prohibition on inserting / modifying / deleting extension headers and those who want to leave the current 2460 ambiguity ambiguous.

The compromise is quite a balancing act. From what I heard during the meeting and on this thread, it does not seem like we will achieve consensus on text without the second paragraph.

I'm fine with you being unhappy with the below text. :-)
But can you _live_ with it?
And if not, why not? Does it break interoperability, does it prohibit future work in this space?

===========
   The insertion of Extension Headers by any node other than the source
   of the packet breaks PMTU-discovery and can result in ICMP error
   messages being sent to the source of the packet that did not insert
   the header.

===========

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jul 2016 20:47:47 +1200

> second paragraph. It does not add any value and should be removed.

So, can we go back to the version at
https://tools.ietf.org/html/draft-ietf-6man-rfc2460bis-01#page-7
which does add value?

Again: that second paragraph is part of a compromise between those who want
to explicitly forbid any insertion of headers and those who don't. Remove
it and you break the compromise.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Jul 2016 17:58:04 +0200

> it and you break the compromise.

What I wonder, in all of this discussion, if whether such "compromise"
is really a comprimise.

My take boils down to these three questions, which I have asked, but
never got an answer:

1) Is a router that inserts an EH compliant with RFC2460? (yes/no)

2) Is a router that inserts an EH compliant with RFC2460bis? (yes/no)

3) If the response to #1 and #2 match, please make that clear. If they
don't, please make it clear that you're changing the spec.

P.S.: The errata I filed for RFC2460 implicitly begs that these
questions be answered.  FWIW, me, I don't care about the specific
outcome, but rather about #3 above being acted upon.

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

---

From: Jen Linkova <[email-masked]>
Date: Thu, 21 Jul 2016 18:21:07 +0200

> Not to pick on you, but can you pretend to represent the people who want the second paragraph removed for a little while?

I'll try to ;)

> But can you _live_ with it?

Well, I'm not sure how that second paragraph represents a compromise
as it juts says 'one possible way to do it is to encapsulate'  (so I
was thinking that we should not add any text which does not add much
value. However after thinking about it for a while I think I'm quite
happy with it as I read it as 'you *can* insert headers - for example
by doing encapsulation or somehow else..'
So, disregard my previous statement ;)

> And if not, why not? Does it break interoperability, does it prohibit future work in this space?

As long as we do explicitly prohibit inserting/modifying - I'm fine with it.
Actually I like the recent version (which says 'One approach' instead
of 'Current approach').
The only comment: it is not clear if the first paragraph talks about
ICMP packet too big only or about sending ICMP
back to host (e.g. "destination unreachable') in general. Do you think
it would make sense to rephrase it slightly:

"The insertion of Extension Headers by any node other than the source
of the packet can break PMTU-discovery.  If ICMPv6 messages (error or
informational,
such as "packet too big" or "echo reply" etc) sent to the source of
the packet that did not insert
   the header, the source host might not be able to recognize/parse it
correctly".

What I'm trying to say, there is not just PMTUD problem which needs to
be kept in mind while inserting EHs,
but generating ICMP in general (traceroute/ping/etc).

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jul 2016 04:39:04 +1200

Fernando,

I understand your frustration but this is where we are:...

> 1) Is a router that inserts an EH compliant with RFC2460? (yes/no)

Some people say Yes. Some people say No.

> 2) Is a router that inserts an EH compliant with RFC2460bis? (yes/no)

Some people say Yes. Some people say No.

> don't, please make it clear that you're changing the spec.

We aren't changing it in the compromise proposal, i.e. we are leaving
it undecided.

IMHO,
   Brian

---

From: [email-masked]
Date: Thu, 21 Jul 2016 20:56:28 +0200

Jen,

[...]

> As long as we do explicitly prohibit inserting/modifying - I'm fine with it.

s/do/don't??

> it would make sense to rephrase it slightly:

it was meant as an _and_. both PMTUD and ICMP error messages break.
it is not an exhaustive list though, e.g. AH would also break.

ICMP Echo would probably work though.

cheers,
Ole

---

From: Jen Linkova <[email-masked]>
Date: Fri, 22 Jul 2016 00:52:58 +0200

Ole,

>> As long as we do explicitly prohibit inserting/modifying - I'm fine with it.

Isn't it great when people can read your mind? ;)
I mean "don't" indeed, thanks for correction!

> it is not an exhaustive list though, e.g. AH would also break.

Ah, OK. It was not very clear (IMHO) but it might be just me..

> ICMP Echo would probably work though.

Yeah, you are right, I stand corrected.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Jul 2016 03:12:44 -0400

Jen Linkova <[email-masked]> wrote:
> As long as we do explicitly prohibit inserting/modifying - I'm fine with
> it. Actually I like the recent version (which says 'One approach' instead
> of 'Current approach'). The only comment: it is not clear if the first
> paragraph talks about ICMP packet too big only or about sending ICMP back
> to host (e.g. "destination unreachable') in general. Do you think it would

An interpretation I heard in the hallway.:
  > "The insertion of Extension Headers by any node other than the source of
  > the packet can break PMTU-discovery.
  .. but I don't care about PMTU, so I'll just do it anyway.

It seems that our haven't prohibited anything, just told people what the
consequences are.  (And what about AH...?  Oh, sadly, nobody uses that)

---

From: Fernando Gont <[email-masked]>
Date: Thu, 21 Jul 2016 18:58:39 +0200

> We aren't changing it in the compromise proposal, i.e. we are leaving

I think that's a bad outcome. We're doing a bis document, and if there's
a known ambiguity, we should clarify it.

My own take is that in RFC2460 forbids it (Bob et al confirming that),
and that rfc2460bis opens the door for it to be possible. If we're going
that way, fair enough, but let's spell that out clearly.

I think that whether EHs can be inserted or not is much of an
architectural point of view that it would be a shame that we publish a
bis document of a 20+ years protocol spec and are not able to answer
such question.

Note, again: I don't care much about the outcome. I care ambiguities in
specs, which, in my experience, sooner or later (but always) lead to
trouble.

Thanks,

---

From: 神明達哉 <[email-masked]>
Date: Fri, 22 Jul 2016 09:57:40 -0700

At Thu, 21 Jul 2016 18:58:39 +0200,

> specs, which, in my experience, sooner or later (but always) lead to

I agree.

And, if the least bad consensus/compromise that this wg could reach is
to leave the ambiguity, I'd at very least like to see text that
explicitly says it was ambiguous in the previous version of the spec
and is still kept ambiguous intentionally due to varied opinions.  I
still oppose to just keeping the text ambiguous.

--
JINMEI, Tatuya

---

From: Hemant Singh <[email-masked]>
Date: Fri, 22 Jul 2016 16:40:30 -0400

+1 to the email below.

The bis doc should acknowledge that old text was deliberately ambiguous and
is now being clarified.  Additionally, the doc should also say  "MPTUD,
ICMP, AH, IPSec" break if any intermediate node adds an EH header.,   It's
probably three times already in this mailer that folks have had to answer
what breaks.   Lastly, please also mention if the rule is not complied
with, a new packet checksum needs to be computed.   There is also potential
to leak packets outside of a specific domain where users may want to add EH
by intermediate nodes and then proper receive behavior of nodes breaks down.

Hemant

On Fri, Jul 22, 2016 at 12:57 PM, 神明達哉 <[email-masked]> wrote:

> .

---

From: Mark Smith <[email-masked]>
Date: Sat, 23 Jul 2016 09:37:47 +1000

On 23 Jul 2016 6:10 AM, "Hemant Singh" <[email-masked]> wrote:
>
> +1 to the email below.
>
> The bis doc should acknowledge that old text was deliberately ambiguous
and is now being clarified.

I haven't seen any evidence of international ambiguity. Brian found an
email from Steve Deering explicitly stating that if you want to add an EH
to a packet you add it via encapsulation within another IPv6 packet.

The following is not ambiguous.

"With one exception, extension headers are not 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."

For those claiming it is, you must explain to the rest of us how you insert
EHs with out "examining" or "processing" the existing EHs.

>Additionally, the doc should also say  "MPTUD, ICMP, AH, IPSec" break if
any intermediate node adds an EH header.,   It's probably three times
already in this mailer that folks have had to answer what breaks.   Lastly,
please also mention if the rule is not complied with, a new packet checksum
needs to be computed.   There is also potential to leak packets outside of
a specific domain where users may want to add EH by intermediate nodes and
then proper receive behavior of nodes breaks down.

---

From: Hemant Singh <[email-masked]>
Date: Fri, 22 Jul 2016 20:10:53 -0400

Sorry, my bad for including "intentional".   It's just ambiguous related to
the term "processed" which is not clear and called out by many others
as ambiguous.

Hemant

On Fri, Jul 22, 2016 at 7:37 PM, Mark Smith <[email-masked]> wrote:

> "With one exception, extension headers are not 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
> For those claiming it is, you must explain to the rest of us how you
> insert EHs with out "examining" or "processing" the existing EHs.
>
>
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 23 Jul 2016 11:51:04 +0930

On 23 July 2016 at 09:40, Hemant Singh <[email-masked]> wrote:
> the term "processed" which is not clear and called out by many others as
> ambiguous.

I think the claim of ambiguity is dubious. Processing is what
computers do, and these devices are specialised computers. If the word
'processing' hasn't been clarified, then it means performing any
actions on the EHs.

I think this is what actually happened:

1. Some people thought the way to solve their problem was to insert
EHs into existing, in flight packets
2. They didn't consult RFC2460 to see if was acceptable to do that
3. They now want a loophole created in RFC2460bis to accommodate
behaviour that isn't permitted, claiming that RFC2460 is ambiguous.

I have two fundamental objections:

- I've dealt with devices that silently change packets or frames in
flight, intentionally or in error, and know how hard they can be to
troubleshoot. Packets that are not modified in flight in any way at
all would be the ideal, because if the packet that arrived wasn't the
packet sent, then something is broken in the network, and network
processing of packets would be no more than look at a value or values
in the packet fields and then perform the small set of actions
necessary to forwarding them.+

- i don't agree with trying to make non-compliant behaviour compliant
by creating a spec loophole using a claimed ambiguity, when an
understanding of the meaning of the words "examine" and "processed"
are fundamental to the field of computing and networking. The heart of
a computer is the Central Processing Unit!

I understand people have work they've put effort into that would be
non-compliant if this loophole isn't created. However, just because
the work exists doesn't mean it now has to be accommodated in the
specifications.

I think the discussion about what and what not to put in regarding
what inserting EHs breaks also shows that this area is not fully
understood or investigated. I think that is also another sign that the
consequences of inserting EHs into existing packets isn't known and
complete. It think it needs to be properly understood and documented,
and then if the benefits are worth the drawbacks, the specification
could be updated to permit it.

Regards,
Mark.

+ If you look at the early versions of IP (e.g., RFC675, various
IENs), for versions 1 through 3 (1974 through 1978) it seems the only
modification of packets that is permitted in the network is
fragmentation (which isn't really modification, rather it is
replacement of one packet with the creation of multiple new packets
carrying the original packet's data). There is no TTL field or hop
count field. I think that indicates that during that design period
there was an expectation that packets were not to be modified in
flight at all, which is the simplest thing to do - just look at them
and forward them, no modification required. TTL or Hop Count fields
are a reasonable safety measure, however they're per-packet overhead
and additional per-hop processing to mitigate what should be a short
lived and transient state of a loop. Ideally, if entirely loop free
routing protocols had been invented (which was probably the
expectation between 1974 and 1978), there'd be no need to have and pay
the price of TTL or Hop Count fields in each and every packet and the
cost of modifying them at each hop.

>> email from Steve Deering explicitly stating that if you want to add an EH to
>> a packet you add it via encapsulation within another IPv6 packet.
>>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sat, 23 Jul 2016 02:58:08 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith

> the work exists doesn't mean it now has to be accommodated in the

+1. That's why, in my opinion, the only way to wiggle out of this state of affairs to is require that the datagram be restored to its original self, before delivery to the destination host or to the next administrative domain downstream (whichever comes first).

Although this measure would not automatically exonerate those networks that want to continue to corrupt packets left and right, and are looking for absolution. I think the practice does go against the intent of RFC 2460, and there's no way around that.

Bert

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Jul 2016 07:44:48 -0400

Hemant Singh <[email-masked]> wrote:
    > ambiguous and is now being clarified. Additionally, the doc should
    > also say "MPTUD, ICMP, AH, IPSec" break if any intermediate node adds

To be clear: it breaks IPsec AH, but has no affect on IPsec ESP.

I'd love to hear that IPsec AH is widely used somewhere, but I have no
evidence of it.  The last time I thought AH might have been useful was when
defining SEND, but it turned out to be impossible due to an unfortunate way
we overspecified what to do when the SPI# isn't recognized.

I think that PMTUD is already broken, so I don't put much value on that
argument.

I'm not in favour of adding/removing headers in the middle; I just want some
technical arguments that hold water.

---

From: Hemant Singh <[email-masked]>
Date: Sat, 23 Jul 2016 10:43:18 -0400

Some obvious use cases should be considered.   Some folks have said we have
a controlled closed domain where we remove added headers before the packet
egresses the domain.   But what about an ICMP error in such a domain
leaking out? What happens when tunnels are used - the original packet was
modified by a middle node with an EH, the packet is later encapsulated in a
tunnel by another node.  What closed domain boundary can catch such a
packet?  See Erik Nordmark's April 6th, 2016 email on this thread.

Additionally, a middle node can also initiate an attack by adding an EH
with a bogus next header value, which downstream nodes don't recognize and
drop the packet; a source node can do the same.

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Jul 2016 07:09:11 +1200

Hemant,

> drop the packet; a source node can do the same.

They can do that whatever we write in RFCs, so I don't think that's a
convincing argument. A more sinister attack is to use an extension header
to exploit a buffer overflow bug in a target system, but again: they can
do that whatever we write in RFCs.

I agree that we could consider a local-use model (already allowed for
diffserv bits) but I see that as a topic for *after* we fix the
Internet-wide standard. I would remond people, however, that we've had
local-use model for diffserv for almost 20 years and TSVWG is still
debating how to standardise inter-domain aspects of diffserv.

    Brian

---

From: Hemant Singh <[email-masked]>
Date: Sat, 23 Jul 2016 18:44:53 -0400

As MarkZZZ said, extension headers are not well understood.  Further, we
have to look into use-case models.   Why not combine all this pending work
in a new draft that collects requirements and use cases for the extension
headers processing by middle nodes.   This way guidance is available to the
community,   But let's move rfc2460bis forward.  Here is text to help move
the bis doc forward.

OLD:

With one exception, extension headers are not examined or processed

NEW:

With one exception, by default, extension headers are not examined or processed

Now implementations on middle nodes are free to do what they want and
the default behavior is not examine and process EH by a middle node.,

Hemant

---

From: 神明達哉 <[email-masked]>
Date: Mon, 25 Jul 2016 11:33:06 -0700

At Sat, 23 Jul 2016 07:44:48 -0400,

> I think that PMTUD is already broken, so I don't put much value on that

I'm not sure if another round of showing the same points helps this
topic, but I have provided another example: inserting an EH in an
intermediate node would break the expectation of the source node that
(rightly) assumes an IPv6 packet of 1280 bytes or shorter won't be
dropped due to a "packet too big" error.  Many existing DNS server
implementations rely on this assumption.

--
JINMEI, Tatuya

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Jul 2016 15:42:04 -0400

> implementations rely on this assumption.

So, we write text that says that systems inserting headers must run on a
network which has a large enough MTU that 1280 byte packets are never
dropped.

NOTE: This is true regardless of how the header is inserted. i.e. this is
      true if you insert using IPIP header!!

We did exactly this in 6lowpan/6lo/RPL.

Myself: I see this is basically the NAT discussion again.  We try to ignore
        something that is really happening, and the result is that we paint
        outselves into a corner, because we failed to negotiate when it was
        time.
        Or, we go the SIP way, and define how the interaction with
        intermediaries is going to be treated.

---

From: Mark Smith <[email-masked]>
Date: Tue, 26 Jul 2016 18:53:00 +1000

On 26 July 2016 at 05:42, Michael Richardson <[email-masked]> wrote:
<snip>
>         intermediaries is going to be treated.

I think the EH insertion comparison with NAT is interesting.

In the inside to outside direction, when the NAT modifies the packet
it changes the source address of the packet to its own outside
address. So it is really re-originating the packet after it has made
its modifications, because it is stating it is the source of those
changes.

In the 'hosts and routers' model, that makes the NAT a host in that
direction. Prior to the NAT, the source address is the origin host of
the packet, and post the NAT, the NAT is the new source of the
modified packet. The source address is reflecting the device that
originated the packet into the network that the packet is being sent
into.

Things that assume the source address is the device that originated
the packet, such as PMTUD and troubleshooting, should work in this
direction.

In the outside to inside direction, only the destination address is
changed, so the NAT is not reflecting that it effectively
re-originated the packet into the inside network by updating the
source address. In the hosts and routers model, it is neither a host
or a router, because it is doing more than just forwarding but doing
less than a host (i.e., in the least, not setting the source address
to its own address).

Things such as PMTUD are not going to work in this direction.
Troubleshooting is harder too, although since there is usually an
obvious boundary between the inside and outside networks that can be
deduced from the boundary between the inside private addressing and
the outside public addressing, the NAT device at that boundary becomes
the first device to suspect to have failed.

Inserting EHs has none of these attributes or indicators of whether or
not and where the EH might have been inserted in the network, as the
packet's source address will never be updated when the EH is added,
and there is no EH insertion boundary that can be as easily deduced
from the type of address being used in either the source or
destination address in the packet.

Regards,
Mark.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Jul 2016 14:51:12 -0400

> its modifications, because it is stating it is the source of those

You mean, the NAT *REMOVED* the IP header, and inserted it's own.
It happened to have the same dst IP in the typical N:1 NAPT situation.
Some NAT44s also mess with the TCP options, and one is known to rewrite the
TCP sequence numbers, which makes it closer in many ways to a transparent
application layer gateway.

It didn't leave the original IP header in place as an IPIP header.
That's really important.

    > destination address in the packet.

The analogy is really to say that we failed to provide a way to
detect/discover the NAT, and negotiate with it in order to discover what
things it would do for us, or to us.

If we are going to permit anything in the middle to look at anything other
than dst, flowlabel and DSCP, (or to modify anything), then let's not repeat
the failure we had in v4 in IPv6.
(Back in 1996, I had designed an authenticated ICMP mechanism to permit IPsec
to traverse firewalls, doing end-to-end AH with hop-by-hop ESP so that
authorized firewalls could perform their audit function. People thought I had
six heads...)