Subject: SRH insertion vs SRH insertion + encapsulation

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 13:08:47 +0200

Hello,

I took liberty to start a new thread to focus on hopefully technical
discussion regarding the subject.

For the other long thread we have had between WGs to me the conclusion and
maybe even IETF rough consensus is that SRH insertion when done at the same
time with IPv6 encapsulation is ok and if any document would like to take
that path fwd there is no objections from 6man in regards to violation or
not of any former 6man or IPv6 consensus.

- - -

So on the very topic let me summarize the observations made in various
emails:

#1

*The draft in question doesn't comment on the most basic question: why
doyou want to do EH-insertion as opposed to encap/decap into a new packet?I
asked this question a number of times, and nobody answered. Rumor onthe
corridors had it that it had to do with one specific vendors havingissues
(of some sort) with implementing this with doing encap/decap. --*

Looks to me like FUD at best - just suffice to read (with understanding)

draft-matsushima-spring-srv6-deployment-status-01

- - -

#2

*EH insertion will increase the MTU of the packet. *

It sure will but as already stated this is done within a given domain so
someone who is doing insertion better makes sure it is not causing packet
drops. Otherwise his customers may be pretty unhappy.

If you do EH insertion + encapsulation to my basic math skills it looks
like you are creating even bigger packet. So you are more likely to face
MTU bottleneck issues.

- - -

# 3

*I also have a nit about that draft. The very first line of theabstract is
"The network operator and vendor community has clearlyindicated that IPv6
header insertion is useful and required." *

I agree - such statements should not be in the IETF standards track
document.  Such document should be judged on its technical merits not on a
basis of crusade.

- - -

# 4

*The draft doesn't say why insertion is considered necessary. There is no
justification presented.  *

Well I can understand why one may say so if he does not follow years of
FRR/LFA/R-LFA and now TI-LFA discussions. In a nut shell one technique of
provide fast connectivity restoration is based on the fact of local repair
with local bypass of the broken fragment of the network in a loop free
manner. That requires some form of controlled packet steering around the
failure.

There are many techniques to achieve such steering SR is an elegant one for
this specific application. The less bits you add to the packet the better.
Usually you are fine with just one SID or in number of topologies you
actually do not need any SID so just placing original dst address into SRH
and applying new dst address may be all what is required.

I understand that for some FRR techniques do not matter .. some may use
completely different end to end techniques (I like those btw :) but for
some it has been a necessity to provide best service to their customers.

- - -

#5

*There is no statement that says, "When using IPv6 tunnelling with 128 bit
SIDs, the per packet overhead can become too high."  *

The proposal to use insertion without encap saves you up front 320 bits. I
think the less bits you put in *each* packet the better. As described in #4
- in vast majority of TI-LFA you only need one external anchor to safely
bypass the failure so in fact no need for any SIDs as the original dst will
be either in inner header or in inserted SRH. So your repair efficiency as
far as extra packet size already  is more then 2 times less when doing SRH
insertion vs SRH or CRH insertion with encapsulation.

- - -

# 6

*EH insertion is entirely anonymous. If something breaks, you have noidea
of which device inserted the EH. *

If inserted SRH contains the routable identified of the network element
which inserted the header does this address this point ?

- - -

# 7

*EH insertion sounds to me like it is breaking a fundamental principleof
trying to avoid sending something unexpected and that the receiverwill be
confused by. *

If EH is removed within the domain it has been inserted end receiver never
sees it.

= = =

I think I see why in general you all consider that EH insertion alone would
be a bad thing. But I think here we are not talking about any insertion to
be allowed. We are discussing a fixed and well defined extension which
could be made sure that all valid hooks to address potential concerns are
embedded in its encoding yet still maintaining forwarding efficiency.

I think now it is up to 6man WG and chairs how they choose to continue this
dialogue.

Many thx,
R.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Sep 2019 14:50:06 +0300

On 7/9/19 14:08, Robert Raszuk wrote:
> For the other long thread we have had between WGs to me the conclusion
> and maybe even IETF rough consensus is that SRH insertion when done at
> the same time with IPv6 encapsulation is ok and if any document would
> like to take that path fwd there is no objections from 6man in regards
> to violation or not of any former 6man or IPv6 consensus. 

Since it has become kind of a tradition for proponents of EH insertion
to have interesting interpretations of standards, let me repeat:

If you originate a packet, you can include you EHs (within the
constraints of RFC8200) because it is a *new* packet. That's not called
"insertion".

If you are not the origin of the packet, you cannot insert EHs in the
packet you received -- RFC8200 forbids EH insertion for the reasons
mentioned in the relevant threads.

> *
> *
> *The draft in question doesn't comment on the most basic question: why do
> you want to do EH-insertion as opposed to encap/decap into a new packet?
> 
> I asked this question a number of times, and nobody answered.. Rumor on
> the corridors had it that it had to do with one specific vendors having
> issues (of some sort) with implementing this with doing encap/decap. --*  
> 

So you are telling me that the document that proposes EH insertion
doesn't contain the rationale for it, and we should go and look elsewhere?

Besides, I've just looked at the I-D you reference. The only thing there
about insertion is that there are folks that have deployed it.

So.. let me try to understand: A vendor went ahead and implemented what
they pleased, violating existing standards. They now come to 6man and
claim that we should modify the standard because even when what they are
proposing is forbidden in our specs, they have already deployed it.

Are we being taken seriously?

> *EH insertion will increase the MTU of the packet. *

*and* attribution of the possible errors -- for whatever reason.

> someone who is doing insertion better makes sure it is not causing
> packet drops. Otherwise his customers may be pretty unhappy. 
> 

The packet is bigger. But in the event of errors, they are delivered to
the originator of the packet. That's how our "architecture" works.

