Subject: Re: [6man] #9 (rfc2460bis): Header injection issue

From: "6man issue tracker" <[email-masked]>
Date: Tue, 28 Jun 2016 22:32:48 -0000

#9: Header injection issue

Comment (by [email-masked]):

 Proposed text in draft-ietf-6man-rfc2460bis-05.txt.

-- 
----------------------------------+------------------
 Reporter:  [email-masked]  |       Owner:
     Type:  defect                |      Status:  new
 Priority:  major                 |   Milestone:
Component:  rfc2460bis            |     Version:
 Severity:  In WG Last Call       |  Resolution:
 Keywords:                        |
----------------------------------+------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6man/trac/ticket/9#comment:1>
6man <https://tools.ietf.org/wg/6man/>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 28 Jun 2016 15:42:44 -0700

Hi,

The text I published in draft-ietf-6man-rfc2460bis-05.txt is:

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

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

After reviewing the mailing list discussion, I think this describes the issue and the current defined solution.  At the same time, it doesn’t prohibit other solutions to inserting extension headers in the future.

My take is that this is about the best we can do given the range of the views in the working group.  I think it is much better than saying nothing.  I don’t think we can get a consensus on anything significantly stronger.

Comments?

Bob

> On Jun 28, 2016, at 3:32 PM, 6man issue tracker <[email-masked]> wrote:
>

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 28 Jun 2016 22:48:23 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden

> After reviewing the mailing list discussion, I think this describes the issue
> and the current defined solution.  At the same time, it doesn’t prohibit
> other solutions to inserting extension headers in the future.

What about Brain C's point that it breaks IPsec authentication too? I mean, as long as we list PMTU, we might indicate IPsec "and other," perhaps?

Bert

---

From: Mark Smith <[email-masked]>
Date: Wed, 29 Jun 2016 11:07:01 +1000

On 29 Jun 2016 8:48 AM, "Manfredi, Albert E" <[email-masked]>
wrote:
> What about Brain C's point that it breaks IPsec authentication too? I
mean, as long as we list PMTU, we might indicate IPsec "and other," perhaps?

Actually, tunnel mode IPsec is another example of how to add EHs to a
pre-existing packet.

It's a little different to the RFC2473 example above because adding at
least one IPsec EH is of course necessary to perform IPsec functions.

Regards,
Mark.

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

---

From: 神明達哉 <[email-masked]>
Date: Wed, 29 Jun 2016 23:08:30 -0700

At Tue, 28 Jun 2016 15:42:44 -0700,
Bob Hinden <[email-masked]> wrote:

> After reviewing the mailing list discussion, I think this describes
> the issue and the current defined solution.  At the same time, it
> doesn’t prohibit other solutions to inserting extension headers in
> the future.
>
> My take is that this is about the best we can do given the range of
> the views in the working group.  I think it is much better than
> saying nothing.  I don’t think we can get a consensus on anything
> significantly stronger.
>
> Comments?

I don't like to be a stubborn blocker, but, I for one still have to
disagree that this is the best "compromise" we can make.  My points in
my previous comment still apply:
https://www.ietf.org/mail-archive/web/ipv6/current/msg24779.html

I also suggested a sense of alternate text, for which I've seen a few
positive feedback and (as far as I'm aware) no explicit objection.  So
I wonder whether we can adopt something like this.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Jun 2016 20:26:45 +1200

> I wonder whether we can adopt something like this.

The point about a compromise is that nobody gets exactly what they want.
Or, as a boss of mine once said, it's the best possible distribution
of unhappiness. On that basis, I support Bob's latest proposed text.

   Brian