Subject: Fwd: 6MAN chair's comments on draft-ietf-conext-destopt

From: [email-masked]
Date: Wed, 14 Oct 2015 19:22:58 +0200

All,

Bob and I just sent the following note to the IESG about this document:
https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/?include_text=1

That is currently at the IESG.

Please comment.

Best regards,
Ole

> Begin forwarded message:
> 
> From: [email-masked]
> Date: 14 October 2015 at 19:15:58 GMT+2
> To: IESG <[email-masked]>
> Cc: 6man Chairs <[email-masked]>
> Subject: 6MAN chair's comments on draft-ietf-conext-destopt
> 
> Dear IESG,
> 
> We recently became aware of this document.  We were surprised
> that this was not sent to the 6man w.g. for review based on our
> charter:
> 
> "6man is the design authority for extensions and modifications to the
> IPv6 protocol. The working group may, at its discretion, review any
> document produced in another working group that extends or modifies the
> IPv6 protocol and, in consultation with the responsible ADs of both
> working groups, may recommend to the IESG that 6man working group
> consensus is needed before any of those documents can progress for
> publication."
> 
> We don’t see any mention of this draft on the 6man mailing list,
> and think this "experimental" usage of IPv6 options might have
> benefited from 6man review, especially guidance on the use of
> extension headers.
> 
> We have a number of concerns with this document.  These include:
> 
> The draft requires intermediate nodes to process the new
> destination option. IPv6 destination options are, of course,
> designed to be processed by destination nodes. The hop by hop
> option is specifically designed for intermediate nodes to
> process.
> 
> The Hop by hop option header is required to be the first
> extension header and is an easy check in the forwarding path of
> routers.  This proposal appears to be attempting to create a new
> hop by hop option type, instead of using the existing one based on
> the requirement that this ConEx destination option be the first
> destination option in the Destination header. If the authors want
> hop by hop behavior, they should have defined an hop by hop
> option, not try to create a new type of hop by hop capability.
> 
> We note that there are issues with the use of Hop by Hop options
> in the Internet, this is a topic that is discussed in 6man on a
> regular basis.  The issue that has been raised with hop by hop
> options, is that all routers MUST process them (lessened to a
> SHOULD in RFC7045) and be able to either discard or ignore
> depending on support for sub-options. There is a proposal in
> draft-baker-6man-hbh-header-handling that will make all HBH
> options optional (ignorable). This draft is about to go through
> an adoption call in 6man.
> 
> The document states:
> 
> "It might be possible to implement a proxy for a ConEx sender, as long
> as it is located where receiver feedback is always visible.  A ConEx
> proxy MUST NOT introduce a CDO header into a packet already carrying
> one and it MUST NOT alter the information in any existing CDO header.
> However, it can add a CDO header to any packets without one, taking
> care not to disrupt any integrity or authentication mechanisms as
> well as to not exceed the MTU."
> 
> The issue of intermediate nodes inserting extension headers have
> been discussed in 6man and it is well known that it creates
> serious issues. The most serious being that it breaks PMTUD. This
> document says that header injection is acceptable, and hand-waves
> around the MTU issues.
> 
> Overall we think inserting extension headers violates the IPv6
> architecture. Even for an experimental draft, we don’t find this
> acceptable.  We don’t need to conduct an experiment to find out
> that adding headers in the middle of the network creates PMTU
> problems.  If this draft is going to go forward it needs to
> describe how this would work.
> 
> While it doesn’t say anything specifically, it appears the intent
> that this header is intended for a specific realm, perhaps a
> ConEx domain.  At a minimum the draft needs to define where it is
> intended to be used, that is in a isolated ConEx domain, the
> whole Internet, or something else.
> 
> Best regards,
> Bob Hinden, Ole Troan,  6MAN chairs.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 14 Oct 2015 18:30:19 +0000

Hi Ole & Bob,
   Thanks a lot for your comments. First of all, I would like to 
apologize for this oversight. I was certain that I discussed this in 
6man in the draft's early days but going back through my mails, I 
realized it was another associated draft 
(draft-krishnan-6man-header-reserved-bits-00.txt) that was the other 
option for conex markings that was discussed.

https://www.ietf.org/mail-archive/web/ipv6/current/msg12944.html

Further comments inline.

>> option, not try to create a new type of hop by hop capability.

The idea was not to create a hop by hop capability. The mere presence of 
the hop-by-hop option header hurts packet processing on routers that are 
not conex-aware. Using a hop-by-hop option was not a viable idea. The 
idea was to run the experiment on consenting intermediate nodes while 
not causing issues on unmodified nodes.

>> document says that header injection is acceptable, and hand-waves

Agree. I do think this is a bad idea as well.

>> whole Internet, or something else.

Unfortunately, the goal is for this to be used across the Internet. The 
usage of the destination option was specifically to avoid processing 
issues on nodes that are not conex-aware. Since RFC6564 closed off other 
avenues of extensibility (extension headers and hop-by-hop options) I am 
not sure if there are any other possibilities.

