Subject: Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 12 Apr 2017 08:34:30 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-6man-rfc2460bis-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

My discuss is mainly on text in section 4.8 (also based on the tsv-art
review -> Thanks Martin!):

I find the recommendation to basically just not use hop-by-hop headers in
section 4.8 extremely unsatisfying. Can we maybe do better? Wouldn't it
be maybe time to just deprecate the current hop-by-hop number an assign a
new one? I know that also has deployment problem but maybe it's worth a
try. I guess the assignment could happen in a new document though, but
the deprecation could be done here.

This related to this comment from Martin's review, also proposing a
potential way forward:
"- Section 4.8. "Defining New Extension Headers and Options":
It says new hop-by-hop headers must never ever defined. This is
problematic, as this closing the door forever, even if future instances
of the IETF do would like to wish to define new hop-by-hop headers. A
better way would have to say "that new hop-by-hop headers must have IETF
consensus".

- Section 4.8. "Defining New Extension Headers and Options":
Also the „not recommended“ to define new extension headers looks strange,
especially with the phrase "There has to be a very clear justification".
The term "clear justification" is not an exact engineering specification.
Why not using "technical protocol specification and real word use case
required, plus IETF consensus"?"

As a side note, there is at least one experimental RFC that defines a
destination option to be inspected by a network device, given the know
problems of hop-by-hop option which renders them unusable.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

One question because I'm not sure if I interpret this correct to make it
part of my discuss:
Section 4.5: "The number and content of the headers preceding the
Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet."
Does this mean the ECN codepoint (part of the Traffic Class field) is
copied from the first fragment? This doesn't seem to be correct, however,
also not sure what the correct answer is. I know this was not changed in
this revision but maybe we can still get this right.

---

From: [email-masked]
Date: Wed, 12 Apr 2017 22:35:52 +0200

Mirja,

See also Bob's response to Maritn.

> the deprecation could be done here.

The Hop-by-Hop header (HBH) is a container option. It has the protocol value 0, and has to be first in the header chain, so to make it efficient for routers to check for it's presence.

RFC2460 has:
  The Hop-by-Hop Options header is used to carry optional information
   that must be examined by every node along a packet's delivery path.

The problem with this was that implementations ended up punting packets with the HBH to software, essentially opening up for a DOS attack, which again led operators to filtering out packets with the HBH == 0.
(While at the same time there were no HBH options with cross Internet significance).

How the HBH option could be saved has been discussed for quite some time in the 6MAN working group.
Including a draft: https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03
Which conclusion got included into 2460bis.

The working group thought it premature to deprecate the HBH option header.
As a way to "rescue" the HBH option we have made one significant change:

NOTE: While [RFC2460] required that all nodes must examine and
process the Hop-by-Hop Options header, it is now expected that nodes
along a packet's delivery path only examine and process the Hop-by-
Hop Options header if explicitly configured to do so.

Which means by default routers unless they have been configured to process a particular option contained in an HBH option, shall forward the packet as normal. Thereby rectifying the attack vector.

What we lose by this approach is that one cannot use mandatory options anymore. I.e. options that MUST be processed by every router along the packet's path. RFC2675 for example is a mechanism depending on that. In our view this is not a problem, since routers with links with MTU larger than 64K would have to be configured and would be within a controlled domain anyhow.

> better way would have to say "that new hop-by-hop headers must have IETF

Yes, the door for a new HBH option header container is closed.
Given that this is the signal that every router has to check.
Given that this is a container option one can put whatever one likes into the existing HBH options header, so it would be hard to see the use case for a new one.

> required, plus IETF consensus"?"

   Defining new IPv6 extension headers is not recommended.  There has to
   be a very clear justification why any new extension header is needed
   before it is standardized.

The text does state "standardized" though.

Just to remind you that the Destination options header, the HBH options header and the Routing header are all container options, which allows for arbitrary number of TLVs inside. Since extension headers share the numbering space with upper layer protocols, defining new ones would require all implementations parsing header chains (e.g. to do packet filtering on transport headers) would have to be updated. This is the reason for the strict restriction on adding new ones.

> problems of hop-by-hop option which renders them unusable.

Right, that's a much more costly way of doing it, given that routers would now have to go and hunt for the particular sub option. This also violates RFC2460. And this would obviously neither achieve hop by hop behaviour.

When fragments are created most of the fields are copied from the IPv6 headers (e.g., Source Address, Destination address, flow label, traffic class, hop limit).  Some like payload length, next header, and hop limit are modified.

If I understand your question, the answer is yes, the ECN code point is copied from the first fragment, but should be the same from all of the fragments.

Best regards,
Ole

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 12 Apr 2017 23:48:17 +0200

Hi Ole,

see below.

> Am 12.04.2017 um 22:35 schrieb [email-masked]:
> 
> Mirja,
> 

Sorry, I meant hop-by-hop option in this case.
> Which means by default routers unless they have been configured to process a particular option contained in an HBH option, shall forward the packet as normal. Thereby rectifying the attack vector.

I’ve see this change and it’s a step in the right direction but it doesn’t solve the problem given there are already deployment that still put packets with an hop-by-hop header on the slow path which still renders the hop-by-hop header as currently defined unusable.

> What we lose by this approach is that one cannot use mandatory options anymore. I.e. options that MUST be processed by every router along the packet's path. RFC2675 for example is a mechanism depen…

Yes, I also don’t see that as a problem. It’s anyway always hard to ensure that something is process by every hop. Not sure that would have been achievable in reality every.

> Just to remind you that the Destination options header, the HBH options header and the Routing header are all container options, which allows for arbitrary number of TLVs inside. Since extension he…

See my response to Mike’s reply to Martin’s review: I think what you better should say is that it is recommended to use a destination option, if suitable, rather than a new header. I don’t think you need to anything else than this about new headers.

> Right, that's a much more costly way of doing it, given that routers would now have to go and hunt for the particular sub option. This also violates RFC2460. And this would obviously neither achiev…

It’s very costly but unfortunately currently the only way to achieve that at all. Given that this experimental option is intended to be inspected by only a few nodes on the path (not all) and usually these nodes are close the edge, it’s probably still doable.

> If I understand your question, the answer is yes, the ECN code point is copied from the first fragment, but should be the same from all of the fragments.

My concern is that the ECN code point could be changed on one of the fragmented packets to signal congestion of a intermediate node and then when you reassemble this information gets lost. That seems wrong.

Mirja

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Apr 2017 15:09:34 -0700

Mirja,

> On Apr 12, 2017, at 2:48 PM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi Ole,
> 
> see below.
> 

As it says in Section 4.8:

   Defining new IPv6 extension headers is not recommended.  There has to
   be a very clear justification why any new extension header is needed
   before it is standardized.  Instead of defining new Extension
   Headers, it is recommended that the Destination Options header is
   used to carry optional information that must be examined only by a
   packet's destination node(s), because they provide better handling
   and backward compatibility.

