Subject: Adding headers and adding options to headers

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 10 May 2016 13:56:23 +0000

Ole and I were talking about the text in 2460bis that says

   Extension headers must never be inserted by any node other than the
   source of the packet.  IP Encapsulation must be used to meet any
   requirement for inserting headers, for example, as defined in
   [RFC2473].

      01)  Added text that Extension headers must never be inserted by
           any node other than the source of the packet.

He tells me that the justification for adding this to the recommendations in 2460 was that "nobody objected". I'd like to explore that a moment.

The current hbh draft does not discuss header insertion, but the version we discussed at IETF 94 most definitely did, and the segment routing people have certainly discussed header insertion. At IETF 94, I was not argued out of it; I was told that the folks concerned about it had agreed to another approach and was pretty much shot down by the chair. Mark Townsley also spoke at the mike supporting the option.

Not that I propose to add it back in.

But in view of that conversation and that version of that draft, I think it's not fair to say that nobody objected. Objections were not accepted.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 10 May 2016 14:27:44 +0000

> On May 10, 2016, at 3:56 PM, Fred Baker (fred) <[email-masked]> wrote:
> 
> The current hbh draft does not discuss header insertion, but the version we discussed at IETF 94 most definitely did, and the segment routing people have certainly discussed header insertion.

correct. I raised the point during IETF94 meeting and repeated it in the mailing list. I’m a bit surprised about this “nobody objected” statement.

Thanks.

s.

> At IETF 94, I was not argued out of it; I was told that the folks concerned about it had agreed to another approach and was pretty much shot down by the chair. Mark Townsley also spoke at the mike supporting the option.
> 
> --------------------------------------------------------------------
> 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, 11 May 2016 09:04:24 +1200

> correct. I raised the point during IETF94 meeting and repeated it in the mailing list. I’m a bit surprised about this “nobody objected” statement.

I agree (even though I support the proposed text). What we are supposed to be doing
is making sure that 2460bis is an unambiguous statement of rough consensus (and in
this case, we are arguing about the intention of 2460 where it left some doubt).

    Brian

---

From: [email-masked]
Date: Wed, 11 May 2016 08:12:56 +0200

> this case, we are arguing about the intention of 2460 where it left some doubt).

I don't see how finding the intention is particularly important nor useful.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 May 2016 20:22:57 +1200

Ole,
> I don't see how finding the intention is particularly important nor useful.

Look way back in this thread to where I traced the WG rough consensus on this
point in 1995; it's why I've read RFC1883/RFC2460 one way, but others (e.g. the segment
routing people) read it differently. I really think we need to fix that ambiguity
for the Internet Standard step.

Regards

    Brian

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 11 May 2016 08:39:22 +0000

> On May 11, 2016, at 10:22 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> Ole,

I don’t disagree with the idea of removing ambiguity from the spec.

However, I strongly advocate the fact that we are not in a position to do it because we’re just at the beginning of EH usage and we lack of experience.

We lived for more than 18 years with the current spec, I think we’ll survive another few years during which the industry can acquire experience, report it to ietf and then, if necessary, update the spec. 

Thanks.
s.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 May 2016 08:55:46 +0000

Agreed,

the last thing we need is stronger rules without a deep proof that the stronger rule is really needed to get the systems work and interoperate.

 Ambiguity has a good history of creating interop issues (not the case here is it?). It has also provided the necessary elasticity for innovation and evolution. Sometimes the authors leave that ambiguity voluntary and removing it for the sake of it is actually destroying their work (eg flow label).

I may have missed one but my summary of why we'd be removing this ambiguity comes from 2 issues, PMTUD (which is so broken anyway) and traceability (who did what). My take is that those issues should be solved for their own sake as opposed to killing the messenger.

Did this ambiguity prove useful? Yes! Because the source does not know it all. SR is a clear proof there's value in adding applicable semantics to the packet. There were others before (eg RPL) and there will be more.

Regards,

Pascal

> Le 11 mai 2016 à 10:39, Stefano Previdi (sprevidi) <[email-masked]> a écrit :
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 May 2016 11:38:03 +0200

Hi,

The main point is that intermediary routers dont touch forwarded 
packets.  This should be kept that way, otherwise one induces risks of 
fragmenting the Internet.

To support that statement, I am afraid one would need to dive into details:
- yes, the intermediary router MUST decrement the Hop Limit.
- yes, the intermediary router can encap/decap with new headers (list
   them all, AH, ESP, base header).