> # 4
> 
> *The draft doesn't say why insertion is considered necessary. There is
> no justification presented.  *
> 
> FRR/LFA/R-LFA and now TI-LFA discussions. In a nut shell one technique
> of provide fast connectivity restoration is based on the fact of local
> repair with local bypass of the broken fragment of the network in a loop
> free manner. That requires some form of controlled packet steering
> around the failure. 

That doesn't answer the question. PLease let me rephrase: what are you
doing with EH insertion that you couldn't do with encap/decap?

> # 6 
> *
> *
> *EH insertion is entirely anonymous. If something breaks, you have no
> idea of which device inserted the EH. *
> 

You are breaking IPv6 ent to endness. A node that receives an error will
receive a packet it never sent.

> *EH insertion sounds to me like it is breaking a fundamental principle
> of trying to avoid sending something unexpected and that the receiver
> will be confused by. *
> 
> If EH is removed within the domain it has been inserted end receiver
> never sees it. 

THat's something that you can't guarantee at the protocol level, but
have to do it operationally. And, operationally, s* happens.

> 
> I think now it is up to 6man WG and chairs how they choose to continue
> this dialogue. 

6man already have this dicussion, and I don't see any new elements being
added to it, to be honest.

Thanks,
-- 
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: Sat, 7 Sep 2019 22:01:05 +1000

On Sat, 7 Sep 2019 at 21:09, Robert Raszuk <[email-masked]> wrote:
>
> Hello,
>
> I took liberty to start a new thread to focus on hopefully technical discussion regarding the subject.
>
> For the other long thread we have had between WGs to me the conclusion and maybe even IETF rough consensus is that SRH insertion when done at the same time with IPv6 encapsulation is ok.

Yes, however I don't consider there to be any "insertion" happening at
all in that scenario, and I don't think anybody else in the IPv6 6man
WG would either.

"EH insertion" is splitting apart an existing IPv6 packet after the
IPv6 header and before the payload, inserting the EH, creating or
modifying an existing EH chain, leaving the packet's original source
and destination address as they were.

This is why EH insertion is anonymous - the source address in the
packet is not the identity of the device that inserted the EH. The EH
insertion being anonymous is what causes all the problems - breaking
PMTUD, IPsec, ICMP in general, causing problems if the EH isn't
removed when it should be, and making troubleshooting much harder.

Encapsulation in another new IPv6 packet creates the option to add,
not insert, new supplementary information via EHs.

>From RFC 2473, "Generic Packet Tunneling in IPv6 Specification"

                            +----------------------------------//-----+
                            | Original |                              |
                            |          |   Original Packet Payload    |
                            | Header   |                              |
                            +----------------------------------//-----+
                             <            Original Packet            >
                                              |
                                              v
       <Tunnel IPv6 Headers> <       Original Packet                 >

      +---------+ - - - - - +-------------------------//--------------+
      | IPv6    | IPv6      |                                         |
      |         | Extension |        Original Packet                  |
      | Header  | Headers   |                                         |
      +---------+ - - - - - +-------------------------//--------------+
       <                          Tunnel IPv6 Packet                 >

                       Fig.3 Encapsulating a Packet

SRH, OAM etc. EHs that are added to the original packet would go in
the "IPv6 Extension Headers" area shown in the lower packet of that
diagram, after the new outer tunnel header.

Encapsulation/Decapsulation is an addition/subtraction operation of
new, non-original sender information. It preserves the original packet
as it was when it was originally sent.

It provides a new source address field to identify the device that
performed the encapsulation and that added the supplementary
information via the added EHs.

It provides a new destination address field to unambiguously identify
which device the added EH information is intended to be processed by.
There is no need for these EH processing devices to be looking beyond
the IPv6 fixed header to determine if there are any EHs for them to
process - if it is for them, it is a simple and IPv6 standard packet
DA to device DA match operation which answers that question. If it is
not for them, the forward it via their FIB.

Yes encapsulation adds overhead, however that overhead makes
everything compliant with existing decades old methods, models, tools,
operations and troubleshooting techniques.

Regards,
Mark.

>and if any document would like to take that path fwd there is no objections from 6man in regards to violation or not of any former 6man or IPv6 consensus.
>
> - - -
>
> So on the very topic let me summarize the observations made in various emails:
>
> #1
>
> The draft in question doesn't comment on the most basic question: why do
> issues (of some sort) with implementing this with doing encap/decap. --
>
> EH insertion will increase the MTU of the packet.
>
> It sure will but as already stated this is done within a given domain so someone who is doing insertion better makes sure it is not causing packet drops. Otherwise his customers may be pretty unhappy.
>
> If you do EH insertion + encapsulation to my basic math skills it looks like you are creating even bigger packet. So you are more likely to face MTU bottleneck issues.
>
> - - -
>
> # 3
>
> I also have a nit about that draft. The very first line of the
> abstract is "The network operator and vendor community has clearly
> indicated that IPv6 header insertion is useful and required."
>
> I agree - such statements should not be in the IETF standards track document.  Such document should be judged on its technical merits not on a basis of crusade.
>
> - - -
>
> # 4
>
> The draft doesn't say why insertion is considered necessary. There is no justification presented.
>
> Well I can understand why one may say so if he does not follow years of FRR/LFA/R-LFA and now TI-LFA discussions. In a nut shell one technique of provide fast connectivity restoration is based on the fact of local repair with local bypass of the broken fragment of the network in a loop free manner. That requires some form of controlled packet steering around the failure.
>
> There are many techniques to achieve such steering SR is an elegant one for this specific application. The less bits you add to the packet the better. Usually you are fine with just one SID or in number of topologies you actually do not need any SID so just placing original dst address into SRH and applying new dst address may be all what is required.
>
> I understand that for some FRR techniques do not matter .. some may use completely different end to end techniques (I like those btw :) but for some it has been a necessity to provide best service to their customers.
>
> - - -
>
> #5
>
> There is no statement that says, "When using IPv6 tunnelling with 128 bit SIDs, the per packet overhead can become too high."
>
> The proposal to use insertion without encap saves you up front 320 bits. I think the less bits you put in *each* packet the better. As described in #4 - in vast majority of TI-LFA you only need one external anchor to safely bypass the failure so in fact no need for any SIDs as the original dst will be either in inner header or in inserted SRH. So your repair efficiency as far as extra packet size already  is more then 2 times less when doing SRH insertion vs SRH or CRH insertion with encapsulation.
>
> - - -
>
> # 6
>
> EH insertion is entirely anonymous. If something breaks, you have no
> idea of which device inserted the EH.
>
> If inserted SRH contains the routable identified of the network element which inserted the header does this address this point ?
>
>
> - - -
>
> # 7
>
> EH insertion sounds to me like it is breaking a fundamental principle
> will be confused by.
> If EH is removed within the domain it has been inserted end receiver never sees it.
>
> = = =
>
> I think I see why in general you all consider that EH insertion alone would be a bad thing. But I think here we are not talking about any insertion to be allowed. We are discussing a fixed and well defined extension which could be made sure that all valid hooks to address potential concerns are embedded in its encoding yet still maintaining forwarding efficiency.
>
>
> I think now it is up to 6man WG and chairs how they choose to continue this dialogue.
>
> Many thx,
> R.
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 14:34:44 +0200