> My concern is that the ECN code point could be changed on one of the fragmented packets to signal congestion of a intermediate node and then when you reassemble this information gets lost. That see…

That is an interesting idea, but I think out of scope for advancing this document to Internet Standard.  Then there is the question of how to encode n of m fragments experienced congestion.  Interesting future work.

Thanks,
Bob

---

From: Michael Richardson <[email-masked]>
Date: Wed, 12 Apr 2017 18:37:22 -0400

{cutting out a bunch of lists}

[email-masked] wrote:
    > NOTE: While [RFC2460] required that all nodes must examine and process
    > the Hop-by-Hop Options header, it is now expected that nodes along a
    > packet's delivery path only examine and process the Hop-by- Hop Options
    > header if explicitly configured to do so.

    > Which means by default routers unless they have been configured to
    > process a particular option contained in an HBH option, shall forward
    > the packet as normal. Thereby rectifying the attack vector.

    > What we lose by this approach is that one cannot use mandatory options
    > anymore. I.e. options that MUST be processed by every router along the
    > packet's path. RFC2675 for example is a mechanism depending on that. In
    > our view this is not a problem, since routers with links with MTU
    > larger than 64K would have to be configured and would be within a
    > controlled domain anyhow.

What I don't understand is why, given that processing all options is now
opt-in, why the upper-bits have any meaning at all?
I thought we were going to deprecate the meaning, and then we weren't.

I also note that rfc2460bis doesn't update the host requirements, so
a host might still do the old thing, and the packet gets dropped anyway.

I wonder if we shouldn't hold rfc2460bis until we update host-requirements.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Apr 2017 13:45:31 +1200

On 13/04/2017 09:48, Mirja Kuehlewind (IETF) wrote:
...
> I’ve see this change and it’s a step in the right direction but it doesn’t solve the problem given there are already deployment that still put packets with an hop-by-hop header on the slow path whi…

I think I'm repeating myself due to jet lag, but this problem IMHO has *nothing* to do with
the current definition of HbH. It's to do with the very nature of HbH - something we are
asking *every* router in the Internet to do. The core routers in transit providers will
never do that. Redefining the HbH header cannot change that; it's intrinsic.

The above quoted Note was a WG consensus choice to resolve this issue, iirc, adapted
from section 2.2 of RFC7045.

    Brian

---

From: [email-masked]
Date: Thu, 13 Apr 2017 11:40:50 +0200

Hi Mirja,

> Sorry, I meant hop-by-hop option in this case.

Ack, and you can define new hop by hop options, as long as you are aware that with the new behaviour only nodes configured to process them will. And it is in general though to make expectations of these options being processed across administrative boundaries.

> I’ve see this change and it’s a step in the right direction but it doesn’t solve the problem given there are already deployment that still put packets with an hop-by-hop header on the slow path whi…

It has a somewhat higher drop probability but it is not unusable. When implementations are updated with the new behaviour then the hope is that it will become more usable.

> Yes, I also don’t see that as a problem. It’s anyway always hard to ensure that something is process by every hop. Not sure that would have been achievable in reality every.

Exactly.

> See my response to Mike’s reply to Martin’s review: I think what you better should say is that it is recommended to use a destination option, if suitable, rather than a new header. I don’t think yo…

A destination option would be the wrong thing to use. That violates the premise for how this option is used.
If you only want a certain set of nodes along a path to process the header, that is the behaviour you will now get with HBH.
An alternative is to use source routing with the routing header combined with a destination options header.

Just using the destination header for this is inefficient and is really a "give up" choice, where you end up requiring all routers to go and hunt for "interesting" options.

> It’s very costly but unfortunately currently the only way to achieve that at all. Given that this experimental option is intended to be inspected by only a few nodes on the path (not all) and usual…

HBH or RH also lets you do that. Note that destination options also has a higher drop probability than packets with extension headers.

> My concern is that the ECN code point could be changed on one of the fragmented packets to signal congestion of a intermediate node and then when you reassemble this information gets lost. That see…

I do see your point. Is this behaviour described somewhere else?

Best regards,
Ole

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 13 Apr 2017 13:19:47 +0200

Hi again,

> Am 13.04.2017 um 03:45 schrieb Brian E Carpenter <[email-masked]>:
> 

I might repeat myself as well but anyway. The above quoted text is fine but it does not solve the problem we have in reality. If the behavior would have been defined the way it is defined now from the beginning that would have been fine. However, there are router out there that put all packets that have the HBH header in the slow path which makes the HBH header unusable in practice. Redefining the behavior in the spec opens the door to fix that problem but the deploy router will not go away quickly, leaving a risk that your packets go on the slow path. Just because there is this risk, I would not recommend to use any HBH option (as the document does). However, if HBH are not usable, how can I then achieve the desired behavior (where some of the router on the path are allow to inspect and process some information in the IP extension header)?

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 13 Apr 2017 13:36:57 +0200

Hi again,

see below.

> Am 13.04.2017 um 00:09 schrieb Bob Hinden <[email-masked]>:
> 
> Mirja,
> 
Yes, this text is the text I have problem with. I think I would suggest to drop the first part and only have this part:

"It is recommended to rather use the Destination Options header 
to carry optional information that must be examined only by a
packet's destination node(s), instead of defining new Extension
Headers, because they provide better handling
and backward compatibility."

> That is an interesting idea, but I think out of scope for advancing this document to Internet Standard.  Then there is the question of how to encode n of m fragments experienced congestion.  Intere…

Yes there might be some more further work needed but that still makes the guidance in this text wrong. Maybe we can add some text that the Traffic Class may be handled differently because it could be changed on the path.

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 13 Apr 2017 13:31:12 +0200

> Am 13.04.2017 um 11:40 schrieb [email-masked]:
> 
> Hi Mirja,
> 

The draft says:

"New hop-by-hop options are not recommended because nodes may be
   configured to ignore the Hop-by-Hop Option header, drop packets
   containing a hop-by-hop header, or assign packets containing a hop-
   by-hop header to a slow processing path. Designers considering
   defining new hop-by-hop options need to be aware of this likely
   behaviour.“

Now I as a designer am aware that there are problems with HBH option and it might put my traffic on the slow path. I decide that I can’t risk that because that would downgrade the QoS and make my service unusable and I can’t even risk that because I would immediately lose costumers. However, I would like to signal something to midddleboxes that support this new fancy QoS mechanism that makes my service better. What should I do?

> It has a somewhat higher drop probability but it is not unusable.

Congestion control reacts to drop, thus you’ll get a very low throughput. Yes you still have connectivity, but I would call this unusable.