- yes the intermediary router owning an address in the dst field of a
   packet can swap it with the value in a field in an existing RH.
- no, the intermediary router can not add a DO, MH, HbH, RH,
   frag, unless it creates a new packet (encap).
- no, the intermediary router can not remove a DO, MH, HbH, RH, frag,
   unless it is decapsulating.

Alex

Le 11/05/2016 à 10:55, Pascal Thubert (pthubert) a écrit :
> Agreed,
>
> the last thing we need is stronger rules without a deep proof that
> the stronger rule is really needed to get the systems work and
> interoperate.
>
> Ambiguity has a good history of creating interop issues (not the case
> here is it?). It has also provided the necessary elasticity for
> innovation and evolution. Sometimes the authors leave that ambiguity
> voluntary and removing it for the sake of it is actually destroying
> their work (eg flow label).
>
> I may have missed one but my summary of why we'd be removing this
> ambiguity comes from 2 issues, PMTUD (which is so broken anyway) and
> traceability (who did what). My take is that those issues should be
> solved for their own sake as opposed to killing the messenger.
>
> Did this ambiguity prove useful? Yes! Because the source does not
> know it all. SR is a clear proof there's value in adding applicable
> semantics to the packet. There were others before (eg RPL) and there
> will be more.
>
> Regards,
>
> Pascal
>
>>> Ole, On 11/05/2016 18:12, [email-masked] wrote:
>>>>>> correct. I raised the point during IETF94 meeting and
>>>>>> repeated it in the mailing list. I’m a bit surprised about
>>>>>> this “nobody objected” statement.
>>>>>
>>>>> I agree (even though I support the proposed text). What we
>>>>> are supposed to be doing is making sure that 2460bis is an
>>>>> unambiguous statement of rough consensus (and in this case,
>>>>> we are arguing about the intention of 2460 where it left some
>>>>> doubt).
>>>>
>>> Look way back in this thread to where I traced the WG rough
>>> consensus on this point in 1995; it's why I've read
>>> RFC1883/RFC2460 one way, but others (e.g. the segment routing
>>> people) read it differently. I really think we need to fix that
>>> ambiguity for the Internet Standard step.
>>
>>
>> However, I strongly advocate the fact that we are not in a position
>> to do it because we’re just at the beginning of EH usage and we
>> lack of experience.
>>
>> We lived for more than 18 years with the current spec, I think
>> we’ll survive another few years during which the industry can
>> acquire experience, report it to ietf and then, if necessary,
>> update the spec.
>>
>> Thanks. s.
>>
>>
>>
>>>
>>> Regards
>>>
>>> Brian
>>
>> [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: Mark Smith <[email-masked]>
Date: Wed, 11 May 2016 20:04:38 +1000

On 11 May 2016 18:56, "Pascal Thubert (pthubert)" <[email-masked]>
wrote:
>
> Agreed,
>
> the last thing we need is stronger rules without a deep proof that the
stronger rule is really needed to get the systems work and interoperate.

The thing I don't understand is the need for proof. Do we really need to
*prove* that adding unexpected EHs mid-flight is going to break things even
though it is foreseeable that they will, because it is easy to see how it
will interact badly with the existing mechanisms?

>  Ambiguity has a good history of creating interop issues (not the case
here is it?). It has also provided the necessary elasticity for innovation
and evolution. Sometimes the authors leave that ambiguity voluntary and
removing it for the sake of it is actually destroying their work (eg flow
label).
ambiguity comes from 2 issues, PMTUD (which is so broken anyway) and
traceability (who did what). My take is that those issues should be solved
for their own sake as opposed to killing the messenger.

How? How are you going to trace who did what if the device silently did it?
If you don't have an answer, you're creating the problem and then making it
somebody else's problem to fix. I think people who create problems are
obligated to fix them.

Tunneling already solves these problems and facilitates adding EHs. Why are
people choosing to ignore this option? What is the unstated bias against
tunneling?

> Did this ambiguity prove useful? Yes! Because the source does not know it
all. SR is a clear proof there's value in adding applicable semantics to
the packet. There were others before (eg RPL) and there will be more.

The question isn't whether or not the added semantics have value.

The question is what is the best way to add those semantics that doesn't
interact badly with or cause to fail existing, widely deployed mechanisms
(like PMTUD), doesn't violate established semantics of existing fields
(like a "multi-source packet" (meaning multiple devices are the source of
parts of the packet) with a single source address field would), and doesn't
make troubleshooting an operational network harder than it already is.

In theory, these edited packets would never leak from the editing domain,
and devices that add or remove them would never need troubleshooting.
Practice and theory are rarely the same.

Regards,
Mark.

> >>>>> correct. I raised the point during IETF94 meeting and repeated it
in the mailing list. I’m a bit surprised about this “nobody objected”
statement.
> > However, I strongly advocate the fact that we are not in a position to
do it because we’re just at the beginning of EH usage and we lack of
experience.
> >
> > We lived for more than 18 years with the current spec, I think we’ll
survive another few years during which the industry can acquire experience,
report it to ietf and then, if necessary, update the spec.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 11 May 2016 10:14:27 +0000

> On May 11, 2016, at 11:38 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi,
> 
> The main point is that intermediary routers dont touch forwarded packets.

I’m afraid the reality is slightly different.

Of course, you’ll have to define what “touching the packet” means.

Inserting, pushing, removing, pop’ing info into/from packets by transit nodes is being done for ages.

s.

>  This should be kept that way, otherwise one induces risks of fragmenting the Internet.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 11 May 2016 12:44:24 +0200

> I’m afraid the reality is slightly different.

Well, reality - just like beauty - is in the eye of the beholder

> Inserting, pushing, removing, pop’ing info into/from packets by transit nodes is being done for ages.

If you mean IPv4 ages then it is possible I agree with you.

Alex

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 11 May 2016 11:21:48 +0000

> On May 11, 2016, at 12:44 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 

yeah sure, whatever.

s.

---

From: <[email-masked]>
Date: Wed, 11 May 2016 11:36:04 +0000

Dear all,

I fully agree with Stefano here. 

Further, I do see some value in inserting EHs for some advanced services in the network side.

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de Stefano Previdi
> (sprevidi)
> Envoyé : mercredi 11 mai 2016 10:39
> À : Brian E Carpenter
> Cc : 6man WG; Bob Hinden; Fred Baker (fred)
> Objet : Re: Adding headers and adding options to headers
> 
> 
> >>>> correct. I raised the point during IETF94 meeting and repeated it in
> the mailing list. I’m a bit surprised about this “nobody objected”
> statement.
> >>>
> However, I strongly advocate the fact that we are not in a position to do
> it because we’re just at the beginning of EH usage and we lack of
> experience.
> 
> survive another few years during which the industry can acquire
> experience, report it to ietf and then, if necessary, update the spec.
> 
> Thanks.
> s.
> 
> 
> 
> >
> > Regards
> >
> >    Brian
> >
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 May 2016 16:14:34 +0000

Hello Mark:

Cheers,

Pascal

From: Mark Smith [mailto:[email-masked]]
Sent: mercredi 11 mai 2016 12:05
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Fred Baker (fred) <[email-masked]>; Bob Hinden <[email-masked]>; 6man WG <[email-masked]>; Stefano Previdi (sprevidi) <[email-masked]>
Subject: Re: Adding headers and adding options to headers

> the last thing we need is stronger rules without a deep proof that the stronger rule is really needed to get the systems work and interoperate.

The thing I don't understand is the need for proof. Do we really need to *prove* that adding unexpected EHs mid-flight is going to break things even though it is foreseeable that they will, because it is easy to see how it will interact badly with the existing mechanisms?

>> Looks like FUD to me. Any addition must be done carefully and ideally pass through this group for validation.

> I may have missed one but my summary of why we'd be removing this ambiguity comes from 2 issues, PMTUD (which is so broken anyway) and traceability (who did what). My take is that those issues shou…

How? How are you going to trace who did what if the device silently did it? If you don't have an answer, you're creating the problem and then making it somebody else's problem to fix. I think people who create problems are obligated to fix them.

>> we could work on improving traceability. I’d support such work. This may mean more headers being modified on the fly ; )