Hi Fernando,

> constraints of RFC8200) because it is a *new* packet.
>

Ok glad we got that far :)

And honestly I would recommend NP document authors to clearly separate
those two indeed.

> That's not called "insertion"

If it would be up to me where the NP document calls for EH insertion keep
"insertion" where the document describes insertion + encap just rename it
to imposition+encapsulation.

Just to avoid confusion ...

> doesn't contain the rationale for it, and we should go and look elsewhere?

Deployment experience is never part of standards track document. And it
should never be.

> about insertion is that there are folks that have deployed it.

And why they deployed it.

> Are we being taken seriously?

Ok I admit I am new to 6man ... but not new to IETF. Say in IDR or other
WGs you can not progress any document till you demonstrate interoperable
implementations. That is why there is early code point allocation too.

If in 6man things work differently - if you have to prove on draft and
slides that your idea may work instead of showing it works then that seems
like different IETF process I am used to.

> the originator of the packet. That's how our "architecture" works.

Sure ... you still have originator of the inserted header too. So stops an
implementation to inform such node that what he is doing hurts here ?

> doing with EH insertion that you couldn't do with encap/decap?

Nothing. All you can do with only insertion you can do with imposition +
encap. Just that you just waisting min extra 40 bytes each time.

> receive a packet it never sent.

I don't think so. Remeber SR inserts bits in the packets and removes them
before handling the packet in original form further.

So I guess the case which you are highlighting is this:

1. Packet comes to a domain
2. Within domain without any encap someone is doing TI-LFA with pure
insertion
3. Nodes on the bypass path encounter the issue with the packet, can not
recognize the SRH so start sending erors to original application src
4. Application src can not interpret those errors and we have a mess.

Is this your thinking ?

If so how about we would mandate that SRH insertion is allowed only if
within domain original packet was already encapsulated ?

> have to do it operationally. And, operationally, s* happens.

s* happens all the time. But if this is mandated in the spec you have a
stick to smash your vendor with and get another vendor if they fail to
listen to you.

> added to it, to be honest.

I am sure it did ... I will try to search for it as clearly I must have
missed it fully or partially.

Thx a lot,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 14:40:38 +0200

Hi,

Mark, Fernando, Tom - many thx indeed.

For me word "insertion" was not a reserved word. I think I now start to
understand the rationale on how and why you reacted like you did.
Especially if you say that "insertion" by definition is/must be anonymous.

So if this is what drives all of the opposition to place SRH into a IPv6
header without encapsulation then I think there easy ways to fix it.

I will then talk to some other others about options they are willing to
incorporate into relevant documents.

Many thx,
R.

> >and if any document would like to take that path fwd there is no
> objections from 6man in regards to violation or not of any former 6man or
> IPv6 consensus.
> >
> > - - -
> >
> > There are many techniques to achieve such steering SR is an elegant one
> for this specific application. The less bits you add to the packet the
> better. Usually you are fine with just one SID or in number of topologies
> you actually do not need any SID so just placing original dst address into
> SRH and applying new dst address may be all what is required.
> >
> > There is no statement that says, "When using IPv6 tunnelling with 128
> bit SIDs, the per packet overhead can become too high."
> >
> > The proposal to use insertion without encap saves you up front 320 bits.
> I think the less bits you put in *each* packet the better. As described in
> #4 - in vast majority of TI-LFA you only need one external anchor to safely
> > I think I see why in general you all consider that EH insertion alone
> would be a bad thing. But I think here we are not talking about any
> insertion to be allowed. We are discussing a fixed and well defined
> extension which could be made sure that all valid hooks to address
> potential concerns are embedded in its encoding yet still maintaining
> forwarding efficiency.
> >
> >

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 7 Sep 2019 13:43:01 +0100

> Deployment experience is never part of standards track document. And it 

Robert,

you're perilously close to suggesting that operational input is 
irrelevant to protocol standards development.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 14:56:21 +0200

Completely contrary Nick ...

I am talking about content of the std track document body.

I am also stating that inter-operable implementations and deployments are
separate input to WG process. So are inputs from any WG participant.

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Sep 2019 23:46:12 +1000

On Sat, 7 Sep 2019 at 22:40, Robert Raszuk <[email-masked]> wrote:
> For me word "insertion" was not a reserved word. I think I now start to understand the rationale on how and why you reacted like you did. Especially if you say that "insertion" by definition is/must be anonymous.
>