> When implementations are updated with the new behaviour then the hope is that it will become more usable.

Yes, but that will take a very long time and I can never be sure that I might not hit an old box somewhere on the path.

> Just using the destination header for this is inefficient and is really a "give up" choice, where you end up requiring all routers to go and hunt for "interesting" options.

I know but it WAS done because it was the only usable approach, see https://datatracker.ietf.org/doc/rfc7837/

Source routing is not an option here because the sender is not aware of the box on the path.

> HBH or RH also lets you do that. Note that destination options also has a higher drop probability than packets with extension headers.

I aware of this but it’s still better than HBH.

> I do see your point. Is this behaviour described somewhere else?

There is an RFC on ECN for tunneling https://tools.ietf.org/html/rfc6040
I don’t think there is anything on fragmentation specifically.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Apr 2017 13:50:06 +1200

On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote:
...
> Yes there might be some more further work needed but that still makes the guidance in this text wrong. Maybe we can add some text that the Traffic Class may be handled differently because it could…

Good point. It's not only ECN that can change; the DSCP can change too.
Both RFC2474 (diffserv) and ECN came after RFC2460, so it's logical
for 2460bis to note this issue.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Apr 2017 14:12:09 +1200

Still jet lagged but let me try:
> I might repeat myself as well but anyway. The above quoted text is fine but it does not solve the problem we have in reality. If the behavior would have been defined the way it is defined now from…

I have no good answer. We got this wrong originally, so what can we do in the Internet Standard except document the problem?