Tunneling already solves these problems and facilitates adding EHs. Why are people choosing to ignore this option? What is the unstated bias against tunneling?

>> tunnels are not exempt of problems. They can cause additional fragmentation, add to loss and latency... And tunnels cannot solve everything. If more than one router needs to add/mod stuff, there would be IP in IP in IP and only the outer encapsulation would be observed and that would not be the desired result. Basically tunneling breaks the whole idea.

The question is what is the best way to add those semantics that doesn't interact badly with or cause to fail existing, widely deployed mechanisms (like PMTUD), doesn't violate established semantics of existing fields (like a "multi-source packet" (meaning multiple devices are the source of parts of the packet) with a single source address field would), and doesn't make troubleshooting an operational network harder than it already is.

>> So you’re opposing a general capability that could in fact be used to instrument packets and help understand how the network is going? That could be used to avoid a congestion that’s indeed hard to troubleshoot? We do not need a general ruling, we need a case by case and careful examination.

In theory, these edited packets would never leak from the editing domain, and devices that add or remove them would never need troubleshooting. Practice and theory are rarely the same.

>> FUD. If this group defines a new operation, I’m sure it will make it properly.

Regards,
Mark.

> Regards,
>
> Pascal
>
> > Le 11 mai 2016 à 10:39, Stefano Previdi (sprevidi) <[email-masked]<mailto:[email-masked]>> a écrit :
> >
> >
> >> On May 11, 2016, at 10:22 AM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
> >>
> >> Ole,
> >> On 11/05/2016 18:12, [email-masked]<mailto:[email-masked]> wrote:
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 11 May 2016 09:40:40 -0700