It's also the splitting apart of existing packets. That is not an
standard IPv6 operation. Only encapsulation/de-encapsulation is.

Splitting packets apart is far more complicated than encapsulation
particularly when there may be existing EHs in the packet, and more
complicated than identifying packets to be de-encapsulated and
processed just by their Destination Address, which is the standard
IPv6 (and IPv4) way to identify packets that are to be processed by
the local node other than using forwarding.

Note the RFC 8200 definition of a router and a host, which are
functional definitions (although we all would usually think of them as
devices):

  router       a node that forwards IPv6 packets not explicitly
                addressed to itself.  (See Note below.)

   host         any node that is not a router.  (See Note below.)

(For completeness, part of the Note

"Note: it is possible for a device with multiple interfaces to be
   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.")

If an SR device is using something else other than a packet's DA to
determine whether to process the packet beyond the IPv6 fixed header
locally, or to forward it, then it isn't an IPv6 router or an IPv6
host. It's undefined, and quite probably a middle box. (It may
physically look like a router, but it's functions that matter in the
context of protocols.)

Regards,
Mark.

> So if this is what drives all of the opposition to place SRH into a IPv6 header without encapsulation then I think there easy ways to fix it.
>
> I will then talk to some other others about options they are willing to incorporate into relevant documents.
>
> Many thx,
> R.
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 7 Sep 2019 16:39:04 +0200

Hi Mark,

> host.

But the crux of the matter is that it is exactly the packet's DA which
determines that.

Of course on the way the packet transited the network the original DA was
placed on the stack and new DA got inserted into the original header to
enable new services on such packets. And the packet gets forwarded which
means it is still falling into router's definition.

Yes new complete header can be placed as well and no service degradation is
going to occur, but only efficiency will be worse. We got that one agreed
on already too.

With that let's keep in mind that LFA technology (leave alone BSIDs) where
unknown when IPv6 was defined. Moreover I am sure new technologies will be
proposed in the future to also benefit from mangling with original IPv6
application sender's complete v6 header while in transit.

So here 6man WG stands in the front of making a choice to either foster the
new services for IPv6 networks native or not.

And as last question to ask ... if you are doing say encapsulation on
ingress to your domain then another encapsulation for local failure
protection and sender of the original packet decided to include large (say
max 256 bytes) Hop-by-Hop Options extension header which should be by
definition examined by all devices on the path - do you every time copy
into new IPv6 encapsulation this type 0 EH or choosing not to copy this
therefor not allowing it to be inspected by all devices on the path ? I
just read 2473 and honestly I am not clear if it should be copied, may be
copied or may not be copied.

Thx,
R.

On Sat, Sep 7, 2019 at 3:47 PM Mark Smith <[email-masked]> wrote:

> >> > It sure will but as already stated this is done within a given domain
> so someone who is doing insertion better makes sure it is not causing
> >> > If you do EH insertion + encapsulation to my basic math skills it
> looks like you are creating even bigger packet. So you are more likely to
> face MTU bottleneck issues.
> >> >
> >> > - - -
> >> >
> >> > # 3
> >> >
> >> > Well I can understand why one may say so if he does not follow years
> of FRR/LFA/R-LFA and now TI-LFA discussions. In a nut shell one technique
> free manner. That requires some form of controlled packet steering around
> the failure.
> >> >
> >> > There are many techniques to achieve such steering SR is an elegant
> one for this specific application. The less bits you add to the packet the
> >> > I understand that for some FRR techniques do not matter .. some may
> use completely different end to end techniques (I like those btw :) but for
> >> > The proposal to use insertion without encap saves you up front 320
> bits. I think the less bits you put in *each* packet the better. As
> described in #4 - in vast majority of TI-LFA you only need one external
> anchor to safely bypass the failure so in fact no need for any SIDs as the
> original dst will be either in inner header or in inserted SRH. So your
> repair efficiency as far as extra packet size already  is more then 2 times
> less when doing SRH insertion vs SRH or CRH insertion with encapsulation.
> >> >
> >> > - - -
> >> >
> >> > # 6
> >> >
> >> > If inserted SRH contains the routable identified of the network
> element which inserted the header does this address this point ?
> >> >
> >> >
> >> > - - -
> >> >
> >> > # 7
> >> >

---

From: Fernando Gont <[email-masked]>
Date: Sat, 7 Sep 2019 23:45:02 +0300

> Ok glad we got that far :) 

I hope that there's no fancy interpretation behind.

> If it would be up to me where the NP document calls for EH insertion
> keep "insertion" where the document describes insertion + encap just
> rename it to imposition+encapsulation. 

It's just encapsulation.

> Deployment experience is never part of standards track document. And it

You miss the point. I look at the document that proposes EH insertion,
and there's no rationale there. And you point me at a different document.

The document that proposes EH insertion has to have minimal analysis
such as: why don't we use encap/decap, etc. If the document that
proposes insertion doesn't have that sort of rationale, I0m not sure why
we should even look at it.

Since you noted: Deployment experience can be part of the document. You
can even add a section noting that it should be removed by the RFC editor.

That said, the fact that somebody implemented something, and that
somebody deployed it is not a motivation for the IETF to work on that
idea, and standardize it.

> And why they deployed it. 

That's completely irrelevant.

> implementations. That is why there is early code point allocation too. 

You are mixing to different things, and also your statement seems to be
incorrect.