(I suspect that the real answer is that to install any kind of flow state, we need to use an explicit flow state creation protocol, not hang it off a packet header designed mainly for stateless processing. If that sounds like a short explanation of why Integrated Services/RSVP failed, it is. And it's surely out of scope for 2460bis.)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Apr 2017 14:28:44 +1200

And one more comment for today:
On 13/04/2017 23:36, Mirja Kuehlewind (IETF) wrote:

...
> and backward compatibility."

"Defining new IPv6 extension headers is not recommended" is a rather
mild statement. There were certainly some in the WG who wanted
a MUST NOT here. It's an operational and security concern: existing
middleboxes, especially firewalls, are allergic to extension headers
that they don't understand. This is unfortunate, since the design model
was that the forwarding path should be transparent to all headers, which
meant that new headers could be deployed between consenting adults
without any infrastructure issues. But this simply doesn't work in
the real world - that's the main reason we wrote RFC7045. I think it's
worth quoting this:

   This combination of circumstances creates a "Catch-22" situation
   [Heller] for the deployment of any newly standardised extension
   header except for local use.  It cannot be widely deployed because
   existing middleboxes will drop it on many paths through the Internet.
   However, most middleboxes will not be updated to allow the new header
   to pass until it has been proved safe and useful on the open
   Internet, which is impossible until the middleboxes have been
   updated.

So, defining new IPv6 extension headers is not recommended, because
they probably won't work across the Internet. But it isn't a MUST NOT,
because if there was a compelling operational case, we could do it and
the middleboxes would follow.

RFC 7045 was intended to nudge middlebox developers in the right
direction, and similarly draft-ietf-opsec-ipv6-eh-filtering. But it's
an uphill battle.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Apr 2017 15:15:30 +1200

Mirja raised the issue of the ECN bits possibly being different in different
fragments. The same is true of the DSCP bits, if there is a diffserv 
re-marker on the path. However, I realised that this is already stated
by the existing text:

>>> 7.  Traffic Classes
>>>
>>> The 8-bit Traffic Class field in the IPv6 header is used by the
>>> network for traffic management.  The value of the Traffic Class bits
>>> in a received packet might be different from the value sent by the
>>> packet's source.

For clarity, we could change that to

>>> 7.  Traffic Classes
>>>
>>> The 8-bit Traffic Class field in the IPv6 header is used by the
>>> network for traffic management.  The value of the Traffic Class bits
>>> in a received packet or fragment might be different from the value
>>> sent by the packet's source.

The text also what happens when a packet is re-assembled:

>>>    The Per-Fragment Headers of the reassembled packet consists of all
>>>    headers up to, but not including, the Fragment header of the first
>>>    fragment packet...

so the Traffic Class in the first fragment will always win.

Obviously, any more sophisticated algorithm during re-assembly
is out of scope for the promotion to Internet Standard, since it
would be a new requirement.

    Brian

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 15 Apr 2017 15:49:58 +0200

Hi Brian,

thanks for splitting the discussion up into it’s three piece. However, i’m answering this one first because there is some relation to the other one on HBH. Further see below.

> Am 14.04.2017 um 04:28 schrieb Brian E Carpenter <[email-masked]>:
> 

First of all yes, giving further explanation/background is definitely a good thing to do, and maybe also provide a reference to rfc7045 if appropriate.

I think I agree that I would not like to make a normative statement here, given that the circumstances are not due to the protocol design itself but because of the current deployment situation we have (which in theory could change in future).

However, instead of making a clear recommendation to not every define a new extension header, I think I would prefer if the text was phrased in the a way that would make the risk clear, give a clear recommendation to rather use destination options if suitable, and then say nothing else.

Maybe you can work on some new text and then have a quick (?) check with the wg which text is preferred. If there is clear consensus for one way by the wg I will not further block this.

However, please see my next mail.

Mirja

P.S.: My understanding from the text above is that the new extension header will be dropped but not the whole packets. Is that right? Because in this case there are still ways for experimentation.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 15 Apr 2017 16:01:15 +0200

Hi again,

(sorry I#ve sent an empty reply a moment ago. Here is my reply now.)

see below.

> Am 14.04.2017 um 04:12 schrieb Brian E Carpenter <[email-masked]>:
> 

We could actually deprecate the HBH header, and eventually define a new one/assign a new number (at some later point). And this is exactly the case where I see a new extension header coming up.

As I said in my original discuss it’s just very unsatisfying to change the HBH handling (correctly) and then say it’s not recommended to use it.

One more point: I recently realized is that given the destination option and the HBH option use the same registry, it actually is very tempting to simply use the destination option header with HBH options because no current router will inspect it and only new boxes that support the new feature (at the edge) may start looking into it. Just as another side note on what we might see happening in future with this recommendation.

> (I suspect that the real answer is that to install any kind of flow state, we need to use an explicit flow state creation protocol, not hang it off a packet header designed mainly for stateless pro…

I agree (I’m working on PLUS for this reason but that’s a different topic). Nothing we have to or should address in this document. But we could be more clear and go the next step and deprecate HBH. I didn’t follow the document or wg discuss closely but to my understanding the option to deprecate HBH was not really discuss in the group. Was it?

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 15 Apr 2017 15:50:10 +0200

---

From: [email-masked]
Date: Sat, 15 Apr 2017 20:13:12 +0200

Mirja,

[...]

> As I said in my original discuss it’s just very unsatisfying to change the HBH handling (correctly) and then say it’s not recommended to use it.

The recommendation not to use it, is because the expectation that an application can give all routers along the packet's delivery path instructions, that will be adhered to is wrong. Essentially we're saying that the HBH option should be mostly ignored, and I would expect mostly have applicability within one administrative domain.

> One more point: I recently realized is that given the destination option and the HBH option use the same registry, it actually is very tempting to simply use the destination option header with HBH…

I don't understand why you see using a destination option solves anything.
That will just end up being subject to the same operational policies as the HBH header.
And note any packet that doesn't have the TCP or UDP header directly following the IP header has a significantly higher drop probability anyway.

> I agree (I’m working on PLUS for this reason but that’s a different topic). Nothing we have to or should address in this document. But we could be more clear and go the next step and deprecate HBH.…

Some people have even been discussing deprecating extension header altogether.
The working group decided not to deprecate the HBH header at this point. As in, we still think it can be rescued.

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Apr 2017 09:02:32 +1200

Comment at the end:
> The working group decided not to deprecate the HBH header at this point. As in, we still think it can be rescued.

I just went through the IANA registry. At the moment there are:

4 standards-track HbH options (jumbogram, router alert, RPL, MPL)
3 Experimental HbH options (Quick Start, SMF-DPD, IP-DFF)
1 US-DOD option (CALIPSO)

I really don't see deprecation of all these as a possibility. RPL and MPL are recent work; deprecating router alert would deprecate RSVP for IPv6. RPL, MPL, and jumbograms are all clearly "consenting adults" scenarios where packets will not cross the Internet.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Apr 2017 10:14:29 +1200

> Maybe you can work on some new text and then have a quick (?) check with the wg which text is preferred. If there is clear consensus for one way by the wg I will not further block this.

I think I will leave that for the document editor. A large part of RFC7045 is about this issue but Bob can probably see best how to integrate it here.

> P.S.: My understanding from the text above is that the new extension header will be dropped but not the whole packets. Is that right? Because in this case there are still ways for experimentation.

No, the firewalls simply drop packets that they don't like. (This is the main reason why SHIM6 is undeployable. But more seriously, it means that even IPv6 fragmentation is impossible on some paths.) That's why we really need draft-ietf-opsec-ipv6-eh-filtering to progress, so that there is consistent guidance.

    Brian

> .

---

From: [email-masked]
Date: Sun, 16 Apr 2017 13:40:51 +0200

> I really don't see deprecation of all these as a possibility. RPL and MPL are recent work; deprecating router alert would deprecate RSVP for IPv6. RPL, MPL, and jumbograms are all clearly "consenti…

Thanks Brian.

Cheers,
Ole

---

From: [email-masked]
Date: Sun, 16 Apr 2017 13:57:38 +0200

Brian, Mirja,

> I think I will leave that for the document editor. A large part of RFC7045 is about this issue but Bob can probably see best how to integrate it here.

I think what is in the document already is representing the working group consensus.
The issues of new / unknown extension headers, and how to distinguish these from new transport protocols have been discussed from many angles. The two main reasons for the strong recommendation against new extension headers are:
 - most uses are already accommodated with the 3 existing containers options (routing. hbh and destination)
 - sharing the same number space with IP protocols, makes it hard for intermediate devices depending on parsing the header chain to find transport information if new headers were introduced.

There is already an opening / provision in the text for new extension headers. The text only asks for these considerations to be made, before proposing new ones.

> No, the firewalls simply drop packets that they don't like. (This is the main reason why SHIM6 is undeployable. But more seriously, it means that even IPv6 fragmentation is impossible on some paths…

Dropping only a header as in deleting it, would violate the specification. And would certainly violate the expectation hosts have from network behaviour.

The opsec-ipv6-eh-filterting draft is at best dangerous and is prohibitive of future evolution. I would strongly object to its publication.

With regards to Brian's point. No IETF recommendation will make much of a difference if the network policy in place is to inspect transport header information. Packets which do not have the transport header will be subject to a higher drop probability. If there is any comfort IPv4 fragments suffer a worse faith than IPv6 ones (in IPv4ng transport ports are used for forwarding).

Best regards,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Sun, 16 Apr 2017 08:38:01 -0700

Hi,

> On Apr 16, 2017, at 4:57 AM, [email-masked] wrote:
> 
> Brian, Mirja,
> 

I agree.

I also note that the text in this section was derived from RFC6564, which updated RFC2460.  Specifically from Section 3 of RFC6564:

   Mindful of the need for compatibility with existing IPv6 deployments,
   new IPv6 extension headers MUST NOT be created or specified, unless
   no existing IPv6 extension header can be used by specifying a new
   option for that existing IPv6 extension header.

New extension headers are allowed (just not recommended) and the next paragraph in the Section specifies a format that should be used for new Extension headers.  I think there is a lot of flexibility going forward.

Bob

---

From: Tom Herbert <[email-masked]>
Date: Sun, 16 Apr 2017 17:10:28 -0700

> The working group decided not to deprecate the HBH header at this point. As in, we still think it can be rescued.
Ole,

I hope HBH can be rescued also!

The alternative to putting L3 information in seems to be to embed the
information somewhere in the transport layer. Mobile throughput
guidance (draft-flinck-mobile-throughput-guidance) suggests to put
this in TCP options, PLUS suggested to put this data in protocol
header in UDP payload, and we have seen other similar proposals. In
these proposals, the intent was that intermediate devices would
perform DPI into transport layer or the payload, and in some cases it
was even suggested that intermediate devices might modify UDP payload
etc. Personally, I think these violate the end to end model, but there
were arguments that they don't.

I believe HBH options (and really all EH) is a classic chicken an egg
problem: they are not supported in the Internet because no one uses
them, and no one uses them because they're not supported in the
Internet. This stalemate may be changing though in some networks that
have control over the devices so that HBH could be meaningfully
deployed (the allowance that routers may ignore them is critical for
this). I imagine this why the issue of EH insertion versus tunneling
is so important as HBH can be very useful for transit over particular
networks.

Tom

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

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 16 Apr 2017 23:57:30 -0400

Hi Mirja/Bob,

>    option for that existing IPv6 extension header.

Yes. This text was arrived at after a lot of discussion in the 6man WG
during the development of the draft that became RFC6564.

> New extension headers are allowed (just not recommended) and the next paragraph in the Section specifies a format that should be used for new Extension headers.  I think there is a lot of flexibili…

Yep. I think the above warning is issued because a node processing an
unknown extension header will simply drop it, and this makes
incremental deployability of these new extension headers difficult
over the Internet.

Thanks
Suresh

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 18 Apr 2017 21:58:20 +0200

sorry it’s late here…

s/formation/formulation/
s/no go advice/no good advice/

> Am 18.04.2017 um 21:49 schrieb Mirja Kuehlewind (IETF) <[email-masked]>:
> 
> This might be rather an editorial issue now but the formation in RFC6564 is fully fine with me because it says „MUST NOT unless no option can be used“. That’s basically what I proposed. The formulation in 2460 however is "Defining new IPv6 extension headers is not recommended.“. I think this is overstated and technically no go advise.
> 
> Mirja
> 
> 
>> Am 17.04.2017 um 05:57 schrieb Suresh Krishnan <[email-masked]>:
>> 
>> Hi Mirja/Bob,
>> 
>>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 18 Apr 2017 21:49:55 +0200

Mirja

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Apr 2017 15:15:05 +1200

In reality "MUST NOT unless..." means about the same as "SHOULD NOT" so
I think we agree that this is editorial. Aligning the language with RFC6564
makes a lot of sense to me.

    Brian

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 19 Apr 2017 08:54:17 +0200

The difference for me it that in one case a condition is specified, while the other one is a general statememt.

> Am 19.04.2017 um 05:15 schrieb Brian E Carpenter <[email-masked]>:
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 19 Apr 2017 13:22:45 +0200

Let me try to wrap this up. So what I learn is that HBH is used in intra-domain scenarios and therefore must be further supported and today’s routers are highly likely to drop packets with unknown headers. In this sense I think the recommendation given could be further clarified. Also I would rather see a discussion of the issue than just given a specific recommendation forever, while people have still hope that the situation might change (at least for HBH I assume). As such I’ll go ahead and would like to propose new text for the paragraphs in question, that is intended to conserve the current recommendation but giving more background and phrase it more carefully. Of course feel free to edit, I just thought it might be easier if I simply propose some text:

OLD:
   New hop-by-hop options are not recommended because nodes may be
   configured to ignore the Hop-by-Hop Option header, drop packets
   containing a hop-by-hop header, or assign packets containing a hop-
   by-hop header to a slow processing path.  Designers considering
   defining new hop-by-hop options need to be aware of this likely
   behaviour.  There has to be a very clear justification why any new
   hop-by-hop option is needed before it is standardized.

NEW:
   Network nodes may be
   configured to ignore the Hop-by-Hop Option header, drop packets
   containing a hop-by-hop header, or assign packets containing a hop-
   by-hop header to a slow processing path. When using or defining new 
   hop-by-hop options this likely behaviour need to be taken into 
   account. While hop-by-hop option may be used for management purposes
   within one domain, measures should be take to detect these problem
   if hop-by-hop options are used end-to-end.

   Network notes further may be configured to drop packets with unknown 
   IPv6 extension headers. Therefore, instead of defining new Extension
   Headers, it is recommended that the Destination Options header is
   used to carry optional information that must be examined only by a
   packet's destination node(s).

Or alternatively the text from RFC6564 can be used directly instead of this second paragraph. However, there are actually two paragraph in RFC6564, one with a SHOULD and one with a MUST…?

   "… Because of this, implementations SHOULD use
   destination options as the preferred mechanism for encoding optional
   destination information, and use a new extension header only if
   destination options do not satisfy their needs.  The request for
   creation of a new IPv6 extension header MUST be accompanied by a
   specific explanation of why destination options could not be used to
   convey this information.“

and 

   "Mindful of the need for compatibility with existing IPv6 deployments,
   new IPv6 extension headers MUST NOT be created or specified, unless
   no existing IPv6 extension header can be used by specifying a new
   option for that existing IPv6 extension header.  Any proposal to
   create or specify a new IPv6 extension header MUST include a detailed
   technical explanation of why no existing IPv6 extension header can be
   used in the document proposing the new IPv6 extension header.“

There is also a paragraph on HBH in RFC6564 but given that routers are not requirement anymore to process the HBH option, I assume that’s not up-to-date anymore?

I hope that helps!
Mirja

---

From: [email-masked]
Date: Thu, 20 Apr 2017 11:29:09 +0200

Mirja,

> Let me try to wrap this up. So what I learn is that HBH is used in intra-domain scenarios and therefore must be further supported and today’s routers are highly likely to drop packets with unknown…

"today's routers are highly likely to drop packets with unknown headers".
No, I do not think we have data supporting that.

Packets with unknown headers are most likely to be dropped at the destination or by the destination AS. Which makes sense and one would expect. If extension headers / options were defined that were useful, one would also expect that the destination would stop dropping them of course. Chicken and egg.

Dropping unknown extension headers in transit networks is relatively rare. With the HBH being an exception, with almost a 40% drop. (Note that there are no HBH option that would make a lot of sense across the Internet, so again chicken and egg.)

Data from:
https://btv6.vyncke.org/exthdr/index.php?ds=alexa2015&t=do

With regards to your text, I certainly wouldn't say "Network nodes may be configured to drop...". That's exactly the opposite of what we would like to say. ;-)

The current (OLD) text went through many many iterations in the working group. I must say I still prefer that text, and I'm not sure what value the new proposal adds. Adding new extension headers are of course still permitted (within the number space available). This note I really there as a "Reader beware, there are dangers in these waters".

In the context of elevating 2460 I really don't think there is anything wrong with the current text. We are limited by RFC6410 in what we can do. If you want different and new behaviour there is of course nothing stopping you from proposing that in a separate document.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Apr 2017 14:01:18 +0100

Ole,

On 04/20/2017 10:29 AM, [email-masked] wrote:
> Mirja,
> 
>> Let me try to wrap this up. So what I learn is that HBH is used in
>> intra-domain scenarios and therefore must be further supported and
>> today’s routers are highly likely to drop packets with unknown
>> headers. In this sense I think the recommendation given could be
>> further clarified. Also I would rather see a discussion of the
>> issue than just given a specific recommendation forever, while
>> people have still hope that the situation might change (at least
>> for HBH I assume). As such I’ll go ahead and would like to propose
>> new text for the paragraphs in question, that is intended to
>> conserve the current recommendation but giving more background and
>> phrase it more carefully. Of course feel free to edit, I just
>> thought it might be easier if I simply propose some text:
> 
> "today's routers are highly likely to drop packets with unknown
> headers". No, I do not think we have data supporting that.
> 
> Packets with unknown headers are most likely to be dropped at the
> destination or by the destination AS. Which makes sense and one would
> expect. If extension headers / options were defined that were useful,
> one would also expect that the destination would stop dropping them
> of course. Chicken and egg.
> 
> Dropping unknown extension headers in transit networks is relatively
> rare. With the HBH being an exception, with almost a 40% drop. (Note
> that there are no HBH option that would make a lot of sense across
> the Internet, so again chicken and egg.)

Based on RFC7872 ("Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World"), your statement is incorrect.

Transit routers do filter packets with EHs, whether known or unknown.

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

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Apr 2017 08:47:08 -0700

Fernando,

> On Apr 20, 2017, at 6:01 AM, Fernando Gont <[email-masked]> wrote:
> 
>> ….
>> 

I think this confirms that the current text which recommends against defining new EH is correct.

Thanks,
Bob

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 20 Apr 2017 08:59:02 -0700

somewhat oldish data points:
http://www.iepg.org/2013-11-ietf88/fgont-iepg-ietf88-ipv6-frag-and-eh.pdf

IPv6 Extension Header (8 bytes) – Failure rate: 52.53 %
IPv6 Extension Header (1 KBytes) – Failure rate: 92.17 %
 
Cheers,
Jeff

On 4/20/17, 08:47, "ipv6 on behalf of Bob Hinden" <[email-masked] on behalf of [email-masked]> wrote:

    Fernando,

    
    Thanks,
    Bob

---

From: [email-masked]
Date: Thu, 20 Apr 2017 18:14:57 +0200

Jeff,

> IPv6 Extension Header (1 KBytes) – Failure rate: 92.17 %

Those numbers are alternative facts. They include the destination system.
It would be as if you reported a 99.5% failure rate of SCTP because the end system didn't respond on the echo port.

For reasons one can only speculate about the authors of RFC7872 chose to show their numbers the same way.

From 7872:
                      DO8
| Web      |      11.88%
| servers  | (17.60%/20.80%)

Which means a drop rate by intermediate systems of 2.4%. A little less sensational.

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Apr 2017 13:29:45 -0300

Ole,

RFC7872 was a while document. It followed the normal publication process,
and we did do our best to address which comments. If this was published as
it was, is because we didn't find a better way to convey the info. So I'm
not sure what your speculation is about, but this is not the first time
that I see see trying to find obscure reasons, when in fact there aren't
any.

As a datapoints, I started measuring EH drops because there was a lot of
talk about the topic, but no data. I spent quite a lot of time on tools and
measurements, assuming that the numbers would be better -- but they just
were not (without double-checking your math, a 2.5% drop rate by
intermediate Asses is still quite bad. And in fact, such numbers could
actually be worse (read RFC7872 for the rationale)).

What I'm really curious is how/why you pretend that EHs work just fine and
argue that there's no data (when we even have RFC7872 with data
specifically about this) -- and also why at the time you opposed to
publication of such document (something which would have made your claim of
"this is just speculation, there's no data" valid).

PS: Give how the term "alternative facts" is being employed in modern
times, I'd probably agree with you that RFC7872 provides alternative facts,
though.

Thanks,
Fernando

El 20/4/2017 17:15, <[email-masked]> escribió:

Jeff,

Those numbers are alternative facts. They include the destination system.
It would be as if you reported a 99.5% failure rate of SCTP because the end
system didn't respond on the echo port.

For reasons one can only speculate about the authors of RFC7872 chose to
show their numbers the same way.

                      DO8
| Web      |      11.88%

Which means a drop rate by intermediate systems of 2.4%. A little less
sensational.

Cheers,
Ole

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 20 Apr 2017 17:09:48 +0000

> On Apr 20, 2017, at 5:47 PM, Bob Hinden <[email-masked]> wrote:
> 
> Fernando,
> 

Well, in fact I believe it’s the exact opposite.

Definition of new EHs must be done carefully but I don’t see why it should be prevented, knowing also that transit routers would anyway filter EH-packets out (hence mitigate the impact of new EHs introduction).

EH is probably _the_ most innovative and powerful feature of ipv6. 

s.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Apr 2017 10:23:44 -0700

Stefano,

> On Apr 20, 2017, at 10:09 AM, Stefano Previdi (sprevidi) <[email-masked]> wrote:
> 
> 

The current text is:

Following this text is the recommended format for new extension headers if they are defined.

I think is inline with what you said, that is “done carefully” and not prevented.

Bob

---

From: [email-masked]
Date: Thu, 20 Apr 2017 20:54:48 +0200

Fernando,

> RFC7872 was a while document. It followed the normal publication process, and we did do our best to address which comments. If this was published as it was, is because we didn't find a better way to convey the info. So I'm not sure what your speculation is about, but this is not the first time that I see see trying to find obscure reasons, when in fact there aren't any.
> 
> As a datapoints, I started measuring EH drops because there was a lot of talk about the topic, but no data. I spent quite a lot of time on tools and measurements, assuming that the numbers would be better -- but they just were not (without double-checking your math, a 2.5% drop rate by intermediate Asses is still quite bad. And in fact, such numbers could actually be worse (read RFC7872 for the rationale)).
> 
> What I'm really curious is how/why you pretend that EHs work just fine and argue that there's no data (when we even have RFC7872 with data specifically about this) -- and also why at the time you opposed to publication of such document (something which would have made your claim of "this is just speculation, there's no data" valid).

I don't pretend EHs (or pretty much anything on the Internet) work just fine.
I only ask you to represent your measurements in an open and honest way.
What the RFC does and even more so the presentation Jeff pointed at is spreading FUD and does not in any way help the community.

I do not think a drop rate in the area of 2.5% warrants:
"today's routers are highly likely to drop packets with unknown headers".

And that's the problem with your sensationalist way of presenting the data, people are left with the impression that EHs are not possible to use.

I don't know if 2.5% is a high number or not. In this from RIPE, 8-9% of RIPE Atlas probes have problems with IPv4 fragmentation.
https://labs.ripe.net/Members/emileaben/ripe-atlas-packet-size-matters

Ole

> 
> PS: Give how the term "alternative facts" is being employed in modern times, I'd probably agree with you that RFC7872 provides alternative facts, though.
> 
> Thanks,
> Fernando
> 
> 
> 
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Apr 2017 08:22:26 +1200

> I think this confirms that the current text which recommends against defining new EH is correct.

Hate to say it, but yes, IMHO that was a clear WG consensus and I don't think
the IESG has the right to override it.

On 21/04/2017 05:09, Stefano Previdi (sprevidi) wrote:
...
> Definition of new EHs must be done carefully but I don’t see why it should be prevented,

which is exactly why the consensus is *not recommended* rather than *must not*.
Even without formally using RFC2119, the distinction is clear.

Why are we re-litigating this?

On 21/04/2017 06:54, [email-masked] wrote:
...
> "today's routers are highly likely to drop packets with unknown headers".

That's beside the point for 2460bis. The point is that unknown EHs are dropped
on *some* paths, which makes deploying them tricky, regardless of the percentage.

    Brian

    Brian

---

From: [email-masked]
Date: Thu, 20 Apr 2017 22:31:25 +0200

Brian,

> on *some* paths, which makes deploying them tricky, regardless of the percentage.

of course. but it is a difference between something that is "fixable" and something that is not.
if you read my comments as suggesting anything but support for the current text from the WG, then I apologise.

Best regards,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Apr 2017 10:48:26 +1000

We worry too much about the installed base.  The installed base can
always be fixed.  It may take sometime but it can be done.  You
just have to be willing to deal with less than perfect for a while.

A lot of this is just firewall setting.  These can be changed.  It
just requires people to be willing to ask that changes be made.

I've asked the US Military to fix their firewall settings because
they were breaking legitimate DNS lookups.  It took a month but the
firewalls were fixed to allow the queries through.

I've sent mail to Federal Ministers to get other firewalls in front
of DNS servers fixed.

It can be done.  You just need to raise enough of a stink.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 21 Apr 2017 08:16:51 +0000

> On Apr 20, 2017, at 7:23 PM, Bob Hinden <[email-masked]> wrote:
> 
> Stefano,
> 

well, the text starts with “Defining new IPv6 extension headers is not recommended.” which is, to me, a clear intention to close the door.

Anyway, it’s just one more issue on the list that this document has.

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 21 Apr 2017 08:21:33 +0000

> On Apr 20, 2017, at 10:22 PM, Brian E Carpenter <[email-masked]> wrote:
> 

well, there’s been another WG consensus that has been overridden by IESG so what’s the algorithm exactly ?

s.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Apr 2017 12:24:39 +0100

> I think this confirms that the current text which recommends against defining new EH is correct.

Yes. Our best possible outcome is that we get *existing* EHs to *not* be
filtered. I think it's *extremely* unlikely that one could get new EHs
to work. So I fully support recommending against the definition of new EHs.

Thanks!

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Apr 2017 12:59:56 +0100

Ole,

On 04/20/2017 07:54 PM, [email-masked] wrote:
> Fernando,
> 
>> RFC7872 was a while document. It followed the normal publication
>> process, and we did do our best to address which comments. If this
>> was published as it was, is because we didn't find a better way to
>> convey the info. So I'm not sure what your speculation is about,
>> but this is not the first time that I see see trying to find
>> obscure reasons, when in fact there aren't any.
>> 
>> As a datapoints, I started measuring EH drops because there was a
>> lot of talk about the topic, but no data. I spent quite a lot of
>> time on tools and measurements, assuming that the numbers would be
>> better -- but they just were not (without double-checking your
>> math, a 2.5% drop rate by intermediate Asses is still quite bad.
>> And in fact, such numbers could actually be worse (read RFC7872 for
>> the rationale)).
>> 
>> What I'm really curious is how/why you pretend that EHs work just
>> fine and argue that there's no data (when we even have RFC7872 with
>> data specifically about this) -- and also why at the time you
>> opposed to publication of such document (something which would have
>> made your claim of "this is just speculation, there's no data"
>> valid).
> 
> I don't pretend EHs (or pretty much anything on the Internet) work
> just fine. I only ask you to represent your measurements in an open
> and honest way. What the RFC does and even more so the presentation
> Jeff pointed at is spreading FUD and does not in any way help the
> community.