At Wed, 11 May 2016 20:22:57 +1200,

> for the Internet Standard step.

+1 (about the need for the fix).

It could be understandable, though I'm not convinced about it yet,
that someone who doesn't like the original intent (because it would
break some existing product of them?) wants to overturn it.  But in
any case it doesn't make sense to me at all to just leave the
ambiguity.  It will just result in more confusion and more possibility
of interoperability problems in the mean time.

--
JINMEI, Tatuya

---

From: [email-masked]
Date: Wed, 11 May 2016 20:38:54 +0200

> of interoperability problems in the mean time.

do you know of any interoperability problems with the current RFC2460?
that has to be the driving issue in deciding this.

with regards to making prohibitions on future work in current protocol specifications, can you cite any example of the IETF being successful with that? :-)

RFC2460 already has this prohibition by the way:

   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.

I'm afraid I don't see the point in changing RFC2460 here.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 May 2016 08:37:03 +1200

Ole,

Trying to answer your specific comments concisely:

> that has to be the driving issue in deciding this.

Yes. Inserting extension headers breaks PMTUD. RFC2460 cites RFC1981
as "strongly recommended" so that is normative.

> I'm afraid I don't see the point in changing RFC2460 here.

The word "processed" is the problem here - it is ambiguous. That is the
spcific reason for adding "modified or inserted".

Regards
    Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 May 2016 06:47:29 +1000

> Hello Mark:

If you think I'm using FUD, then I wonder if you have had any experience
troubleshooting the sorts of problems this could cause. That is why I argue
strongly against it - I don't see the benefits are worth the cost when I
think there is a much better alternative.

Regards,
Mark.

> Cc: Fred Baker (fred) <[email-masked]>; Bob Hinden <[email-masked]>;
6man WG <[email-masked]>; Stefano Previdi (sprevidi) <[email-masked]>
> >
>
> How? How are you going to trace who did what if the device silently did
it? If you don't have an answer, you're creating the problem and then
making it somebody else's problem to fix. I think people who create
problems are obligated to fix them.
>
> >> we could work on improving traceability. I’d support such work. This
may mean more headers being modified on the fly ; )
>
> Tunneling already solves these problems and facilitates adding EHs. Why
are people choosing to ignore this option? What is the unstated bias
against tunneling?
>
> >> tunnels are not exempt of problems. They can cause additional
fragmentation, add to loss and latency... And tunnels cannot solve
everything. If more than one router needs to add/mod stuff, there would be
IP in IP in IP and only the outer encapsulation would be observed and that
would not be the desired result. Basically tunneling breaks the whole idea.
>
> > Did this ambiguity prove useful? Yes! Because the source does not know
it all. SR is a clear proof there's value in adding applicable semantics to
the packet. There were others before (eg RPL) and there will be more.
>
> >> So you’re opposing a general capability that could in fact be used to
instrument packets and help understand how the network is going? That could
be used to avoid a congestion that’s indeed hard to troubleshoot? We do not
need a general ruling, we need a case by case and careful examination.
> > >> Look way back in this thread to where I traced the WG rough
consensus on this
> > > However, I strongly advocate the fact that we are not in a position
to do it because we’re just at the beginning of EH usage and we lack of
experience.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 May 2016 17:45:51 -0400