Firstly, implementations and deployment experience are do not replace an
appripriate rationale and analysys for updating a standard. Normally,
one would expect that a spec elaborates why the update is needed ("we
want to do EH insertion... hence this document" is not a rationale), and
, in the presense of an obvious choice (such as encap/decap), why that
option is not acceptable to solve your problem.

draft-voyer-6man-extension-header-insertion completely lacks such rationale.

OTOH, as noted in Section 4.1.1. demonstration of interoperable
implementations is not a requirement for draft standard.

> slides that your idea may work instead of showing it works then that
> seems like different IETF process I am used to. 

You have to make a strong case why you want to update the spec. "Hey, we
did this code, it works, and we now want to update the current standard
with it" *is not* an appropriate rationale.

> Sure ... you still have originator of the inserted header too. So stops
> an implementation to inform such node that what he is doing hurts here ? 

An  implementation that receives an error that appears to have been
elicited by a packet it didn't send should normally be ignored.

> encap. Just that you just waisting min extra 40 bytes each time. 

This is probable the first or second sentence that should be in
draft-voyer-6man-extension-header-insertion.

Things are normally portrayed as "Oh! If we can't have EH-inertion, we
cannot do this and that!". -- where in reality you want to do EH
insertion to save 40 bytes of an IPv6 header.

> I don't think so. Remeber SR inserts bits in the packets and removes
> them before handling the packet in original form further. 
> 

That's certainly better than inserting when the packet wasn't
encapsulated. Still, there are other issues with insertion.
If you ask me, EH insertion is not worth it.

> stick to smash your vendor with and get another vendor if they fail to

We have been there numerous times for different protocols. Truth is, s*
happens, and packets leak.

Thanks,

---

From: Ron Bonica <[email-masked]>
Date: Sat, 7 Sep 2019 22:52:54 +0000

Folks,

IMHO, EH insertion modifies the semantics of the IPv6 source address. Today, the IPv6 source address indicates the source of an IP packet and *ALL* of its contents. If transit routers are allowed to insert extension headers, downstream routers can no longer identify the source of a packet and all of its contents.

Granted, in some cases, transit routers are allowed to modify a packet (e.g., Hop Count, DHCP, mutable options). But there is a big difference between changing a field whose value is know to me mutable and inserting a new option.

                                                                                                                                      Ron

Juniper Business Use Only

---

From: Fernando Gont <[email-masked]>
Date: Sun, 8 Sep 2019 02:11:48 +0300

On 8/9/19 01:52, Ron Bonica wrote:
[...]
>  
> 
> IMHO, EH insertion modifies the semantics of the IPv6 source address.
> Today, the IPv6 source address indicates the source of an IP packet and
> **ALL** of its contents. If transit routers are allowed to insert
> extension headers, downstream routers can no longer identify the source
> of a packet and all of its contents.>
>  
> 
> Granted, in some cases, transit routers are allowed to modify a packet
> (e.g., Hop Count, DHCP, mutable options). But there is a big difference
> between changing a field whose value is know to me mutable and inserting
> a new option.

Indeed, it's a major modification (besides the associated issues that
have been pointed out a number of times by several folks).

That's why I think it's not even in the scope of 6man.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 8 Sep 2019 11:47:31 +1200

Hi Fernando,

> have been pointed out a number of times by several folks).

It's explicitly forbidden by RFC8200 plus the fact that option length is
immutable according to IPsec. So the issue is pretty black and white
in terms of the standards track.

> That's why I think it's not even in the scope of 6man.

6man "is not chartered to develop major changes or additions
to the IPv6 specifications." Of course it's a matter of judgment,
but I agree that changing this is "major".

Look, this is one of the reasons we wrote
https://tools.ietf.org/html/draft-carpenter-limited-domains
which is currently being considered as an Independent Submission.
If the community wants to standardise mechanisms that are *not*
intended to work across the open Internet, we need to make that
clear, and specify how it works safely and securely. That's a
community choice, not a WG choice, IMHO.

Regards
   Brian

---

From: Ole Troan <[email-masked]>
Date: Sun, 8 Sep 2019 05:02:32 +0200

Ron,

> Granted, in some cases, transit routers are allowed to modify a packet (e.g., Hop Count, DHCP, mutable options). But there is a big difference between changing a field whose value is know to me mut…

6296?

And I am pointing that out because of what feels like moral righteousness and hypocrisy to me, not because I think header insertion is a good idea or even doable. 

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 8 Sep 2019 15:37:42 +1200

Ole,

On 08-Sep-19 15:02, Ole Troan wrote:
> Ron,
> 
>> IMHO, EH insertion modifies the semantics of the IPv6 source address. Today, the IPv6 source address indicates the source of an IP packet and **ALL** of its contents. If transit routers are allowed to insert extension headers, downstream routers can no longer identify the source of a packet and all of its contents.
>>
>>  
>>

I think the real question here is whether we want it to be possible *in principle* to verify that a packet has not been modified in transit, except for fields that are known to be mutable. NPTv6 is indeed a case where we consciously made this worse. ("NPTv6 involves modifying IP headers in transit, so it is not compatible with security mechanisms, such as the IPsec Authentication Header, that provide integrity protection for the IP header.") Addresses are not mutable as far as AH is concerned.