To be honest I find your statement rather disrespectful, for at least
these reasons:

1) The fact that you might have preferred to present the data in a
different way, doesn't make the document or the authors dishonest. The
document discusses the measurements in detail So anyone that *reads* the
document will understand what the numbers mean. (*)

2) You've recently argued that wg documents are "owned" by the wg, and
it's the wg that controls the changes to documents -- fair enough. Now,
for this particular document, you blame *the authors* rather than the
wg. Is that honest?  (and no: I don't think there's anyone to blame)
This wa a wg product. If you didn't like how the data were presented,
you should have made your point, and we'd have modified the document.
Instead, you simply opposed to publishing the document, rather than
helping us improve it. But now you complain, and claim the document (or
us, who knows) were dishonest. That's certainly not fair.

3) If you think data could have been represented in a better way, you
should have made your point, and if the wg considered your point valid,
we would have changed the I-D. (I wouldn't have had any issues in
changing the doc accordingly, myself). Me, I think the value in the
document is in providing data for a topic on which there was a lot of
talk, but no data... so I couldn't care least about the outcome of the
measurements.

(*) The document originally just contained results for the drops,
irrelevant of the AS. Then you asked about "where in the network do such
packets occur", that's why we phrased it as "X of such drops occur at
different ASes". Taking the look at the doc again (without looking at it
for quite a while, I realize that if someone *quickly looks at the
tables and doesn't read the text* might get confused. But there's
nothing like dishonesty or intention in that.