> as "strongly recommended" so that is normative.

Again: I claim PMTUD is already broken and unfixable.
(and should be replaced by PLMTUD, which should be turned on by default)

What else does inserting headers break that isn't related to PMTU ICMPs?

(I'm not in favour of inserting headers.  I am in favour of having rational
and evidence based reasons in our specifications, or they will get ignored).

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

---

From: Mark Smith <[email-masked]>
Date: Thu, 12 May 2016 08:40:29 +1000

> What else does inserting headers break that isn't related to PMTU ICMPs?

The name and purpose of the source address field in the packet.

If there can be multiple originators of parts of a packet, created by
multiple sources, the name of that field would now be incorrect. It would
now only be carrying the first source of the first part of the packet, with
no way to tell if the listed address created the whole or only part of the
packet.

That's how fundamental a change this would be. Anything that believes the
source address in a packet is the originator of all parts of the packet -
protocols, devices, troubleshooting tools and methods, and many network
operators - will now be relying on a falsehood.

So if adding EHs is to be permitted, then the source address field name and
description must be changed too, and everywhere this assumption about
source = whole of packet originator (RFCs, documentation, troubleshooting
tools etc.) also needs to be changed.

I think this discussion is really about whether to support multi-source
packets or not, and then the consequences of only encoding the first source
in the packet.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 May 2016 14:57:50 +1200

> (and should be replaced by PLMTUD, which should be turned on by default)

But that's beside the point of what we should say in 2460bis, which is
supposed to be a consolidation of 2460 and nothing more.

[Agreed - there's more to be done on this topic, but it's a separate
issue from 2460bis.]

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 May 2016 08:55:32 +0200

> What else does inserting headers break that isn't related to PMTU ICMPs?

Maybe integrity values like ICMP CRC or AH ICV fields(?)

Alex

---

From: [email-masked]
Date: Thu, 12 May 2016 09:05:36 +0200

Brian,

> Trying to answer your specific comments concisely:

Thank you.

[...]

> as "strongly recommended" so that is normative.

Yes, that would be a valid argument if we were discussing how to design header injection.
Describing header injection in RFC2460bis is not on the table.
My argument is about what we put in 2460bis.
I believe no interoperability issue has been shown in RFC2460. Do you concur with that?

(Future specifications can of course create as many interoperability issues they like, not much we can or should do about that in 2460).

> spcific reason for adding "modified or inserted".

I don't think this text is ambiguous at all.
Every network on the planet seems to violate it though, which of course is a much larger problem than the one we're talking about here.

To summarise my view:
 - There has not been shown any interoperability issues caused by the extension header text in 2460
 - Adding a general prohibitions to avoid something we dislike happening in the future, does a) not belong in 2460, b) is not testable c) is  unlikely to have the desired effect

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 May 2016 11:08:52 +0200

>and evidence based reasons in our specifications, or they will get ignored).

By and large PMTUD works. It doesn't always work, which is an issue. But
it largely works.

That said in my opinion all hosts MUST do some form of PMTU blackhole
detection. Unfortunately we can't write that down.

Also unfortunately, very few stacks seem to ship with PLMTUD enabled by
default. So any new feature in IPv6 that break PMTUD more is going to put
IPv6 at a significant disadvantage compared to IPv4.

I think we should focus on PMTUD with a fallback to PLMTUD. As far as I
know there are no major stack running with just PLMTUD and we have
no idea how it would work in practice.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 12 May 2016 11:39:36 -0700

> that has to be the driving issue in deciding this.

I guess this seems to be a fundamental difference on the view between
us - I don't think this has to be the driving issue on this at all.
IMO the onus is on those who want to keep the ambiguity by proving it
is actually safe for any combination of assumption mismatch: a sending
node believes no intermediate node inserts or deletes an EH while an
intermediate node believes it's allowed for them.

Nevertheless I can easily come up with a few such problems:

- As already pointed out, PMTUD
- As a corollary of this, some connection-less applications that
  assume they can safely send packets up to 1280 bytes without any
  drop due to a 'packet too big' issue.  DNS servers work on this
  assumption.
- Authentication Header