If we are willing to say that a feature is useable only within a domain where AH is not used, that seems OK, but only if the concepts of a domain, its membership, and its boundary nodes, are well defined. (To be clear, I don't think draft-voyer-6man-extension-header-insertion-06 is anywhere near explaining how a domain is defined and managed.) Or the IETF decides to declare AH dead. In any case, it's wider than a 6man decision.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 8 Sep 2019 14:09:57 +1000

On Sun, 8 Sep 2019, 12:32 Ole Troan, <[email-masked]> wrote:

> Today, the IPv6 source address indicates the source of an IP packet and *
> *ALL** of its contents. If transit routers are allowed to insert
> extension headers, downstream routers can no longer identify the source of
> a packet and all of its contents.
>
>
>
> between changing a field whose value is know to me mutable and inserting a
> new option.
>
>
> 6296?
>

I don't agree with RFC 6296 and NAT in general because of the operational
problems it causes and has caused me.*

The caveat with RFC 6296 is that it is Experimental, not Standards Track. I
don't think people should use it, however with that RFC they will hopefully
consistently do something they shouldn't do.

In comparison to anonymous EH insertion, at least the NPT box overstamps
the packet source address in the inside to outside direction, so in one
direction it isn't anonymous. If you're troubleshooting from that side
there is no ambiguity, because the NPT box will look like the packet's
original source host.

If you're troubleshooting from the inside, the location of the NPT box is
going to known, likely at the network/Internet edge.

EH insertion is far worse, because it's entirely anonymous.

* "The Trouble With NAT", using a set of operational Network Critical
Success Factors as criteria.
https://blog.apnic.net/author/mark-smith/

> And I am pointing that out because of what feels like moral righteousness
> and hypocrisy to me, not because I think header insertion is a good idea or
> even doable.
>
> Ole
>

---

From: Sander Steffann <[email-masked]>
Date: Sun, 8 Sep 2019 23:28:39 +0200

Hi Mark,

> 6296?
> 
> I don't agree with RFC 6296 and NAT in general because of the operational problems it causes and has caused me.*
> 
> The caveat with RFC 6296 is that it is Experimental, not Standards Track. I don't think people should use it, however with that RFC they will hopefully consistently do something they shouldn't do.
> 
> In comparison to anonymous EH insertion, at least the NPT box overstamps the packet source address in the inside to outside direction, so in one direction it isn't anonymous. If you're troubleshooting from that side there is no ambiguity, because the NPT box will look like the packet's original source host.
> 
> If you're troubleshooting from the inside, the location of the NPT box is going to known, likely at the network/Internet edge.
> 

Thank you for that summary. I agree with it.

I'm just sad we're having this discussion over and over again. My personal opinion is that at some point the WG chairs should declare this rehashing of the same discussion as out of scope and move on. The problems with EH insertion have been discussed, the fact that domain/scope limiting doesn't work in practice (especially for those who need to debug the results) and RFC 8200 has been reached. Why the *($#&(* are we still wasting everybody's time beating this dead horse?

Cheers,
Sander

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Sep 2019 08:08:01 +0200

Hi Brian,

> I think the real question here is whether we want it to be possible *in principle* to verify that a packet has not been modified in transit, except for fields that are known to be mutable. NPTv6 is…

I am not quite sure if that's the real question. ;-)
Something like header insertion could only possibly work in a limited domain, e.g. inserted on ingress, removed on egress.
Thereby keeping the end to end transparency. Changing of the packet size breaks PMTUD.

AH is a neat lithmus test. At least in theory. And I think it should be kept for no other reason than that.
I believe ILNP makes changes in only binding to the identifier not the locator.
And as NAT has become such an integrated part of the Internet architecture you might argue if AH should bind to addresses at all, and that consideration applies to the transport protocols too of course.

> If we are willing to say that a feature is useable only within a domain where AH is not used, that seems OK, but only if the concepts of a domain, its membership, and its boundary nodes, are well d…

Indeed. I think what we are talking about here is only possible within a limited domain.
And no, I don't think draft-voyer is nearly done. I think we asked the authors to document the issues with header insertion and proposed mitigations or why those issues weren't applicable in the limited domain. I see only the PMTUD issue mentioned, and then without any mitigation.

Cheers,
Ole

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Sep 2019 16:01:52 +0000

Ole,

There is a big difference between translating a packet's source/destination address and adding something to a packet. The best way to explain this difference is with an analogy.

Assume the following:

  *   I, Ronald, am conversing with an Italian speaker through a translator
  *   I say to the Italian speaker, through the translator, "your shoe is untied"

It is OK for the translator to tell the Italian speaker, "Aldo says that your shoe is untied". He has translated my name into Italian, but not changed the message.

It is not OK for the translator to tell the Italian speaker, "Aldo says that your shoe is untied, and that you are ugly ".  If he were to do that, he would be originating a message and attributing it to me.

                                                                     Ron

Juniper Business Use Only
From: Ole Troan <[email-masked]>
Sent: Saturday, September 7, 2019 11:03 PM
To: Ron Bonica <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Mark Smith <[email-masked]>; draft-voyer-6man-extension-header-insertion <[email-masked]>; [email-masked]
Subject: Re: SRH insertion vs SRH insertion + encapsulation

Ron,

6296?

Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Sep 2019 19:39:52 +0300

>> On 8/9/19 01:52, Ron Bonica wrote:
[....]
> but I agree that changing this is "major".

I cannot think of many other changes that could be considered major as
this. It even changes the end-to-endness of IPv6.

> which is currently being considered as an Independent Submission.

I will look at the I-D again (I think I had at least skimmed through it
a while ago). Was the term "limited domains" coinced there?

> community choice, not a WG choice, IMHO.

I do agree that it's an IETF-wide choice, since this would be out of the
scope of 6man.

That said, while I do think the concept of limited domains is applicable
to things such as "domains where IP fragmentation or EHs can be safely
used", I think when things fail, the implications of EH insertion can
span more than the intended domain. And all this architectural mangling
to save 40 bytes for a protocol that's not the most performance/optimal
(in terms of overhead) one.

I'd bet money that if this proposal had not come from a big vendor, it
had been shot down 1 millisecond after it was made public.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Sep 2019 20:08:42 +0300

On 8/9/19 06:37, Brian E Carpenter wrote:
>>> IMHO, EH insertion modifies the semantics of the IPv6 source
>>> address. Today, the IPv6 source address indicates the source of
>>> an IP packet and **ALL** of its contents. If transit routers are
>>> allowed to insert extension headers, downstream routers can no
>>> longer identify the source of a packet and all of its contents.
>>> 
>>> 
>>> 
>>> Granted, in some cases, transit routers are allowed to modify a
>>> packet (e.g., Hop Count, DHCP, mutable options). But there is a
>>> big difference between changing a field whose value is know to me
>>> mutable and inserting a new option.
>>> 
>> 
>> 6296?
>> 
>> And I am pointing that out because of what feels like moral
>> righteousness and hypocrisy to me, not because I think header
>> insertion is a good idea or even doable.
> 
> I think the real question here is whether we want it to be possible
> *in principle* to verify that a packet has not been modified in
> transit, except for fields that are known to be mutable.

Well, that's IPv6. The question really is if we want (or can) deviate
from that.

> NPTv6 is indeed a case where we consciously made this worse. ("NPTv6
> involves modifying IP headers in transit, so it is not compatible
> with security mechanisms, such as the IPsec Authentication Header,
> that provide integrity protection for the IP header.") Addresses are
> not mutable as far as AH is concerned.
> 
> If we are willing to say that a feature is useable only within a
> domain where AH is not used, that seems OK, but only if the concepts
> of a domain, its membership, and its boundary nodes, are well
> defined. (To be clear, I don't think
> draft-voyer-6man-extension-header-insertion-06 is anywhere near
> explaining how a domain is defined and managed.) 

There's even more trivial questions to be answered, like "what problem
are you trying to solve?". The whole EH insertion thing is motivated by
trying to save 40 bytes for a mechanism that already introduces a lot of
overhead. EH-insertion doesn't allow you to do anything you can't do
with encap/decap.

> Or the IETF decides
> to declare AH dead. In any case, it's wider than a 6man decision.

Agreed. Inserting EHs in the middle of the network is certainly not
"IPv6 maintenance".

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Sep 2019 20:49:23 +0200

Dear Ron,

I think we both have used up our posting quota for long into next year, but I'll one more on this topic.

> There is a big difference between translating a packet’s source/destination address and adding something to a packet. The best way to explain this difference is with an analogy.
>  
> Assume the following:
>  
> 	• I, Ronald, am conversing with an Italian speaker through a translator
> 	• I say to the Italian speaker, through the translator, “your shoe is untied”
>  
> It is OK for the translator to tell the Italian speaker, “Aldo says that your shoe is untied”. He has translated my name into Italian, but not changed the message.
>  
> It is not OK for the translator to tell the Italian speaker, “Aldo says that your shoe is untied, and that you are ugly “.  If he were to do that, he would be originating a message and attributing it to me.

Translating the source address and/or destination address on the Internet is of course much worse than if a header inserted packet leaked.
Translation breaks fundamental parts of the Internet architecture, which has shaped the unidirectional centralized network we have been forced into today.

I do think you are attacking a strawman though. I don't think many, apart from Fernando is talking about changing 8200. I.e the ground rules for end to end IPv6.
The only realistic option for "header insertion" is within a limited domain.

A more fitting analogy would be something like:

- Ronald wants to ship a Birthday parcel to his aunt in Rome. He delivers the packet to the ACME shipping company in Boston
- The shipping company puts the parcel into a bigger sturdier box and gets it loaded onto the first ship bound for Europe.
- When arriving in London the European arm of ACME opens the outer box and slips a big bag of jelly babies in there and close the box up again.
- ACME's box then travel to Rome by train, and arrives to the Italian postal service.
- The Italian postal employee opens the box, eats the jellybabies and take Ron's birthday parcel to his aunt.

Of course if Ron had just shipped the parcel himself directly with the Best Effort Real Internet Inc company, it would have in half the time at half the cost, but the Italian postman would not have gotten any jelly babies...

Cheers,
Ole

PS: For unknown reasons Bassett Jellybabies are really hard to get hold of outside of the UK. Apparently because everyone else thinks the frosting looks like mold.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 9 Sep 2019 21:37:27 +0200

> this. It even changes the end-to-endness of IPv6.

Please observe that today packets are already transported encapsulated in
L2VPN/VPWS transport within number of domains using IPv4 or MPLS. If such
encapsulated packet in say IPv4 domain would "leaked" or "escape" outside
the domain without proper decapsulation it would naturally die as no other
AS would be able to neither route nor properly decapsulate them.

Important: It is in the deepest interest of the carrier to deliver packets.
If they would be dropping packets for whatever reason their business would
be at deep risk.

/* Side comment: Reading a lot of emails I see that some folks treat
network operators like either vacuum or completely unresponsible group of
gangsters just waiting around the corner when 6man will allow them to break
their customer's services or worse as too damn to decide for themselves
what and when to enable a feature in their network. I can rest assure that
carriers are very conservative and would never to anything which would put
at risk even single customer's packet. */

25 years ago frame relay and ATM where connection oriented to offer such
transport for any IP service .. now it is all connection less. Till we get
back to connect oriented transport paradigm using this time optical
switched paths via transit domains we need to at least try do out best in
connection less fashion.

Same for L3VPN/EVPN transports - they also use various encapsulations - and
what goes there IPv6 packets sitting happy as a payload never see.

And all of this is happening today and 6man simply does not know about it.

So here the effort is not to break the end-to-endness of IPv6 nor violate
any dogmas.

*The effort here is to allow IPv6 transport to get the same level of
functionality in the native way in order to deliver IPv6 end-to-end
services with all applications which otherwise require additional
encapsulation layers, various control plane extensions etc ...*

Encapsulated packets will be delivered as the sender intended to the final
receiver and no one is talking about changing a bit in the original
packets.

It is just like you would put cars on the modern tracks to improve time and
quality how they will get through across the mountains.

I tend to think about IPv6 in two planes: IPv6 transport and IPv6 services.
Yes I know you will tell me such division does not exist - true - but this
is the problem not a feature. The sooner community accepts that both can
safely coexist the better for the protocol itself as well as services using
this protocol.

And here interestingly enough we are only talking about enhancement to IPv6
transport without breaking or changing anything to IPv6 services.

Thx,
R.

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Sep 2019 20:09:48 +0000

Ole,

I am a little worried about the Italian postal worker in your example. She opened the outer box, which should have had the following return address:

- ACME Shipping, Boston, USA

She knows and trusts the ACME Staff in Boston, so she eats the Jelly Belly's. But the people in Boston didn't put the Jelly Belly's in the box. Some guy in London did.

So now, any trust that she had bestowed upon the ACME staff in Boston has been usurped by a stranger in London.

                                                                    Ron

-----Original Message-----
From: Ole Troan <[email-masked]> 
Sent: Monday, September 9, 2019 2:49 PM
To: Ron Bonica <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Mark Smith <[email-masked]>; draft-voyer-6man-extension-header-insertion <[email-masked]>; [email-masked]
Subject: Re: SRH insertion vs SRH insertion + encapsulation

Dear Ron,

Cheers,
Ole

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 9 Sep 2019 21:22:55 +0000

Me too.

The only reason that the Italian postal worker would/should open the outer packet would be if the outer packet had her name, at her ufficio postale, as its destination address. But that would be an example of IP in IP encapsulation, where the source address had been placed on the outer packet as ACME London, when ACME London shipped the packet to a specific ufficio postale.

The only exception to who opens packets, other than the destination host, should be firewalls. For example, Ronaldo's aunt lives in an apartment building, and asks the portiere to please open all packages addressed to her. As would firewalls into enterprise networks. Otherwise, the network in the middle should not do this?

Seems a confusing analogy.

Bert

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ron Bonica
Sent: Monday, September 09, 2019 16:10
To: Ole Troan <[email-masked]>
Cc: draft-voyer-6man-extension-header-insertion <[email-masked]>; [email-masked]; Robert Raszuk <[email-masked]>
Subject: RE: SRH insertion vs SRH insertion + encapsulation

Ole,

                                                                    Ron

-----Original Message-----
From: Ole Troan <[email-masked]> 
Sent: Monday, September 9, 2019 2:49 PM
To: Ron Bonica <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Mark Smith <[email-masked]>; draft-voyer-6man-extension-header-insertion <[email-masked]>; [email-masked]
Subject: Re: SRH insertion vs SRH insertion + encapsulation

Dear Ron,

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 9 Sep 2019 23:39:44 +0200

Ron,

> So now, any trust that she had bestowed upon the ACME staff in Boston has been usurped by a stranger in London.

Your concern for Italian postal workers is unfounded in this case.
ACME Boston addresses the outer box to the Rome post office whom was of course well informed that ACME London acts on behalf of ACME Boston.

Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Sep 2019 21:36:05 +0300

[...]
> And as NAT has become such an integrated part of the Internet architecture you might argue if AH should bind to addresses at all, and that consideration applies to the transport protocols too of co…

I'm really curious what's the criteria with which you decide what's part
of the architecture, and what's not. For example, here you say that NATs
are part of the architecture. Not a long time ago you claimed on ietf@
that firewalls are not part of the architecture....

> And no, I don't think draft-voyer is nearly done. I think we asked the authors to document the issues with header insertion and proposed mitigations or why those issues weren't applicable in the li…

THe first question is normally what problem you are trying to solve, and
why you can't solve it with what we already have.

It would seem to me that the "process" here is being *very biased*.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Sep 2019 03:21:17 +0300

On 9/9/19 22:37, Robert Raszuk wrote:
> Please observe that today packets are already transported encapsulated
> in L2VPN/VPWS transport within number of domains using IPv4 or MPLS. If
> such encapsulated packet in say IPv4 domain would "leaked" or "escape"
> outside the domain without proper decapsulation it would naturally die
> as no other AS would be able to neither route nor properly decapsulate
> them. 

I have no idea what's the connection between the text you quote, and the
response below.

I repeat: Allowing EH insertion seems a major addition/modification to
IPv6. 6man is not chartered to do so.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Sep 2019 03:43:37 +0300

> I do think you are attacking a strawman though. I don't think many, apart from Fernando is talking about changing 8200. I.e the ground rules for end to end IPv6.

My argument is: let's call a lemon a lemon. Inserting EHs does break the
end-to-endness of IPv6.

If you want to do it, I'd expect:

1) A proposal that argues what problem they want to solve, and why they
don't solve it in a standards-compliant manner. You seem to imply that
"we have to allow EH-insertion of some sort", whereas I think the first
question is "should we, really?"

2) A document that, at the very least, contains an "Updates: RFC8200"
tag, such that the reader of RFC8200 is pointed to the document from
item "1)" above. As noted above, if you do "1)", you should really
change the text in RFC8200 such that s/must not/should not/.  If RFC8200
represents the consensus on the topic, and you want to deviate from
that, at the bare minimum your document should "Updates: RFC8200".

And to clarify the above: RFC8200 represents IETF consensus on this
topic. This is the reason why RFC8200 -- not because it's a sacred
document.

Besides, I will note that have always been keen to updating standards,
where deemed necessary. And when I've authored document, I've been
generous in including the "Update:" tags that would apply (see RFC8064,
for instance)

> The only realistic option for "header insertion" is within a limited domain.

I don't think we have "flavors" of IPv6 -- that, by itself, would be a
shift in the architecture. But in any case, I think this EH-insertion
thing (whether in a limited domain or not) would seem to me like out of
the scope of 6man.

Thanks,

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Sep 2019 15:09:33 +0000

So, the return address has one meaning in general, and another in the limited domain of ACME shipping.

I guess this is OK so long as packages addressed by ACME never leak out of ACME's limited domain.

Yeah, we have been around this track before.......

                                                        Ron

-----Original Message-----
From: Ole Troan <[email-masked]> 
Sent: Monday, September 9, 2019 5:40 PM
To: Ron Bonica <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; Mark Smith <[email-masked]>; draft-voyer-6man-extension-header-insertion <[email-masked]>; [email-masked]
Subject: Re: SRH insertion vs SRH insertion + encapsulation

Ron,

Ole