> I do not think a drop rate in the area of 2.5% warrants: "today's
> routers are highly likely to drop packets with unknown headers".

There are many aspects here. e.g.:

1) 2.5% is the best case scenario of all of them (we fail on "it's
filtered by the dest AS" when in doubt, but this need not be the case).

2) You assume that the folk to which packets are destined has control
over what his AS filters. This need not be the case.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Apr 2017 13:03:01 +0100

> if you read my comments as suggesting anything but support for the current text from the WG, then I apologise.

I don't know what fixable is. Striclty speaking, lots of things are
"fixable", including e.g. poverty, people dying of curable diseases,
etc. Whether that's *feasible* is a different thing.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Fri, 21 Apr 2017 16:31:01 +0200

>over what his AS filters. This need not be the case.

Note that I think that the current extension headers are by and large a
failure.

But absent that, your measurements seem to have an implicit assumption that
anyone would spend resources on a feature that isn't used. So without a
compelling use case for HBH or Dest. options, it makes a lot of sense to
just drop those packets. 

You can see that clearly if you compare support for an extension header in a
context where that header makes sense with one where it doesn't

For example, support for fragmented DNS replies is way higher than support
for fragmented TCP packets.

So if you want to argue that the current internet is not transparent to
various unused features, then yes that's true and has been known to be true
for a couple of decades.