I suspect these "evidences" won't matter anyway, though.  It's easy to
pooh-pooh those (or any other) examples as weak.  As long as we have
the fundamental difference on how to view this I mentioned above, I
guess no such example will convince you.  So I think we should
probably simply agree to disagree.

> with regards to making prohibitions on future work in current protocol specifications, can you cite any example of the IETF being successful with that? :-)

Maybe this is just a rhetorical question, and an answer isn't
expected, but if it's trying to suggest something like "determined
developers/operators do whatever they want no matter what the IETF
says", I don't deny that.  But I also believe what's stated in the RFC
still has some (pretty strong) power to discourage people to do "the
wrong thing".

I'd also note that I didn't intend to prohibit future work that can
change what's written in the current specification.  In the context of
this discussion, my understanding is that the ambiguity and confusion
are real as we can see it in RFC4782 and that it's not unreasonable to
expect it will actually cause interoperability problems, while the
discussion on changing the current spec would be quite controversial
and can take long time.  So I believe it does make very sense to
eliminate the ambiguity at this point.

> I'm afraid I don't see the point in changing RFC2460 here.

On the other hand, I'm afraid I don't see what's wrong with clarifying
obvious ambiguity as log as we all agree that that's actually the
original intent (even if some of them don't like the intent).  It will
just make the doc a couple of paragraphs longer and would completely
eliminate the ambiguity.

But again, this is probably just another case of how our views on this
are so fundamentally different.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 May 2016 08:39:28 +1200

Ole,

I think that I and some others disagree with you, and of course
we are all entitled to our opinions. I doubt we'll hear any new
arguments now.

However, what is your WG Chair's view of the *WG consensus*? Do you think
the rough consensus is to include or exclude these words:

   Extension headers must never be inserted by any node other than the
   source of the packet.  One approach to meet a requirement to add
   extension headers is to use IP Encapsulation, for example, as defined
   in [RFC2473].

   Extension headers must never be deleted or changed in size by any
   node on the path the packet takes.

   The contents of an Extension header or Option in an Extension header
   may be modified if this is permitted by the definition of the
   Extension header or option.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 May 2016 18:24:55 -0400

> supposed to be a consolidation of 2460 and nothing more.

I don't agree.
As part of the process towards Internet Standard, we are supposed to rip out
and/or clarify things which didn't work as expected.

I claim that PMTUD is such a thing, and it seems to be the key reason to
avoid header insertion/deletion.  (I hear Mark Smith's comments loudly; and I
have war wounds from debugging MPLS and all manner of 802.3 networks where
intermediate boxes do stuff mysteriously to packets).

{I would prefer that header insertion/deletion was impossible because 90% of
traffic had AH on it.... Hey, a person can dream, can't they?}

---

From: Michael Richardson <[email-masked]>
Date: Thu, 12 May 2016 18:31:34 -0400

> By and large PMTUD works. It doesn't always work, which is an issue. But

How did you arrive at this conclusion?
I use native IPv6 through tunnels and PPPoE on a regular and continuous basis
throughout the day.  Without PLMTUD enabled, I get regular fails.

I have an IPsec tunnel to a one-armed router that I used from my laptop, and
somehow it just WILL NOT produce an ICMP message when it should.  And my
ISP's router seems to never produce ICMPs on incoming traffic to the PPPoE.
PLMTUD saves the day each time.

    > default.

yes, it's a mystery as to why not.
It works well.

    > no idea how it would work in practice.

I think that there was a lot of experience with PLMTUD from the people who
designed it 15 years ago.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 May 2016 10:23:51 +1000

> How did you arrive at this conclusion?

Is it a broken protocol or broken equipement.  PMTUD works with
equipement that implements IPv4 and IPv6.  Firewalls that drop PTB
indescriminately do not implement IPv4 and IPv6, they implement
some abomination they the incorrectly describe as IPv4 and IPv6.

Load balancers that don't look at the PTB payload to determine where
to send the ICMP message also don't implement IPv4 and IPv6

ICMP is a basic part of IP.

> --=-=-=
> Content-Type: application/pgp-signature; name="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEVAwUBVzUEQ4CLcPvd0N1lAQL8jwf5ARU6MJW3YV8Q+dZ8VJPfL20pu1mudalf
> v12E1vzwmLkTmc3VeB1HX1c2cneXFO8HQoUk1JkWEYxPmlQGnIF5YTbwE9Y+nj1a
> GgWH5sN6FdfwDaXZmmGyUr+My1Sqg3uQGkXD73WLNfiYxrv2C/C89EOgIsCfFUDJ
> Lt4RzpIEvOYmfRqH1AxLb/IHISXhrccRW39PW3wx9XqlQ6wZXkZ/jBcYXHgz/3D7
> VSC2SwGupvo4CW+Zf/a+Lid00o7flG/j8+QQkUabvy2UCNXp0DnyzvjQQEA1ugjf
> mOWykUicdRiUTQi0+PyQ40YsatBehGHcls/6F36uM6URKD8303y1DQ==
> =MSWf
> -----END PGP SIGNATURE-----
> --=-=-=--
> 
> 
> --===============3115220982506232764==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============3115220982506232764==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 May 2016 14:12:13 +1200

Well, I changed the subject, since this is really a separate issue
about the text.

Currently 2460bis has exactly the same words about PMTUD as 2460, and
this is running code if all intermediate systems respect 2460 and 1981
and 4443.

Bob: ===>>> Presumably 2460bis should actually cite 1981bis

1981bis cites PLPMTUD, which is of course new text compared to 1981.

I think that covers it, within the rules for promotion to Internet Standard.

This doesn't fix the real world; that is v6ops territory, where a BCP on
IPv6 ops would belong.

    Brian

---

From: [email-masked]
Date: Fri, 13 May 2016 08:37:44 +0200

Brian,

Thanks for the question.
What I plan to do is to start working group last calls of the 3 affected documents. In series unless someone thinks parallel will work better. We will track issues found in the issue tracker, and then work through the issues as they are raised.

I have already added a ticket to the tracker for the header insertion. While I don't see a clear consensus at the moment, I'm thinking of giving the working group (and myself) some time to mull this over now that the discussion has settled.
I do not want to make this an issue that blocks progress of 2460bis, so I hope we can have this settled by end of WGLC period.

Does that sound reasonable?

Best regards,
Ole

> On 12 May 2016, at 22:39, Brian E Carpenter <[email-masked]> wrote:
> 
> Ole,
>

---

From: [email-masked]
Date: Fri, 13 May 2016 09:09:46 +0200

[Replying to Michael's post with Brian's new subject]

> traffic had AH on it.... Hey, a person can dream, can't they?}

We can state whatever we'd like in standards about not processing past the IPv6 header or banning middleboxes from inserting header or mangling the packet in general. The only true answer is encryption.

I largely agree with you that PMTUD is unreliable. Although this paper:
http://dl.acm.org/citation.cfm?id=1879155

Although somewhat old, and with limited data on IPv6, seems to suggest 2-3% PMTUD drop on IPv6 and quite a bit higher on IPv4.
Anyone got newer measurements?
What about measurements on PLMTUD deployments?

With regards to 2460bis; if we look at the motivation of the section 5 text, I think it strongly recommends that a host implements path mtu discovery, in some form. Just that at the time 2460 was written PMTUD was the only one available.

Is your argument that 2460bis should cite both PMTUD and PLMTUD as the strongly recommended mechanisms to implement?

Another way of asking if we can add that to 2460bis, would be to ask "is 4821 ready to be advanced to Internet standard?"

Best regards,
Ole

PS: Completely outside of 2460bis context. There are some other interesting ideas floating around. E.g. Andrew Yourtchenko suggested that routers truncate and forward instead of dropping and sending PMTUD ICMP. With that scheme you could detect full path MTU in one round trip. I don't know if he wrote that up anywhere or not.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 13 May 2016 14:02:35 +0200

>throughout the day.  Without PLMTUD enabled, I get regular fails.

The way I see it that for as link smaller than 1500, most of the IPv6
internet can be reached.

There are some cases where ICMP are dropped, not generated at all, or
generated broken. But it is a small percentage.

The percentage is big enough that from an operational point of view it is
extremely annoying. But technically it mostly works.

>yes, it's a mystery as to why not.

Indeed, it's a mistery to me as well.

>designed it 15 years ago.

If we want to offically replace PMTUD with PLMTUD then we need large scale
experience on the current internet.

---

From: Ca By <[email-masked]>
Date: Fri, 13 May 2016 06:05:28 -0700

On Wednesday, May 11, 2016, Michael Richardson <[email-masked]>
wrote:

>
> Brian E Carpenter <[email-masked] <javascript:;>> wrote:
Please cite current evidence ipv6 pmtud is broken.

I know the ipv4 situation is widely known, but the ipv6 deployers have been
eyes wide open on making pmtud work as a requirement on day 1

> Michael Richardson <[email-masked] <javascript:;>>, Sandelman
> Software Works

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 13 May 2016 15:22:55 +0200 (CEST)

> Please cite current evidence ipv6 pmtud is broken.

I know of non-zero amount of web sites where it's broken and doesn't work 
correctly, but I'd say this is not widespread.

My home (ipv6 path) network:

COMPUTER <MTU1500 LAN> ROUTER <MTU1280 tunnel> ROUTER <MTU1500 INTERNET>

I do not do MSS adjust in any of the routers. I rely on PMTUD to work.

Happy Eyeballs won't help me if PMTUD is broken.

I've been running this for years and it's my opinion that there were a lot 
more broken IPv6 enabled sites 3-4 years ago compared to now. I imagine I 
would have noticed if there was widespread PMTUD brokenness.

Otoh I like PLMTUD as well, I think we should have both.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Fri, 13 May 2016 09:57:16 -0700

At Thu, 12 May 2016 18:24:55 -0400,

> and/or clarify things which didn't work as expected.

Two separate points seem to be conflated here:

A. Whether PMTUD is already broken and should be removed from 2460bis
B. Even if A is true, whether that can be a reason for not explicitly
   clarifying the EH insertion/deletion matter in 2460bis

Your second sentence ('As part of...') seems to simply focus on A, but
I'm not sure if the first sentence "disagreed" about A or B or both or
something else...

I don't have a strong opinion on point A although I feel it'd be
overkill to remove it.  But regarding point B, I'd list another
example that inserting extension headers breaks DNS server
implementations, which generally limit large response packets to up to
1280 bytes to avoid PMTUD overhead (even if PMTUD works).  This is the
case regardless of whether PMTUD really works or is broken or PLMTUD
is/will be widely implemented and deployed.  (in any case, though, I
personally don't think we have to show these specific cases just for
not being silent on the existing ambiguity in the first place, as I
said in my other message).

--
JINMEI, Tatuya

---

From: joel jaeggli <[email-masked]>
Date: Fri, 13 May 2016 10:00:31 -0700

On 5/13/16 6:05 AM, Ca By wrote:
> 
> 
> On Wednesday, May 11, 2016, Michael Richardson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> I know the ipv4 situation is widely known, but the ipv6 deployers have
> been eyes wide open on making pmtud work as a requirement on day 1

Hashing to endpoints is naturally really problematic irrespective
address family.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 May 2016 14:01:19 -0400

[email-masked] wrote:
    mcr> {I would prefer that header insertion/deletion was impossible because 90% of
    mcr> traffic had AH on it.... Hey, a person can dream, can't they?}

    > We can state whatever we'd like in standards about not processing past
    > the IPv6 header or banning middleboxes from inserting header or
    > mangling the packet in general. The only true answer is encryption.

+1000.

    > With regards to 2460bis; if we look at the motivation of the section 5
    > text, I think it strongly recommends that a host implements path mtu
    > discovery, in some form. Just that at the time 2460 was written PMTUD
    > was the only one available.

    > Is your argument that 2460bis should cite both PMTUD and PLMTUD as the
    > strongly recommended mechanisms to implement?

Yes, I would be happier with this.

    > Another way of asking if we can add that to 2460bis, would be to ask
    > "is 4821 ready to be advanced to Internet standard?"

    > PS: Completely outside of 2460bis context. There are some other
    > interesting ideas floating around. E.g. Andrew Yourtchenko suggested
    > that routers truncate and forward instead of dropping and sending PMTUD
    > ICMP. With that scheme you could detect full path MTU in one round
    > trip. I don't know if he wrote that up anywhere or not.

okay, so transport checksums and AH would completely break at the receiving
host, which is probably no worse than not having the packet at all, but it
would be indistinguishable from an attack.

A more ECN-like mechanism along with the truncation of all the transport
data contents might be better; one has to keep the same originating IP in order to
pass through firewalls and ACLs, etc.  An interesting idea to discuss, though.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 May 2016 14:04:57 -0400

> experience on the current internet.

I agree.

It would be rather easy a thing to do for some big provider, maybe a CDN
could do an experiment.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 May 2016 08:35:54 +1200

> Does that sound reasonable?

Yes, very reasonable.

Thanks,
       Brian