Thanks
Suresh

---

From: Bob Hinden <[email-masked]>
Date: Wed, 14 Oct 2015 11:49:27 -0700

Suresh,

> not causing issues on unmodified nodes.

So it a new type of hop by hop option that only some intermediate nodes look at.

By the way, if this is an experiment, shouldn’t it be using one of the experimental destination option header code points, instead of asking IANA for a permanent assignment?

Bob

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

---

From: [email-masked]
Date: Wed, 14 Oct 2015 20:57:29 +0200

Suresh,

> https://www.ietf.org/mail-archive/web/ipv6/current/msg12944.html

Don't apologise, I would expect AD's/IESG to have dealt with this. Certainly not individual authors in this case in a different area.

> not causing issues on unmodified nodes.

I understand that.
Wouldn't you say that if the experiment turned out to be stunningly successful that you ended up creating what's essentially a new HBH header? And one that was more costly for intermediate nodes than HBH.
The HBH header does deal with the case of unmodified nodes on the path.
I do understand your concerns with HBH though, that's an active item under discussion in 6man.

draft-baker-6man-hbh-header-handling suggests a "rescue" for HBH by making all options in the HBH optional (i.e. intermediate nodes without enabled HBH features don't have to parse them).
(In practice, that's what I would expect most implementations to do anyway.)

I'm personally quite concerned about opening the door and creating the requirement in an IETF document that routers are required to parse deeper into the packet than the header with the one exception.
And if the argument is that the HBH is dropped or ignored because of performance reasons, why wouldn't the exact same argument apply to this new usage of the DestOpt header?

> not sure if there are any other possibilities.

Do you know the conex-aware nodes a priori? You could of course encapsulate or source route.

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Oct 2015 11:47:48 +1300

> So it a new type of hop by hop option that only some intermediate nodes look at.

Which is the case for all HbH options in reality (which is why RFC7045
updates RFC2460).

> By the way, if this is an experiment, shouldn’t it be using one of the experimental destination option header code points, instead of asking IANA for a permanent assignment?

There are also HbH experimental code points (RFC4727), and they are intended for experiments.
So indeed, there's no need to trouble IANA.

   Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 15 Oct 2015 02:22:17 +0000

Hi Bob/Brian,

> So indeed, there's no need to trouble IANA.

Sounds good. The option type 0x1E looks right for this. Will rework the 
option and IANA text for this.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 15 Oct 2015 03:22:26 +0000

Hi Ole,

> I do understand your concerns with HBH though, that's an active item under discussion in 6man.

Great.

> (In practice, that's what I would expect most implementations to do anyway.)

That draft would really help things out. If the experiment is a success, 
then it makes a lot of sense to rewrite with a new hop by hop option if 
the intermediate nodes start to get updated with this new behavior. Even 
then, unupdated intermediate nodes (that either drop packets with the 
HBH header or punt them to the slow path) would still cause issues for 
conex marked packets.

> And if the argument is that the HBH is dropped or ignored because of performance reasons, why wouldn't the exact same argument apply to this new usage of the DestOpt header?

The concern is mainly about current intermediate nodes that 
indiscriminately penalize/drop packets just based on the presence of the 
HBH option header. If the nodes stay unupdated, they will not process 
the destopt header and will leave the packets alone. If they do get 
updated with awareness of the new option, it is most likely because they 
would like to support it, right?

> Do you know the conex-aware nodes a priori? You could of course encapsulate or source route.

No. They aren't. Like you say, encapsulation would have made a lot of 
sense if the list of conex-aware nodes on the path were known up front.

Thanks
Suresh

---

From: Mark Smith <[email-masked]>
Date: Thu, 15 Oct 2015 16:16:02 +1100

> On 10/14/2015 02:57 PM, [email-masked] wrote:

<snip>

> sense if the list of conex-aware nodes on the path were known up front.

Just a random and possibly throw away idea (and baring in mind that I
don't know much about conex)

How about encapsulating and using a well-known anycast address for the
conex-aware nodes as the encapsulation destination address?

Conex unaware routers would just forward the packet towards the
closest router announcing the anycast address.

Conex aware routers would match on that destination anycast address on
ingress and pass the packet to the conex processing functions. When
the router is done with its conex processing, it would then forward to
the next closest router announcing the well known conex anycast
address, ignoring its own local 'ownership' of that anycast address.
I'd guess the source address of the encapsulation would be set to one
of the local conex aware router's non-anycast address, so that at any
time if you're troubleshooting for example, you know the last conex
aware router that processed the packet, and ICMP PTB messages would go
back to the router that performed the conex processing that triggered
PMTUD.

Regards,
Mark.

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 16 Oct 2015 03:29:01 +0000

Hi Mark,

> conex-aware nodes as the encapsulation destination address?

That is an interesting idea, but there is one issue with it. There are *zero* 
or more conex-aware routers on the path between the sender and the receiver 
and the sender does not know up front if there are any conex aware routers.

Thanks
Suresh