That said, I doubt that any use case is compelling enough that wide spread
support will develop. But using current filtering statistics to argue that
such support will never develop goes a bit far.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Apr 2017 12:34:31 -0300

Hi, Phillip,

Apologies for top-posting (mobile phone, and quoting capabilities are
awful).

Just wanted to clarify a few things:

1) RFC7872 simply provides data about drop rates, and does not speculate
about the reasons for such packet drops.

2) While I'm inclined to think that deploying new EHs would be harder than
getting the existing EHs to work, there's no way.I can predict the future.
Nor do I claim I can tell what may or.may not happen.

3) I do believe that getting closer to the ops folks and trying to
understand why they do what they do (rather than simply trashing them for
"breaking the Internet") is probably one of the most sensible things to do
if we want the situation to improve.

4) I think rfc2460bis is correct in the advise being provided in this area
("defining new EHs is not recommended").

Thanks!

Cheers,
Fernando

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Apr 2017 19:26:05 +0200

> to work. So I fully support recommending against the definition of new EHs.

​All this means that instead of endorsing deployment of IPv6 you guys are
just shutting it down for a lot of customers and networks.

With no future innovation in transport protocol what will happen is that it
is now IPv6 which will be encapsulated in MPLS or IPv4+MPLS and carried
over.

Great progress indeed !

Cheers,
R.

PS.

Perhaps most folks voting against SRH insertion in any transit node in the
Internet or making recommendation against defining any new EHs are just
completely detached from real hardware development, P4 programming,
flexible packet processors coming as we speak from various vendors etc ...
What are you guys using in your networks ? Optimistically assuming that you
actually even have real networks to operate.

It's like an attempt here to make a perfect baloon for any air travel and
never add anything to it as it may fall.

---

From: [email-masked]
Date: Fri, 21 Apr 2017 21:38:36 +0200

Hi Robert,

> ​All this means that instead of endorsing deployment of IPv6 you guys are just shutting it down for a lot of customers and networks.
> 
> With no future innovation in transport protocol what will happen is that it is now IPv6 which will be encapsulated in MPLS or IPv4+MPLS and carried over.
> 
> Great progress indeed !
> 
> Cheers,
> R.
> 
> PS.
> 
> Perhaps most folks voting against SRH insertion in any transit node in the Internet or making recommendation against defining any new EHs are just completely detached from real hardware development, P4 programming, flexible packet processors coming as we speak from various vendors etc ... What are you guys using in your networks ? Optimistically assuming that you actually even have real networks to operate.
> 
> It's like an attempt here to make a perfect baloon for any air travel and never add anything to it as it may fall.

This is really not what those changes in 2460bis are intended to do.
Within the context of elevating 2460 to Internet standard, we can't add new features.

That does in no way stop anyone from proposing _new_ work. Of any sort.

Best regards,
Ole

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Apr 2017 22:09:33 +0200

​Hi Ole,​

> That does in no way stop anyone from proposing _new_ work. Of any sort.

​Very true ! Anyone can propose anything in IETF.

But with the text additions which I have seen here recently the bar to move
from individual's draft proposal to WG doc then via all LCs to Standards
Track RFC just went up significantly higher especially for SRH and EH
elements. ​

And that's my point.

Cheers,
R.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Apr 2017 11:18:20 +1200

> well, there’s been another WG consensus that has been overridden by IESG so what’s the algorithm exactly ?

It's fine if IESG review raises an issue and the WG agrees to the suggested change. But in this case I don't personally see any change in the WG's collective opinion. See the first two bullets at
https://www.ietf.org/iesg/statement/discuss-criteria.html

(Full disclosure: I was IETF Chair when those criteria were agreed and published.)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Apr 2017 11:34:34 +1200

> Track RFC just went up significantly higher especially for SRH and EH

But *our* point, for some definition of 'our', is that by making the
Internet-wide situation clear, we are in fact clearing the way for careful
definition of local-use mechanisms. At the moment, as we've clearly seen
from discussion of the SRH, we simply can't have that discussion because
of the unfortunate ambiguity of RFC1883 and RFC2460. Truly, the quicker
we get that settled and approved by the IESG, the quicker we can look
seriously at draft-voyer-6man-extension-header-insertion.

You might ask yourself why no IPv4 options have been defined since 2007
(Quick Start) and before that, 1997 (Router Alert). The same reason: they
don't survive a trip across the Internet.

    Brian

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 22 Apr 2017 09:28:12 +0200

Hi Brian,

In every other email I see a concern about "Internet" or "Internet-wide"
behavior.

To me Internet is a collection of *independent* chain of Autonomous
Systems. As name indicates those domains are **autonomous** and can do
whatever they like to do with packets they carry. If they do not choose to
do right things customers will avoid them, there will be no revenue and
they will disappear from Internet map. Pure and simple.

I find it very bizarre that IETF is trying to be a judge or policer to
dictate on what each AS can or can not do in their own network. Moreover it
also apparently is putting least common denominator rule which states that
all 50000 ASes should do MUST only be limited to what the weakest AS can do
with either old or incapable vendors to support innovation.

I was apparently very wrong assuming for all those years that IETF focus is
to make sure that protocol extensions we define are as best as we are
collectively able to do .. rather then community to worry what hardware
vendors will manage to support or not support in what we define.

So what will happen ... we will either have waves of proprietary features
which will be hard to interoperate even within single AS or that definition
of such things will take a spin outside of IETF via various forums,
consortium, foundations etc ... Do we really all here endorse such
direction ?

Have a great weekend,
Robert.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Apr 2017 08:47:30 +1200

Robert,

I think we're well off the main topic by now...
> they will disappear from Internet map. Pure and simple.

The trouble is, that doesn't work for second-order effects like dropping
unknown IPv6 extension headers, IPv4 options or ICMP packets. The network
learns to avoid those features, rather than avoiding certain paths.

> dictate on what each AS can or can not do in their own network.

We're not. We're simply saying PIPO (packet in = packet out), except for
any fields that are *explicitly* designed to change.

> Moreover it

Yes, transmitting IP datagrams from source to destination is indeed the lowest
common denominator that the Internet requires. And that sets a limit on the
external behaviour of every AS.

> vendors will manage to support or not support in what we define.

I'm not sure I take your point. There's always been a tension between ideal
notions of protocol design and the capability of actual hardware. For
example, your comment recently about how many bytes of the packet header
are within reach of the hardware protocol engine. Are you saying we should
design much larger headers regardless of that limitation?

> consortium, foundations etc ... Do we really all here endorse such

No. The third way: set a base line for the lowest common denominator and
then extend from there. That is what we're trying to do here.

Regards
    Brian

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 22 Apr 2017 23:18:52 +0200

Hi Brian,

> For example, your comment recently about how many bytes of the packet
> header are within reach of the hardware protocol engine. Are you saying
> we should design much larger headers regardless of that limitation?

We should be realistic. It is wise to enforce progressing the protocol
extension
only where there is implementation proving it. And that should be
sufficient criteria
of course assuming that the proposal is wise.

So while I am not advocating XXL headers ... but even if someone comes with
brilliant
idea to have XXL header, but also in the same time documents and proves
that any
transit node in the end to end path needs to only read first N bytes of
such header
to claim full support of it I see no problem to standardize it.

Just look at proposals which dynamically grow test packets at every node
and do
require very flexible data planes to add a lot of forwarding and control
information
on the fly at line rate during packet's forwarding depending on operator's
or such
packet src included set of required fields.

Example: https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-00

Would that be included in the base line you are referring to ?  Clearly
very useful
for my end to end Internet wide v6 transit ! Even more attractive if those
probes
would be SRv6 enabled Internet wide.

//R.