| Message ID | 1577400698-4836-1-git-send-email-tom@herbertland.com |
|---|---|
| Headers | show |
| Series | ipv6: Extension header infrastructure | expand |
From: Tom Herbert <tom@herbertland.com> Date: Thu, 26 Dec 2019 14:51:29 -0800 > The fundamental rationale here is to make various TLVs, in particular > Hop-by-Hop and Destination options, usable, robust, scalable, and > extensible to support emerging functionality. So, patch #1 is fine and it seems to structure the code to more easily enable support for: https://tools.ietf.org/html/draft-ietf-6man-icmp-limits-07 (I'll note in passing how frustrating it is that, based upon your handling of things in that past, I know that I have to go out and explicitly look for draft RFCs containing your name in order to figure out what your overall long term agenda actually is. You should be stating these kinds of things in your commit messages) But as for the rest of the patch series, what are these "emerging functionalities" you are talking about? I've heard some noises about people wanting to do some kind of "kerberos for packets". Or even just plain putting app + user ID information into options. Is that where this is going? I have no idea, because you won't say. And honestly, this stuff sounds so easy to misuse by governments and other entities. It could also be used to allow ISPs to limit users in very undesirable and unfair ways. And honestly, surveilance and limiting are the most likely uses for such a facility. I can't see it legitimately being promoted as a "security" feature, really. I think the whole TX socket option can wait. And because of that the whole consolidation and cleanup of the option handling code is untenable, because without a use case all it does is make -stable backports insanely painful.
On Thu, Jan 2, 2020 at 1:41 PM David Miller <davem@davemloft.net> wrote: > > From: Tom Herbert <tom@herbertland.com> > Date: Thu, 26 Dec 2019 14:51:29 -0800 > > > The fundamental rationale here is to make various TLVs, in particular > > Hop-by-Hop and Destination options, usable, robust, scalable, and > > extensible to support emerging functionality. > > So, patch #1 is fine and it seems to structure the code to more easily > enable support for: > > https://tools.ietf.org/html/draft-ietf-6man-icmp-limits-07 > > (I'll note in passing how frustrating it is that, based upon your > handling of things in that past, I know that I have to go out and > explicitly look for draft RFCs containing your name in order to figure > out what your overall long term agenda actually is. You should be > stating these kinds of things in your commit messages) > > But as for the rest of the patch series, what are these "emerging > functionalities" you are talking about? > > I've heard some noises about people wanting to do some kind of "kerberos > for packets". Or even just plain putting app + user ID information into > options. > > Is that where this is going? I have no idea, because you won't say. > Yes, there is some of that. Here are some of the use cases for HBH options: PMTU option: draft-ietf-6man-mtu-option-01. There is a P4 implementation as well as Linux PoC for this that was demonstated @IETF103 hackathon. IOAM option: https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-00. There is also P4 implementation and Linux router support demonstrated at IETF104 hackathon. INT is a related technology that would also use this. FAST option: https://datatracker.ietf.org/doc/draft-herbert-fast/. I have PoC for this. There are some other protocol proposals in the is are (I know Huawei has something to describe the QoS that should be applied). There are others including the whole space especially as a real solution for host to networking signaling gets fleshed out. There's also the whole world of segment routing options and where that's going. > And honestly, this stuff sounds so easy to misuse by governments and > other entities. It could also be used to allow ISPs to limit users > in very undesirable and unfair ways. And honestly, surveilance and > limiting are the most likely uses for such a facility. I can't see > it legitimately being promoted as a "security" feature, really. > Yes, but the problem isn't unique to IPv6 options nor would abuse be prevented by not implementing them in Linux. Router vendors will happily provide the necessary support to allow abuse :-) AH is the prescribed way to prevent this sort of abuse (aside from encrypting everything that isn't necessary to route packets, but that's another story). AH is fully supported by Linux, good luck finding a router vendor that cares about it :-) > I think the whole TX socket option can wait. > > And because of that the whole consolidation and cleanup of the option > handling code is untenable, because without a use case all it does is > make -stable backports insanely painful. The problem with "wait and see" approach is that Linux is not the only game in town. There are other players that are pursuing this area (Cisco and Huawei in particular). They are able to implement protocols more to appease their short term marketing requirements with little regard for what is best for the community. This is why Linux is so critical to networking, it is the only open forum where real scrutiny is applied to how protocols are implemented. If the alternatives are given free to lead then it's very likely we'll end up being stuck with what they do and probably have to follow their lead regardless of how miserable they make the protocols. We've already seen this in segment routing, their attempts to kill IP fragmentation, and all the other examples of protocol ossification that unnecessarily restrict what hosts are allowed to send in the network and hence reduce the utility and security we are able to offer the user. The other data point I will offer is that the current Linux implementation of IPv6 destination and hop-by-hop options in the kernel is next to useless. Nobody is using the ones that have been implemented, and adding support for a new is a major pain-- the ability for modules to register support for an option seems like an obvious feature to me. Similarly, the restriction that only admin can set options is overly restrictive-- allowing to non-privileged users to send options under tightly controlled constraints set by the admin also seems reasonable to me. Tom
Tom, Happy new year!! I believe that these patches cost you great effort. However, we would like to see the 6-10 subsequent patch set to be really able to understand where are you going with these ones. At some point you mentioned that router vendors make protocol in miserable way. Do you believe the right way is that every individual defines the protocol the way he wants in a single authored IETF draft ? Regarding 10) Support IPv4 extension headers. I see that your drafts describing the idea are expired [1][2]. Do you plan to add to the kernel the implementation of expired contents ? or did you abandoned these drafts and described the idea somewhere else that I’m not aware of ? [1] https://tools.ietf.org/html/draft-herbert-ipv4-udpencap-eh-01 [2] https://tools.ietf.org/html/draft-herbert-ipv4-eh-01 Ahmed On Thu, 2 Jan 2020 16:42:24 -0800 Tom Herbert <tom@herbertland.com> wrote: > On Thu, Jan 2, 2020 at 1:41 PM David Miller <davem@davemloft.net> wrote: > > > > From: Tom Herbert <tom@herbertland.com> > > Date: Thu, 26 Dec 2019 14:51:29 -0800 > > > > > The fundamental rationale here is to make various TLVs, in particular > > > Hop-by-Hop and Destination options, usable, robust, scalable, and > > > extensible to support emerging functionality. > > > > So, patch #1 is fine and it seems to structure the code to more easily > > enable support for: > > > > https://tools.ietf.org/html/draft-ietf-6man-icmp-limits-07 > > > > (I'll note in passing how frustrating it is that, based upon your > > handling of things in that past, I know that I have to go out and > > explicitly look for draft RFCs containing your name in order to figure > > out what your overall long term agenda actually is. You should be > > stating these kinds of things in your commit messages) > > > > But as for the rest of the patch series, what are these "emerging > > functionalities" you are talking about? > > > > I've heard some noises about people wanting to do some kind of "kerberos > > for packets". Or even just plain putting app + user ID information into > > options. > > > > Is that where this is going? I have no idea, because you won't say. > > > Yes, there is some of that. Here are some of the use cases for HBH options: > > PMTU option: draft-ietf-6man-mtu-option-01. There is a P4 > implementation as well as Linux PoC for this that was demonstated > @IETF103 hackathon. > IOAM option: https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-00. > There is also P4 implementation and Linux router support demonstrated > at IETF104 hackathon. INT is a related technology that would also use > this. > FAST option: https://datatracker.ietf.org/doc/draft-herbert-fast/. I > have PoC for this. There are some other protocol proposals in the is > are (I know Huawei has something to describe the QoS that should be > applied). > > There are others including the whole space especially as a real > solution for host to networking signaling gets fleshed out. There's > also the whole world of segment routing options and where that's > going. > > > And honestly, this stuff sounds so easy to misuse by governments and > > other entities. It could also be used to allow ISPs to limit users > > in very undesirable and unfair ways. And honestly, surveilance and > > limiting are the most likely uses for such a facility. I can't see > > it legitimately being promoted as a "security" feature, really. > > > Yes, but the problem isn't unique to IPv6 options nor would abuse be > prevented by not implementing them in Linux. Router vendors will > happily provide the necessary support to allow abuse :-) AH is the > prescribed way to prevent this sort of abuse (aside from encrypting > everything that isn't necessary to route packets, but that's another > story). AH is fully supported by Linux, good luck finding a router > vendor that cares about it :-) > > > I think the whole TX socket option can wait. > > > > And because of that the whole consolidation and cleanup of the option > > handling code is untenable, because without a use case all it does is > > make -stable backports insanely painful. > > The problem with "wait and see" approach is that Linux is not the only > game in town. There are other players that are pursuing this area > (Cisco and Huawei in particular). They are able to implement protocols > more to appease their short term marketing requirements with little > regard for what is best for the community. This is why Linux is so > critical to networking, it is the only open forum where real scrutiny > is applied to how protocols are implemented. If the alternatives are > given free to lead then it's very likely we'll end up being stuck with > what they do and probably have to follow their lead regardless of how > miserable they make the protocols. We've already seen this in segment > routing, their attempts to kill IP fragmentation, and all the other > examples of protocol ossification that unnecessarily restrict what > hosts are allowed to send in the network and hence reduce the utility > and security we are able to offer the user. > > The other data point I will offer is that the current Linux > implementation of IPv6 destination and hop-by-hop options in the > kernel is next to useless. Nobody is using the ones that have been > implemented, and adding support for a new is a major pain-- the > ability for modules to register support for an option seems like an > obvious feature to me. Similarly, the restriction that only admin can > set options is overly restrictive-- allowing to non-privileged users > to send options under tightly controlled constraints set by the admin > also seems reasonable to me. > > Tom
On Thu, Jan 2, 2020 at 11:11 PM kernel Dev <ahabdels.dev@gmail.com> wrote: > > Tom, > Happy new year!! > Happy new year to you! > I believe that these patches cost you great effort. However, we would like to see the 6-10 subsequent patch set to be really able to understand where are you going with these ones. > I can post those as RFC. > At some point you mentioned that router vendors make protocol in miserable way. Do you believe the right way is that every individual defines the protocol the way he wants in a single authored IETF draft ? > No, that defies the whole purpose of standard and interoperable protocols. The problem we are finding with IETF is that it has no means to enforce conformance of the protocols it standardizes. Router vendors openly exploit this, for instance at the last IETF the Cisco engineer presenting extension header insertion (a clear violation of RFC8200) plainly said upfront that regardless of any feedback or input they will continue developing and deploying it the way they want. Note this is not an indictment of all router vendors and their engineers, there are many that are trying to do the right thing-- but it's really pretty easy for a few engineers at large vendors to cheat the system in different ways. The only pushback IETF can do is to not standardize these non-conformant quasi-proprietary protocols. The real way to combat this provide open implementation that demonstrates the correct use of the protocols and show that's more extensible and secure than these "hacks". > Regarding 10) Support IPv4 extension headers. > I see that your drafts describing the idea are expired [1][2]. > Do you plan to add to the kernel the implementation of expired contents ? or did you abandoned these drafts and described the idea somewhere else that I’m not aware of ? > > [1] https://tools.ietf.org/html/draft-herbert-ipv4-udpencap-eh-01 > [2] https://tools.ietf.org/html/draft-herbert-ipv4-eh-01 > [1] is obsoleted by [2]. I will update [2] shortly. I may also propose an IETF hackathon project to bring up IOAM over IPv4 if you are interested. Tom > Ahmed > > > On Thu, 2 Jan 2020 16:42:24 -0800 > Tom Herbert <tom@herbertland.com> wrote: > > > On Thu, Jan 2, 2020 at 1:41 PM David Miller <davem@davemloft.net> wrote: > > > > > > From: Tom Herbert <tom@herbertland.com> > > > Date: Thu, 26 Dec 2019 14:51:29 -0800 > > > > > > > The fundamental rationale here is to make various TLVs, in particular > > > > Hop-by-Hop and Destination options, usable, robust, scalable, and > > > > extensible to support emerging functionality. > > > > > > So, patch #1 is fine and it seems to structure the code to more easily > > > enable support for: > > > > > > https://tools.ietf.org/html/draft-ietf-6man-icmp-limits-07 > > > > > > (I'll note in passing how frustrating it is that, based upon your > > > handling of things in that past, I know that I have to go out and > > > explicitly look for draft RFCs containing your name in order to figure > > > out what your overall long term agenda actually is. You should be > > > stating these kinds of things in your commit messages) > > > > > > But as for the rest of the patch series, what are these "emerging > > > functionalities" you are talking about? > > > > > > I've heard some noises about people wanting to do some kind of "kerberos > > > for packets". Or even just plain putting app + user ID information into > > > options. > > > > > > Is that where this is going? I have no idea, because you won't say. > > > > > Yes, there is some of that. Here are some of the use cases for HBH options: > > > > PMTU option: draft-ietf-6man-mtu-option-01. There is a P4 > > implementation as well as Linux PoC for this that was demonstated > > @IETF103 hackathon. > > IOAM option: https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-00. > > There is also P4 implementation and Linux router support demonstrated > > at IETF104 hackathon. INT is a related technology that would also use > > this. > > FAST option: https://datatracker.ietf.org/doc/draft-herbert-fast/. I > > have PoC for this. There are some other protocol proposals in the is > > are (I know Huawei has something to describe the QoS that should be > > applied). > > > > There are others including the whole space especially as a real > > solution for host to networking signaling gets fleshed out. There's > > also the whole world of segment routing options and where that's > > going. > > > > > And honestly, this stuff sounds so easy to misuse by governments and > > > other entities. It could also be used to allow ISPs to limit users > > > in very undesirable and unfair ways. And honestly, surveilance and > > > limiting are the most likely uses for such a facility. I can't see > > > it legitimately being promoted as a "security" feature, really. > > > > > Yes, but the problem isn't unique to IPv6 options nor would abuse be > > prevented by not implementing them in Linux. Router vendors will > > happily provide the necessary support to allow abuse :-) AH is the > > prescribed way to prevent this sort of abuse (aside from encrypting > > everything that isn't necessary to route packets, but that's another > > story). AH is fully supported by Linux, good luck finding a router > > vendor that cares about it :-) > > > > > I think the whole TX socket option can wait. > > > > > > And because of that the whole consolidation and cleanup of the option > > > handling code is untenable, because without a use case all it does is > > > make -stable backports insanely painful. > > > > The problem with "wait and see" approach is that Linux is not the only > > game in town. There are other players that are pursuing this area > > (Cisco and Huawei in particular). They are able to implement protocols > > more to appease their short term marketing requirements with little > > regard for what is best for the community. This is why Linux is so > > critical to networking, it is the only open forum where real scrutiny > > is applied to how protocols are implemented. If the alternatives are > > given free to lead then it's very likely we'll end up being stuck with > > what they do and probably have to follow their lead regardless of how > > miserable they make the protocols. We've already seen this in segment > > routing, their attempts to kill IP fragmentation, and all the other > > examples of protocol ossification that unnecessarily restrict what > > hosts are allowed to send in the network and hence reduce the utility > > and security we are able to offer the user. > > > > The other data point I will offer is that the current Linux > > implementation of IPv6 destination and hop-by-hop options in the > > kernel is next to useless. Nobody is using the ones that have been > > implemented, and adding support for a new is a major pain-- the > > ability for modules to register support for an option seems like an > > obvious feature to me. Similarly, the restriction that only admin can > > set options is overly restrictive-- allowing to non-privileged users > > to send options under tightly controlled constraints set by the admin > > also seems reasonable to me. > > > > Tom > > > -- > kernel Dev <ahabdels.dev@gmail.com>
From: Tom Herbert <tom@herbertland.com> Date: Fri, 3 Jan 2020 09:35:08 -0800 > The real way to combat this provide open implementation that > demonstrates the correct use of the protocols and show that's more > extensible and secure than these "hacks". Keep dreaming, this won't stop Cisco from doing whatever it wants to do.
On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@davemloft.net> wrote: > > From: Tom Herbert <tom@herbertland.com> > Date: Fri, 3 Jan 2020 09:35:08 -0800 > > > The real way to combat this provide open implementation that > > demonstrates the correct use of the protocols and show that's more > > extensible and secure than these "hacks". > > Keep dreaming, this won't stop Cisco from doing whatever it wants to do. See QUIC. See TLS. See TCP fast open. See transport layer encryption. These are prime examples where we've steered the Internet from host protocols and implementation to successfully obsolete or at least work around protocol ossification that was perpetuated by router vendors. Cisco is not the Internet!
From: Tom Herbert <tom@herbertland.com> Date: Fri, 3 Jan 2020 14:31:58 -0800 > On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@davemloft.net> wrote: >> >> From: Tom Herbert <tom@herbertland.com> >> Date: Fri, 3 Jan 2020 09:35:08 -0800 >> >> > The real way to combat this provide open implementation that >> > demonstrates the correct use of the protocols and show that's more >> > extensible and secure than these "hacks". >> >> Keep dreaming, this won't stop Cisco from doing whatever it wants to do. > > See QUIC. See TLS. See TCP fast open. See transport layer encryption. > These are prime examples where we've steered the Internet from host > protocols and implementation to successfully obsolete or at least work > around protocol ossification that was perpetuated by router vendors. > Cisco is not the Internet! Seriously, I wish you luck stopping the SRv6 header insertion stuff. It's simply not happening, no matter what transport layer technology you throw at the situation.
On Fri, Jan 3, 2020 at 2:57 PM David Miller <davem@davemloft.net> wrote: > > From: Tom Herbert <tom@herbertland.com> > Date: Fri, 3 Jan 2020 14:31:58 -0800 > > > On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@davemloft.net> wrote: > >> > >> From: Tom Herbert <tom@herbertland.com> > >> Date: Fri, 3 Jan 2020 09:35:08 -0800 > >> > >> > The real way to combat this provide open implementation that > >> > demonstrates the correct use of the protocols and show that's more > >> > extensible and secure than these "hacks". > >> > >> Keep dreaming, this won't stop Cisco from doing whatever it wants to do. > > > > See QUIC. See TLS. See TCP fast open. See transport layer encryption. > > These are prime examples where we've steered the Internet from host > > protocols and implementation to successfully obsolete or at least work > > around protocol ossification that was perpetuated by router vendors. > > Cisco is not the Internet! > > Seriously, I wish you luck stopping the SRv6 header insertion stuff. > Dave, I agree we can't stop it, but maybe we can steer it to be at least palatable. There are valid use cases for extension header insertion. Ironically, SRv6 header insertion isn't one of them; the proponents have failed to offer even a single reason why the alternative of IPv6 encapsulation isn't sufficient (believe me, we've asked _many_ times for some justification and only get hand waving!). There are, however, some interesting uses cases like in IOAM where the operator would like to annotate packets as they traverse the network. Encapsulation is insufficient if they don't know what the end point would be or they don't want the annotation to change the path the packets take (versus those that aren't annotated). The salient problem with extension header insertion is lost of attribution. It is fundamental in the IP protocol that the contents of a packet are attributed to the source host identified by the source address. If some intermediate node inserts an extension header that subsequently breaks the packet downstream then there is no obvious way to debug this. If an ICMP message is sent because of the receiving data, then receiving host can't do much with it; it's not the source of the data in error and nothing in the packet tells who the culprit is. The Cisco guys have at least conceded one point on SRv6 insertion due to pushback on this, their latest draft only does SRv6 insertion on packets that have already been encapsulated in IPIP on ingress into the domain. This is intended to at least restrict the modified packets to a controlled domain (I'm note sure if any implementations enforce this though). My proposal is to require an "attribution" HBH option that would clearly identify inserted data put in a packet by middleboxes (draft-herbert-6man-eh-attrib-00). This is a tradeoff to allow extension header insertion, but require protocol to give attribution and make it at least somewhat robust and manageable. Tom
On Fri, 3 Jan 2020 at 15:49, Tom Herbert <tom@herbertland.com> wrote: > > On Fri, Jan 3, 2020 at 2:57 PM David Miller <davem@davemloft.net> wrote: > > > > From: Tom Herbert <tom@herbertland.com> > > Date: Fri, 3 Jan 2020 14:31:58 -0800 > > > > > On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@davemloft.net> wrote: > > >> > > >> From: Tom Herbert <tom@herbertland.com> > > >> Date: Fri, 3 Jan 2020 09:35:08 -0800 > > >> > > >> > The real way to combat this provide open implementation that > > >> > demonstrates the correct use of the protocols and show that's more > > >> > extensible and secure than these "hacks". > > >> > > >> Keep dreaming, this won't stop Cisco from doing whatever it wants to do. > > > > > > See QUIC. See TLS. See TCP fast open. See transport layer encryption. > > > These are prime examples where we've steered the Internet from host > > > protocols and implementation to successfully obsolete or at least work > > > around protocol ossification that was perpetuated by router vendors. > > > Cisco is not the Internet! > > > > Seriously, I wish you luck stopping the SRv6 header insertion stuff. > > > Dave, > > I agree we can't stop it, but maybe we can steer it to be at least > palatable. There are valid use cases for extension header insertion. > Ironically, SRv6 header insertion isn't one of them; the proponents > have failed to offer even a single reason why the alternative of IPv6 > encapsulation isn't sufficient (believe me, we've asked _many_ times > for some justification and only get hand waving!). There are, however, > some interesting uses cases like in IOAM where the operator would like > to annotate packets as they traverse the network. Encapsulation is > insufficient if they don't know what the end point would be or they > don't want the annotation to change the path the packets take (versus > those that aren't annotated). > > The salient problem with extension header insertion is lost of And the problems that can be introduced by changing the effective path MTU... > attribution. It is fundamental in the IP protocol that the contents of > a packet are attributed to the source host identified by the source > address. If some intermediate node inserts an extension header that > subsequently breaks the packet downstream then there is no obvious way > to debug this. If an ICMP message is sent because of the receiving > data, then receiving host can't do much with it; it's not the source > of the data in error and nothing in the packet tells who the culprit > is. The Cisco guys have at least conceded one point on SRv6 insertion > due to pushback on this, their latest draft only does SRv6 insertion > on packets that have already been encapsulated in IPIP on ingress into > the domain. This is intended to at least restrict the modified packets > to a controlled domain (I'm note sure if any implementations enforce > this though). My proposal is to require an "attribution" HBH option > that would clearly identify inserted data put in a packet by > middleboxes (draft-herbert-6man-eh-attrib-00). This is a tradeoff to > allow extension header insertion, but require protocol to give > attribution and make it at least somewhat robust and manageable. > > Tom FWIW the SRv6 header insertion stuff is still under discussion in spring wg (last I knew). I proposed one option that could be used to avoid insertion (allow for extra scratch space https://mailarchive.ietf.org/arch/msg/spring/UhThRTNxbHWNiMGgRi3U0SqLaDA), but nothing has been conclusively resolved last I checked. As everyone probably knows, the draft-ietf-* documents are working-group-adopted documents (though final publication is never guaranteed). My current reading of 6man tea leaves is that neither "ICMP limits" and "MTU option" docs were terribly contentious. Whether code reorg is important for implementing these I'm not competent enough to say.
On Fri, Jan 3, 2020 at 3:53 PM Erik Kline <ek@loon.com> wrote: > > On Fri, 3 Jan 2020 at 15:49, Tom Herbert <tom@herbertland.com> wrote: > > > > On Fri, Jan 3, 2020 at 2:57 PM David Miller <davem@davemloft.net> wrote: > > > > > > From: Tom Herbert <tom@herbertland.com> > > > Date: Fri, 3 Jan 2020 14:31:58 -0800 > > > > > > > On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@davemloft.net> wrote: > > > >> > > > >> From: Tom Herbert <tom@herbertland.com> > > > >> Date: Fri, 3 Jan 2020 09:35:08 -0800 > > > >> > > > >> > The real way to combat this provide open implementation that > > > >> > demonstrates the correct use of the protocols and show that's more > > > >> > extensible and secure than these "hacks". > > > >> > > > >> Keep dreaming, this won't stop Cisco from doing whatever it wants to do. > > > > > > > > See QUIC. See TLS. See TCP fast open. See transport layer encryption. > > > > These are prime examples where we've steered the Internet from host > > > > protocols and implementation to successfully obsolete or at least work > > > > around protocol ossification that was perpetuated by router vendors. > > > > Cisco is not the Internet! > > > > > > Seriously, I wish you luck stopping the SRv6 header insertion stuff. > > > > > Dave, > > > > I agree we can't stop it, but maybe we can steer it to be at least > > palatable. There are valid use cases for extension header insertion. > > Ironically, SRv6 header insertion isn't one of them; the proponents > > have failed to offer even a single reason why the alternative of IPv6 > > encapsulation isn't sufficient (believe me, we've asked _many_ times > > for some justification and only get hand waving!). There are, however, > > some interesting uses cases like in IOAM where the operator would like > > to annotate packets as they traverse the network. Encapsulation is > > insufficient if they don't know what the end point would be or they > > don't want the annotation to change the path the packets take (versus > > those that aren't annotated). > > > > The salient problem with extension header insertion is lost of > > And the problems that can be introduced by changing the effective path MTU... > Eric, Yep, increasing the size of packet in transit potentially wreaks havoc on PMTU discovery, however I personally think that the issue might be overblown. We already have the same problem when tunneling is done in the network since most tunneling implementations and deployments just assume the operator has set large enough MTUs. As long as all the overhead inserted into the packet doesn't reduce the end host PMTU below 1280, PMTU discovery and probably even PTB for a packet with inserted headers still has right effect. > > attribution. It is fundamental in the IP protocol that the contents of > > a packet are attributed to the source host identified by the source > > address. If some intermediate node inserts an extension header that > > subsequently breaks the packet downstream then there is no obvious way > > to debug this. If an ICMP message is sent because of the receiving > > data, then receiving host can't do much with it; it's not the source > > of the data in error and nothing in the packet tells who the culprit > > is. The Cisco guys have at least conceded one point on SRv6 insertion > > due to pushback on this, their latest draft only does SRv6 insertion > > on packets that have already been encapsulated in IPIP on ingress into > > the domain. This is intended to at least restrict the modified packets > > to a controlled domain (I'm note sure if any implementations enforce > > this though). My proposal is to require an "attribution" HBH option > > that would clearly identify inserted data put in a packet by > > middleboxes (draft-herbert-6man-eh-attrib-00). This is a tradeoff to > > allow extension header insertion, but require protocol to give > > attribution and make it at least somewhat robust and manageable. > > > > Tom > > FWIW the SRv6 header insertion stuff is still under discussion in > spring wg (last I knew). I proposed one option that could be used to It's also under discussion in 6man. > avoid insertion (allow for extra scratch space > https://mailarchive.ietf.org/arch/msg/spring/UhThRTNxbHWNiMGgRi3U0SqLaDA), > but nothing has been conclusively resolved last I checked. > I saw your proposal. It's a good idea from POV to be conformant with RFC8200 and avoid the PMTU problems, but the header insertion proponents aren't going to like it at all. First, it means that the source is in control of the insertion policy and host is required to change-- no way they'll buy into that ;-). Secondly, if the scratch space isn't used they'll undoubtedly claim that is unnecessary overhead. Tom > As everyone probably knows, the draft-ietf-* documents are > working-group-adopted documents (though final publication is never > guaranteed). My current reading of 6man tea leaves is that neither > "ICMP limits" and "MTU option" docs were terribly contentious. > Whether code reorg is important for implementing these I'm not > competent enough to say.
Tom, I will not go into whether Tom or router vendors is right from IETF perspective as here is not the place to discuss. But it seems to me that the motivation behind these patches is just to pushback on the current IETF proposals. The patches timeline is completely aligned with when IETF threads get into tough discussions (May 2019, August 2019, and now). I’m not the one to decide, but IMO people should not add stuff to the kernel just to enforce their opinions on other mailers. On Fri, 3 Jan 2020 16:37:33 -0800 Tom Herbert <tom@herbertland.com> wrote: > On Fri, Jan 3, 2020 at 3:53 PM Erik Kline <ek@loon.com> wrote: > > > > On Fri, 3 Jan 2020 at 15:49, Tom Herbert <tom@herbertland.com> wrote: > > > > > > On Fri, Jan 3, 2020 at 2:57 PM David Miller <davem@davemloft.net> wrote: > > > > > > > > From: Tom Herbert <tom@herbertland.com> > > > > Date: Fri, 3 Jan 2020 14:31:58 -0800 > > > > > > > > > On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@davemloft.net> wrote: > > > > >> > > > > >> From: Tom Herbert <tom@herbertland.com> > > > > >> Date: Fri, 3 Jan 2020 09:35:08 -0800 > > > > >> > > > > >> > The real way to combat this provide open implementation that > > > > >> > demonstrates the correct use of the protocols and show that's more > > > > >> > extensible and secure than these "hacks". > > > > >> > > > > >> Keep dreaming, this won't stop Cisco from doing whatever it wants to do. > > > > > > > > > > See QUIC. See TLS. See TCP fast open. See transport layer encryption. > > > > > These are prime examples where we've steered the Internet from host > > > > > protocols and implementation to successfully obsolete or at least work > > > > > around protocol ossification that was perpetuated by router vendors. > > > > > Cisco is not the Internet! > > > > > > > > Seriously, I wish you luck stopping the SRv6 header insertion stuff. > > > > > > > Dave, > > > > > > I agree we can't stop it, but maybe we can steer it to be at least > > > palatable. There are valid use cases for extension header insertion. > > > Ironically, SRv6 header insertion isn't one of them; the proponents > > > have failed to offer even a single reason why the alternative of IPv6 > > > encapsulation isn't sufficient (believe me, we've asked _many_ times > > > for some justification and only get hand waving!). There are, however, > > > some interesting uses cases like in IOAM where the operator would like > > > to annotate packets as they traverse the network. Encapsulation is > > > insufficient if they don't know what the end point would be or they > > > don't want the annotation to change the path the packets take (versus > > > those that aren't annotated). > > > > > > The salient problem with extension header insertion is lost of > > > > And the problems that can be introduced by changing the effective path MTU... > > > Eric, > > Yep, increasing the size of packet in transit potentially wreaks havoc > on PMTU discovery, however I personally think that the issue might be > overblown. We already have the same problem when tunneling is done in > the network since most tunneling implementations and deployments just > assume the operator has set large enough MTUs. As long as all the > overhead inserted into the packet doesn't reduce the end host PMTU > below 1280, PMTU discovery and probably even PTB for a packet with > inserted headers still has right effect. > > > > attribution. It is fundamental in the IP protocol that the contents of > > > a packet are attributed to the source host identified by the source > > > address. If some intermediate node inserts an extension header that > > > subsequently breaks the packet downstream then there is no obvious way > > > to debug this. If an ICMP message is sent because of the receiving > > > data, then receiving host can't do much with it; it's not the source > > > of the data in error and nothing in the packet tells who the culprit > > > is. The Cisco guys have at least conceded one point on SRv6 insertion > > > due to pushback on this, their latest draft only does SRv6 insertion > > > on packets that have already been encapsulated in IPIP on ingress into > > > the domain. This is intended to at least restrict the modified packets > > > to a controlled domain (I'm note sure if any implementations enforce > > > this though). My proposal is to require an "attribution" HBH option > > > that would clearly identify inserted data put in a packet by > > > middleboxes (draft-herbert-6man-eh-attrib-00). This is a tradeoff to > > > allow extension header insertion, but require protocol to give > > > attribution and make it at least somewhat robust and manageable. > > > > > > Tom > > > > FWIW the SRv6 header insertion stuff is still under discussion in > > spring wg (last I knew). I proposed one option that could be used to > > It's also under discussion in 6man. > > > avoid insertion (allow for extra scratch space > > https://mailarchive.ietf.org/arch/msg/spring/UhThRTNxbHWNiMGgRi3U0SqLaDA), > > but nothing has been conclusively resolved last I checked. > > > > I saw your proposal. It's a good idea from POV to be conformant with > RFC8200 and avoid the PMTU problems, but the header insertion > proponents aren't going to like it at all. First, it means that the > source is in control of the insertion policy and host is required to > change-- no way they'll buy into that ;-). Secondly, if the scratch > space isn't used they'll undoubtedly claim that is unnecessary > overhead. > > Tom > > > As everyone probably knows, the draft-ietf-* documents are > > working-group-adopted documents (though final publication is never > > guaranteed). My current reading of 6man tea leaves is that neither > > "ICMP limits" and "MTU option" docs were terribly contentious. > > Whether code reorg is important for implementing these I'm not > > competent enough to say. --
On Sat, Jan 4, 2020 at 12:05 AM kernel Dev <ahabdels.dev@gmail.com> wrote: > > Tom, > > I will not go into whether Tom or router vendors is right from IETF perspective as here is not the place to discuss. > > But it seems to me that the motivation behind these patches is just to pushback on the current IETF proposals. > Sorry, but that is completely untrue. The patches are a general improvement. The ability to allow modules to register handlers for options code points has nothing to do with "pushback on the current IETF protocols". This sort of registration is a mechanism used all over the place. Similarly, allowing non-priveledged users to send options is not for any specific protocol-- it is a *general* mechanism. > The patches timeline is completely aligned with when IETF threads get into tough discussions (May 2019, August 2019, and now). > Yes, discussion about new protocols in IETF tends to correlate with development and implementation of the protocols. That shouldn't surprise anyone. SRv6 for instance was highly controversial in IETF and yet the patches went in. > I’m not the one to decide, but IMO people should not add stuff to the kernel just to enforce their opinions on other mailers. I take exception with your insinuation. Seeing as how you might be new to Linux kernel development I will ignore it. But, in the future, I strongly suggest you be careful about accusing people about their motivations based solely on one interaction. Tom > > > On Fri, 3 Jan 2020 16:37:33 -0800 > Tom Herbert <tom@herbertland.com> wrote: > > > On Fri, Jan 3, 2020 at 3:53 PM Erik Kline <ek@loon.com> wrote: > > > > > > On Fri, 3 Jan 2020 at 15:49, Tom Herbert <tom@herbertland.com> wrote: > > > > > > > > On Fri, Jan 3, 2020 at 2:57 PM David Miller <davem@davemloft.net> wrote: > > > > > > > > > > From: Tom Herbert <tom@herbertland.com> > > > > > Date: Fri, 3 Jan 2020 14:31:58 -0800 > > > > > > > > > > > On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@davemloft.net> wrote: > > > > > >> > > > > > >> From: Tom Herbert <tom@herbertland.com> > > > > > >> Date: Fri, 3 Jan 2020 09:35:08 -0800 > > > > > >> > > > > > >> > The real way to combat this provide open implementation that > > > > > >> > demonstrates the correct use of the protocols and show that's more > > > > > >> > extensible and secure than these "hacks". > > > > > >> > > > > > >> Keep dreaming, this won't stop Cisco from doing whatever it wants to do. > > > > > > > > > > > > See QUIC. See TLS. See TCP fast open. See transport layer encryption. > > > > > > These are prime examples where we've steered the Internet from host > > > > > > protocols and implementation to successfully obsolete or at least work > > > > > > around protocol ossification that was perpetuated by router vendors. > > > > > > Cisco is not the Internet! > > > > > > > > > > Seriously, I wish you luck stopping the SRv6 header insertion stuff. > > > > > > > > > Dave, > > > > > > > > I agree we can't stop it, but maybe we can steer it to be at least > > > > palatable. There are valid use cases for extension header insertion. > > > > Ironically, SRv6 header insertion isn't one of them; the proponents > > > > have failed to offer even a single reason why the alternative of IPv6 > > > > encapsulation isn't sufficient (believe me, we've asked _many_ times > > > > for some justification and only get hand waving!). There are, however, > > > > some interesting uses cases like in IOAM where the operator would like > > > > to annotate packets as they traverse the network. Encapsulation is > > > > insufficient if they don't know what the end point would be or they > > > > don't want the annotation to change the path the packets take (versus > > > > those that aren't annotated). > > > > > > > > The salient problem with extension header insertion is lost of > > > > > > And the problems that can be introduced by changing the effective path MTU... > > > > > Eric, > > > > Yep, increasing the size of packet in transit potentially wreaks havoc > > on PMTU discovery, however I personally think that the issue might be > > overblown. We already have the same problem when tunneling is done in > > the network since most tunneling implementations and deployments just > > assume the operator has set large enough MTUs. As long as all the > > overhead inserted into the packet doesn't reduce the end host PMTU > > below 1280, PMTU discovery and probably even PTB for a packet with > > inserted headers still has right effect. > > > > > > attribution. It is fundamental in the IP protocol that the contents of > > > > a packet are attributed to the source host identified by the source > > > > address. If some intermediate node inserts an extension header that > > > > subsequently breaks the packet downstream then there is no obvious way > > > > to debug this. If an ICMP message is sent because of the receiving > > > > data, then receiving host can't do much with it; it's not the source > > > > of the data in error and nothing in the packet tells who the culprit > > > > is. The Cisco guys have at least conceded one point on SRv6 insertion > > > > due to pushback on this, their latest draft only does SRv6 insertion > > > > on packets that have already been encapsulated in IPIP on ingress into > > > > the domain. This is intended to at least restrict the modified packets > > > > to a controlled domain (I'm note sure if any implementations enforce > > > > this though). My proposal is to require an "attribution" HBH option > > > > that would clearly identify inserted data put in a packet by > > > > middleboxes (draft-herbert-6man-eh-attrib-00). This is a tradeoff to > > > > allow extension header insertion, but require protocol to give > > > > attribution and make it at least somewhat robust and manageable. > > > > > > > > Tom > > > > > > FWIW the SRv6 header insertion stuff is still under discussion in > > > spring wg (last I knew). I proposed one option that could be used to > > > > It's also under discussion in 6man. > > > > > avoid insertion (allow for extra scratch space > > > https://mailarchive.ietf.org/arch/msg/spring/UhThRTNxbHWNiMGgRi3U0SqLaDA), > > > but nothing has been conclusively resolved last I checked. > > > > > > > I saw your proposal. It's a good idea from POV to be conformant with > > RFC8200 and avoid the PMTU problems, but the header insertion > > proponents aren't going to like it at all. First, it means that the > > source is in control of the insertion policy and host is required to > > change-- no way they'll buy into that ;-). Secondly, if the scratch > > space isn't used they'll undoubtedly claim that is unnecessary > > overhead. > > > > Tom > > > > > As everyone probably knows, the draft-ietf-* documents are > > > working-group-adopted documents (though final publication is never > > > guaranteed). My current reading of 6man tea leaves is that neither > > > "ICMP limits" and "MTU option" docs were terribly contentious. > > > Whether code reorg is important for implementing these I'm not > > > competent enough to say. > > > --
Hi Tom, I wasn’t accusing anyone in my message. It is a personal opinion. If my message was misunderstood, then please accept my apologies. Also SRv6 is not highly controversial and this is proven by its adoption rate and ecosystem. I have never seen a highly controversial technology that has (in two years) at least 8 public deployments and is supported by 18 publicly known routing platforms from 8 different vendors. Also has support in the mainline of Linux kernel, FD.io VPP, Wireshark, tcpdump, iptables and nftables. If you are a network operator, would you deply a highly controversial technology in your network ? On Sat, 4 Jan 2020 09:45:59 -0800 Tom Herbert <tom@herbertland.com> wrote: > On Sat, Jan 4, 2020 at 12:05 AM kernel Dev <ahabdels.dev@gmail.com> wrote: > > > > Tom, > > > > I will not go into whether Tom or router vendors is right from IETF perspective as here is not the place to discuss. > > > > But it seems to me that the motivation behind these patches is just to pushback on the current IETF proposals. > > > Sorry, but that is completely untrue. The patches are a general > improvement. The ability to allow modules to register handlers for > options code points has nothing to do with "pushback on the current > IETF protocols". This sort of registration is a mechanism used all > over the place. Similarly, allowing non-priveledged users to send > options is not for any specific protocol-- it is a *general* > mechanism. > > > The patches timeline is completely aligned with when IETF threads get into tough discussions (May 2019, August 2019, and now). > > > Yes, discussion about new protocols in IETF tends to correlate with > development and implementation of the protocols. That shouldn't > surprise anyone. SRv6 for instance was highly controversial in IETF > and yet the patches went in. > > > I’m not the one to decide, but IMO people should not add stuff to the kernel just to enforce their opinions on other mailers. > > I take exception with your insinuation. Seeing as how you might be new > to Linux kernel development I will ignore it. But, in the future, I > strongly suggest you be careful about accusing people about their > motivations based solely on one interaction. > > Tom > > > > > > > > On Fri, 3 Jan 2020 16:37:33 -0800 > > Tom Herbert <tom@herbertland.com> wrote: > > > > > On Fri, Jan 3, 2020 at 3:53 PM Erik Kline <ek@loon.com> wrote: > > > > > > > > On Fri, 3 Jan 2020 at 15:49, Tom Herbert <tom@herbertland.com> wrote: > > > > > > > > > > On Fri, Jan 3, 2020 at 2:57 PM David Miller <davem@davemloft.net> wrote: > > > > > > > > > > > > From: Tom Herbert <tom@herbertland.com> > > > > > > Date: Fri, 3 Jan 2020 14:31:58 -0800 > > > > > > > > > > > > > On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@davemloft.net> wrote: > > > > > > >> > > > > > > >> From: Tom Herbert <tom@herbertland.com> > > > > > > >> Date: Fri, 3 Jan 2020 09:35:08 -0800 > > > > > > >> > > > > > > >> > The real way to combat this provide open implementation that > > > > > > >> > demonstrates the correct use of the protocols and show that's more > > > > > > >> > extensible and secure than these "hacks". > > > > > > >> > > > > > > >> Keep dreaming, this won't stop Cisco from doing whatever it wants to do. > > > > > > > > > > > > > > See QUIC. See TLS. See TCP fast open. See transport layer encryption. > > > > > > > These are prime examples where we've steered the Internet from host > > > > > > > protocols and implementation to successfully obsolete or at least work > > > > > > > around protocol ossification that was perpetuated by router vendors. > > > > > > > Cisco is not the Internet! > > > > > > > > > > > > Seriously, I wish you luck stopping the SRv6 header insertion stuff. > > > > > > > > > > > Dave, > > > > > > > > > > I agree we can't stop it, but maybe we can steer it to be at least > > > > > palatable. There are valid use cases for extension header insertion. > > > > > Ironically, SRv6 header insertion isn't one of them; the proponents > > > > > have failed to offer even a single reason why the alternative of IPv6 > > > > > encapsulation isn't sufficient (believe me, we've asked _many_ times > > > > > for some justification and only get hand waving!). There are, however, > > > > > some interesting uses cases like in IOAM where the operator would like > > > > > to annotate packets as they traverse the network. Encapsulation is > > > > > insufficient if they don't know what the end point would be or they > > > > > don't want the annotation to change the path the packets take (versus > > > > > those that aren't annotated). > > > > > > > > > > The salient problem with extension header insertion is lost of > > > > > > > > And the problems that can be introduced by changing the effective path MTU... > > > > > > > Eric, > > > > > > Yep, increasing the size of packet in transit potentially wreaks havoc > > > on PMTU discovery, however I personally think that the issue might be > > > overblown. We already have the same problem when tunneling is done in > > > the network since most tunneling implementations and deployments just > > > assume the operator has set large enough MTUs. As long as all the > > > overhead inserted into the packet doesn't reduce the end host PMTU > > > below 1280, PMTU discovery and probably even PTB for a packet with > > > inserted headers still has right effect. > > > > > > > > attribution. It is fundamental in the IP protocol that the contents of > > > > > a packet are attributed to the source host identified by the source > > > > > address. If some intermediate node inserts an extension header that > > > > > subsequently breaks the packet downstream then there is no obvious way > > > > > to debug this. If an ICMP message is sent because of the receiving > > > > > data, then receiving host can't do much with it; it's not the source > > > > > of the data in error and nothing in the packet tells who the culprit > > > > > is. The Cisco guys have at least conceded one point on SRv6 insertion > > > > > due to pushback on this, their latest draft only does SRv6 insertion > > > > > on packets that have already been encapsulated in IPIP on ingress into > > > > > the domain. This is intended to at least restrict the modified packets > > > > > to a controlled domain (I'm note sure if any implementations enforce > > > > > this though). My proposal is to require an "attribution" HBH option > > > > > that would clearly identify inserted data put in a packet by > > > > > middleboxes (draft-herbert-6man-eh-attrib-00). This is a tradeoff to > > > > > allow extension header insertion, but require protocol to give > > > > > attribution and make it at least somewhat robust and manageable. > > > > > > > > > > Tom > > > > > > > > FWIW the SRv6 header insertion stuff is still under discussion in > > > > spring wg (last I knew). I proposed one option that could be used to > > > > > > It's also under discussion in 6man. > > > > > > > avoid insertion (allow for extra scratch space > > > > https://mailarchive.ietf.org/arch/msg/spring/UhThRTNxbHWNiMGgRi3U0SqLaDA), > > > > but nothing has been conclusively resolved last I checked. > > > > > > > > > > I saw your proposal. It's a good idea from POV to be conformant with > > > RFC8200 and avoid the PMTU problems, but the header insertion > > > proponents aren't going to like it at all. First, it means that the > > > source is in control of the insertion policy and host is required to > > > change-- no way they'll buy into that ;-). Secondly, if the scratch > > > space isn't used they'll undoubtedly claim that is unnecessary > > > overhead. > > > > > > Tom > > > > > > > As everyone probably knows, the draft-ietf-* documents are > > > > working-group-adopted documents (though final publication is never > > > > guaranteed). My current reading of 6man tea leaves is that neither > > > > "ICMP limits" and "MTU option" docs were terribly contentious. > > > > Whether code reorg is important for implementing these I'm not > > > > competent enough to say. > > > > > > --
sorry forgot to add the link for the public SRv6 deployment. https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-04 On Sat, 4 Jan 2020 21:02:29 +0200 kernel Dev <ahabdels.dev@gmail.com> wrote: > Hi Tom, > > I wasn’t accusing anyone in my message. It is a personal opinion. > If my message was misunderstood, then please accept my apologies. > > Also SRv6 is not highly controversial and this is proven by its adoption rate and ecosystem. > I have never seen a highly controversial technology that has (in two years) at least 8 public deployments and is supported by 18 publicly known routing platforms from 8 different vendors. Also has support in the mainline of Linux kernel, FD.io VPP, Wireshark, tcpdump, iptables and nftables. > > If you are a network operator, would you deply a highly controversial technology in your network ? > > > On Sat, 4 Jan 2020 09:45:59 -0800 > Tom Herbert <tom@herbertland.com> wrote: > > > On Sat, Jan 4, 2020 at 12:05 AM kernel Dev <ahabdels.dev@gmail.com> wrote: > > > > > > Tom, > > > > > > I will not go into whether Tom or router vendors is right from IETF perspective as here is not the place to discuss. > > > > > > But it seems to me that the motivation behind these patches is just to pushback on the current IETF proposals. > > > > > Sorry, but that is completely untrue. The patches are a general > > improvement. The ability to allow modules to register handlers for > > options code points has nothing to do with "pushback on the current > > IETF protocols". This sort of registration is a mechanism used all > > over the place. Similarly, allowing non-priveledged users to send > > options is not for any specific protocol-- it is a *general* > > mechanism. > > > > > The patches timeline is completely aligned with when IETF threads get into tough discussions (May 2019, August 2019, and now). > > > > > Yes, discussion about new protocols in IETF tends to correlate with > > development and implementation of the protocols. That shouldn't > > surprise anyone. SRv6 for instance was highly controversial in IETF > > and yet the patches went in. > > > > > I’m not the one to decide, but IMO people should not add stuff to the kernel just to enforce their opinions on other mailers. > > > > I take exception with your insinuation. Seeing as how you might be new > > to Linux kernel development I will ignore it. But, in the future, I > > strongly suggest you be careful about accusing people about their > > motivations based solely on one interaction. > > > > Tom > > > > > > > > > > > > > On Fri, 3 Jan 2020 16:37:33 -0800 > > > Tom Herbert <tom@herbertland.com> wrote: > > > > > > > On Fri, Jan 3, 2020 at 3:53 PM Erik Kline <ek@loon.com> wrote: > > > > > > > > > > On Fri, 3 Jan 2020 at 15:49, Tom Herbert <tom@herbertland.com> wrote: > > > > > > > > > > > > On Fri, Jan 3, 2020 at 2:57 PM David Miller <davem@davemloft.net> wrote: > > > > > > > > > > > > > > From: Tom Herbert <tom@herbertland.com> > > > > > > > Date: Fri, 3 Jan 2020 14:31:58 -0800 > > > > > > > > > > > > > > > On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@davemloft.net> wrote: > > > > > > > >> > > > > > > > >> From: Tom Herbert <tom@herbertland.com> > > > > > > > >> Date: Fri, 3 Jan 2020 09:35:08 -0800 > > > > > > > >> > > > > > > > >> > The real way to combat this provide open implementation that > > > > > > > >> > demonstrates the correct use of the protocols and show that's more > > > > > > > >> > extensible and secure than these "hacks". > > > > > > > >> > > > > > > > >> Keep dreaming, this won't stop Cisco from doing whatever it wants to do. > > > > > > > > > > > > > > > > See QUIC. See TLS. See TCP fast open. See transport layer encryption. > > > > > > > > These are prime examples where we've steered the Internet from host > > > > > > > > protocols and implementation to successfully obsolete or at least work > > > > > > > > around protocol ossification that was perpetuated by router vendors. > > > > > > > > Cisco is not the Internet! > > > > > > > > > > > > > > Seriously, I wish you luck stopping the SRv6 header insertion stuff. > > > > > > > > > > > > > Dave, > > > > > > > > > > > > I agree we can't stop it, but maybe we can steer it to be at least > > > > > > palatable. There are valid use cases for extension header insertion. > > > > > > Ironically, SRv6 header insertion isn't one of them; the proponents > > > > > > have failed to offer even a single reason why the alternative of IPv6 > > > > > > encapsulation isn't sufficient (believe me, we've asked _many_ times > > > > > > for some justification and only get hand waving!). There are, however, > > > > > > some interesting uses cases like in IOAM where the operator would like > > > > > > to annotate packets as they traverse the network. Encapsulation is > > > > > > insufficient if they don't know what the end point would be or they > > > > > > don't want the annotation to change the path the packets take (versus > > > > > > those that aren't annotated). > > > > > > > > > > > > The salient problem with extension header insertion is lost of > > > > > > > > > > And the problems that can be introduced by changing the effective path MTU... > > > > > > > > > Eric, > > > > > > > > Yep, increasing the size of packet in transit potentially wreaks havoc > > > > on PMTU discovery, however I personally think that the issue might be > > > > overblown. We already have the same problem when tunneling is done in > > > > the network since most tunneling implementations and deployments just > > > > assume the operator has set large enough MTUs. As long as all the > > > > overhead inserted into the packet doesn't reduce the end host PMTU > > > > below 1280, PMTU discovery and probably even PTB for a packet with > > > > inserted headers still has right effect. > > > > > > > > > > attribution. It is fundamental in the IP protocol that the contents of > > > > > > a packet are attributed to the source host identified by the source > > > > > > address. If some intermediate node inserts an extension header that > > > > > > subsequently breaks the packet downstream then there is no obvious way > > > > > > to debug this. If an ICMP message is sent because of the receiving > > > > > > data, then receiving host can't do much with it; it's not the source > > > > > > of the data in error and nothing in the packet tells who the culprit > > > > > > is. The Cisco guys have at least conceded one point on SRv6 insertion > > > > > > due to pushback on this, their latest draft only does SRv6 insertion > > > > > > on packets that have already been encapsulated in IPIP on ingress into > > > > > > the domain. This is intended to at least restrict the modified packets > > > > > > to a controlled domain (I'm note sure if any implementations enforce > > > > > > this though). My proposal is to require an "attribution" HBH option > > > > > > that would clearly identify inserted data put in a packet by > > > > > > middleboxes (draft-herbert-6man-eh-attrib-00). This is a tradeoff to > > > > > > allow extension header insertion, but require protocol to give > > > > > > attribution and make it at least somewhat robust and manageable. > > > > > > > > > > > > Tom > > > > > > > > > > FWIW the SRv6 header insertion stuff is still under discussion in > > > > > spring wg (last I knew). I proposed one option that could be used to > > > > > > > > It's also under discussion in 6man. > > > > > > > > > avoid insertion (allow for extra scratch space > > > > > https://mailarchive.ietf.org/arch/msg/spring/UhThRTNxbHWNiMGgRi3U0SqLaDA), > > > > > but nothing has been conclusively resolved last I checked. > > > > > > > > > > > > > I saw your proposal. It's a good idea from POV to be conformant with > > > > RFC8200 and avoid the PMTU problems, but the header insertion > > > > proponents aren't going to like it at all. First, it means that the > > > > source is in control of the insertion policy and host is required to > > > > change-- no way they'll buy into that ;-). Secondly, if the scratch > > > > space isn't used they'll undoubtedly claim that is unnecessary > > > > overhead. > > > > > > > > Tom > > > > > > > > > As everyone probably knows, the draft-ietf-* documents are > > > > > working-group-adopted documents (though final publication is never > > > > > guaranteed). My current reading of 6man tea leaves is that neither > > > > > "ICMP limits" and "MTU option" docs were terribly contentious. > > > > > Whether code reorg is important for implementing these I'm not > > > > > competent enough to say. > > > > > > > > > -- > > > -- > kernel Dev <ahabdels.dev@gmail.com>
On Sat, Jan 4, 2020 at 11:02 AM kernel Dev <ahabdels.dev@gmail.com> wrote: > > Hi Tom, > > I wasn’t accusing anyone in my message. It is a personal opinion. > If my message was misunderstood, then please accept my apologies. > > Also SRv6 is not highly controversial and this is proven by its adoption rate and ecosystem. It was controversial in the five years it look to get to WGLC, and thanks to things like extension header insertion it will remain controversial. > I have never seen a highly controversial technology that has (in two years) at least 8 public deployments and is supported by 18 publicly known routing platforms from 8 different vendors. Also has support in the mainline of Linux kernel, FD.io VPP, Wireshark, tcpdump, iptables and nftables. > These support only support some subset of the protocol. For instance, SRv6 TLVs including HMAC TLV are defined in SRH, however only Linux claims to support them. However, the Linux implementation isn't protocol conformant: it doesn't support required padding options and just assumes HMAC is the one and only TLV. Previously, I've posted patches to fix that based on the generic parser in this patch set. Those original patches for fixing SRv6 would now be out of date since it was decided to change the PADN option type in SRv6 to be 5 instead of 1 thereby breaking compatibility with HBH and Destination Options. Seeing as how you seem interested in SRv6, it would be nice if you could look into fixing the SRv6 TLV implementation to be conformant (I can repost my original patches if that would help). Thanks, Tom > If you are a network operator, would you deply a highly controversial technology in your network ? > > > On Sat, 4 Jan 2020 09:45:59 -0800 > Tom Herbert <tom@herbertland.com> wrote: > > > On Sat, Jan 4, 2020 at 12:05 AM kernel Dev <ahabdels.dev@gmail.com> wrote: > > > > > > Tom, > > > > > > I will not go into whether Tom or router vendors is right from IETF perspective as here is not the place to discuss. > > > > > > But it seems to me that the motivation behind these patches is just to pushback on the current IETF proposals. > > > > > Sorry, but that is completely untrue. The patches are a general > > improvement. The ability to allow modules to register handlers for > > options code points has nothing to do with "pushback on the current > > IETF protocols". This sort of registration is a mechanism used all > > over the place. Similarly, allowing non-priveledged users to send > > options is not for any specific protocol-- it is a *general* > > mechanism. > > > > > The patches timeline is completely aligned with when IETF threads get into tough discussions (May 2019, August 2019, and now). > > > > > Yes, discussion about new protocols in IETF tends to correlate with > > development and implementation of the protocols. That shouldn't > > surprise anyone. SRv6 for instance was highly controversial in IETF > > and yet the patches went in. > > > > > I’m not the one to decide, but IMO people should not add stuff to the kernel just to enforce their opinions on other mailers. > > > > I take exception with your insinuation. Seeing as how you might be new > > to Linux kernel development I will ignore it. But, in the future, I > > strongly suggest you be careful about accusing people about their > > motivations based solely on one interaction. > > > > Tom > > > > > > > > > > > > > On Fri, 3 Jan 2020 16:37:33 -0800 > > > Tom Herbert <tom@herbertland.com> wrote: > > > > > > > On Fri, Jan 3, 2020 at 3:53 PM Erik Kline <ek@loon.com> wrote: > > > > > > > > > > On Fri, 3 Jan 2020 at 15:49, Tom Herbert <tom@herbertland.com> wrote: > > > > > > > > > > > > On Fri, Jan 3, 2020 at 2:57 PM David Miller <davem@davemloft.net> wrote: > > > > > > > > > > > > > > From: Tom Herbert <tom@herbertland.com> > > > > > > > Date: Fri, 3 Jan 2020 14:31:58 -0800 > > > > > > > > > > > > > > > On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@davemloft.net> wrote: > > > > > > > >> > > > > > > > >> From: Tom Herbert <tom@herbertland.com> > > > > > > > >> Date: Fri, 3 Jan 2020 09:35:08 -0800 > > > > > > > >> > > > > > > > >> > The real way to combat this provide open implementation that > > > > > > > >> > demonstrates the correct use of the protocols and show that's more > > > > > > > >> > extensible and secure than these "hacks". > > > > > > > >> > > > > > > > >> Keep dreaming, this won't stop Cisco from doing whatever it wants to do. > > > > > > > > > > > > > > > > See QUIC. See TLS. See TCP fast open. See transport layer encryption. > > > > > > > > These are prime examples where we've steered the Internet from host > > > > > > > > protocols and implementation to successfully obsolete or at least work > > > > > > > > around protocol ossification that was perpetuated by router vendors. > > > > > > > > Cisco is not the Internet! > > > > > > > > > > > > > > Seriously, I wish you luck stopping the SRv6 header insertion stuff. > > > > > > > > > > > > > Dave, > > > > > > > > > > > > I agree we can't stop it, but maybe we can steer it to be at least > > > > > > palatable. There are valid use cases for extension header insertion. > > > > > > Ironically, SRv6 header insertion isn't one of them; the proponents > > > > > > have failed to offer even a single reason why the alternative of IPv6 > > > > > > encapsulation isn't sufficient (believe me, we've asked _many_ times > > > > > > for some justification and only get hand waving!). There are, however, > > > > > > some interesting uses cases like in IOAM where the operator would like > > > > > > to annotate packets as they traverse the network. Encapsulation is > > > > > > insufficient if they don't know what the end point would be or they > > > > > > don't want the annotation to change the path the packets take (versus > > > > > > those that aren't annotated). > > > > > > > > > > > > The salient problem with extension header insertion is lost of > > > > > > > > > > And the problems that can be introduced by changing the effective path MTU... > > > > > > > > > Eric, > > > > > > > > Yep, increasing the size of packet in transit potentially wreaks havoc > > > > on PMTU discovery, however I personally think that the issue might be > > > > overblown. We already have the same problem when tunneling is done in > > > > the network since most tunneling implementations and deployments just > > > > assume the operator has set large enough MTUs. As long as all the > > > > overhead inserted into the packet doesn't reduce the end host PMTU > > > > below 1280, PMTU discovery and probably even PTB for a packet with > > > > inserted headers still has right effect. > > > > > > > > > > attribution. It is fundamental in the IP protocol that the contents of > > > > > > a packet are attributed to the source host identified by the source > > > > > > address. If some intermediate node inserts an extension header that > > > > > > subsequently breaks the packet downstream then there is no obvious way > > > > > > to debug this. If an ICMP message is sent because of the receiving > > > > > > data, then receiving host can't do much with it; it's not the source > > > > > > of the data in error and nothing in the packet tells who the culprit > > > > > > is. The Cisco guys have at least conceded one point on SRv6 insertion > > > > > > due to pushback on this, their latest draft only does SRv6 insertion > > > > > > on packets that have already been encapsulated in IPIP on ingress into > > > > > > the domain. This is intended to at least restrict the modified packets > > > > > > to a controlled domain (I'm note sure if any implementations enforce > > > > > > this though). My proposal is to require an "attribution" HBH option > > > > > > that would clearly identify inserted data put in a packet by > > > > > > middleboxes (draft-herbert-6man-eh-attrib-00). This is a tradeoff to > > > > > > allow extension header insertion, but require protocol to give > > > > > > attribution and make it at least somewhat robust and manageable. > > > > > > > > > > > > Tom > > > > > > > > > > FWIW the SRv6 header insertion stuff is still under discussion in > > > > > spring wg (last I knew). I proposed one option that could be used to > > > > > > > > It's also under discussion in 6man. > > > > > > > > > avoid insertion (allow for extra scratch space > > > > > https://mailarchive.ietf.org/arch/msg/spring/UhThRTNxbHWNiMGgRi3U0SqLaDA), > > > > > but nothing has been conclusively resolved last I checked. > > > > > > > > > > > > > I saw your proposal. It's a good idea from POV to be conformant with > > > > RFC8200 and avoid the PMTU problems, but the header insertion > > > > proponents aren't going to like it at all. First, it means that the > > > > source is in control of the insertion policy and host is required to > > > > change-- no way they'll buy into that ;-). Secondly, if the scratch > > > > space isn't used they'll undoubtedly claim that is unnecessary > > > > overhead. > > > > > > > > Tom > > > > > > > > > As everyone probably knows, the draft-ietf-* documents are > > > > > working-group-adopted documents (though final publication is never > > > > > guaranteed). My current reading of 6man tea leaves is that neither > > > > > "ICMP limits" and "MTU option" docs were terribly contentious. > > > > > Whether code reorg is important for implementing these I'm not > > > > > competent enough to say. > > > > > > > > > -- > > > -- > kernel Dev <ahabdels.dev@gmail.com>
On Sat, 4 Jan 2020 12:22:17 -0800 Tom Herbert <tom@herbertland.com> wrote: > On Sat, Jan 4, 2020 at 11:02 AM kernel Dev <ahabdels.dev@gmail.com> wrote: > > > > Hi Tom, > > > > I wasn’t accusing anyone in my message. It is a personal opinion. > > If my message was misunderstood, then please accept my apologies. > > > > Also SRv6 is not highly controversial and this is proven by its adoption rate and ecosystem. > > It was controversial in the five years it look to get to WGLC, and > thanks to things like extension header insertion it will remain > controversial. But it is not anymore :) > > > I have never seen a highly controversial technology that has (in two years) at least 8 public deployments and is supported by 18 publicly known routing platforms from 8 different vendors. Also has support in the mainline of Linux kernel, FD.io VPP, Wireshark, tcpdump, iptables and nftables. > > > > These support only support some subset of the protocol. For instance, > SRv6 TLVs including HMAC TLV are defined in SRH, however only Linux > claims to support them. However, the Linux implementation isn't > protocol conformant: it doesn't support required padding options and > just assumes HMAC is the one and only TLV. Previously, I've posted > patches to fix that based on the generic parser in this patch set. > Those original patches for fixing SRv6 would now be out of date since > it was decided to change the PADN option type in SRv6 to be 5 instead > of 1 thereby breaking compatibility with HBH and Destination Options. > Seeing as how you seem interested in SRv6, it would be nice if you > could look into fixing the SRv6 TLV implementation to be conformant (I > can repost my original patches if that would help). I’m ok and willing to contribute to add missing pieces of SRv6 to the Linux kernel. I was just not convinced with the idea of IPv4 extensions headers as we do not need to reinvent the wheel. We need IPv6 as we ran out of IPv4, and I believe SRv6 can handle most of IPv6 use-cases. > > Thanks, > Tom > > > > If you are a network operator, would you deply a highly controversial technology in your network ? > > > > > > On Sat, 4 Jan 2020 09:45:59 -0800 > > Tom Herbert <tom@herbertland.com> wrote: > > > > > On Sat, Jan 4, 2020 at 12:05 AM kernel Dev <ahabdels.dev@gmail.com> wrote: > > > > > > > > Tom, > > > > > > > > I will not go into whether Tom or router vendors is right from IETF perspective as here is not the place to discuss. > > > > > > > > But it seems to me that the motivation behind these patches is just to pushback on the current IETF proposals. > > > > > > > Sorry, but that is completely untrue. The patches are a general > > > improvement. The ability to allow modules to register handlers for > > > options code points has nothing to do with "pushback on the current > > > IETF protocols". This sort of registration is a mechanism used all > > > over the place. Similarly, allowing non-priveledged users to send > > > options is not for any specific protocol-- it is a *general* > > > mechanism. > > > > > > > The patches timeline is completely aligned with when IETF threads get into tough discussions (May 2019, August 2019, and now). > > > > > > > Yes, discussion about new protocols in IETF tends to correlate with > > > development and implementation of the protocols. That shouldn't > > > surprise anyone. SRv6 for instance was highly controversial in IETF > > > and yet the patches went in. > > > > > > > I’m not the one to decide, but IMO people should not add stuff to the kernel just to enforce their opinions on other mailers. > > > > > > I take exception with your insinuation. Seeing as how you might be new > > > to Linux kernel development I will ignore it. But, in the future, I > > > strongly suggest you be careful about accusing people about their > > > motivations based solely on one interaction. > > > > > > Tom > > > > > > > > > > > > > > > > > > On Fri, 3 Jan 2020 16:37:33 -0800 > > > > Tom Herbert <tom@herbertland.com> wrote: > > > > > > > > > On Fri, Jan 3, 2020 at 3:53 PM Erik Kline <ek@loon.com> wrote: > > > > > > > > > > > > On Fri, 3 Jan 2020 at 15:49, Tom Herbert <tom@herbertland.com> wrote: > > > > > > > > > > > > > > On Fri, Jan 3, 2020 at 2:57 PM David Miller <davem@davemloft.net> wrote: > > > > > > > > > > > > > > > > From: Tom Herbert <tom@herbertland.com> > > > > > > > > Date: Fri, 3 Jan 2020 14:31:58 -0800 > > > > > > > > > > > > > > > > > On Fri, Jan 3, 2020 at 12:45 PM David Miller <davem@davemloft.net> wrote: > > > > > > > > >> > > > > > > > > >> From: Tom Herbert <tom@herbertland.com> > > > > > > > > >> Date: Fri, 3 Jan 2020 09:35:08 -0800 > > > > > > > > >> > > > > > > > > >> > The real way to combat this provide open implementation that > > > > > > > > >> > demonstrates the correct use of the protocols and show that's more > > > > > > > > >> > extensible and secure than these "hacks". > > > > > > > > >> > > > > > > > > >> Keep dreaming, this won't stop Cisco from doing whatever it wants to do. > > > > > > > > > > > > > > > > > > See QUIC. See TLS. See TCP fast open. See transport layer encryption. > > > > > > > > > These are prime examples where we've steered the Internet from host > > > > > > > > > protocols and implementation to successfully obsolete or at least work > > > > > > > > > around protocol ossification that was perpetuated by router vendors. > > > > > > > > > Cisco is not the Internet! > > > > > > > > > > > > > > > > Seriously, I wish you luck stopping the SRv6 header insertion stuff. > > > > > > > > > > > > > > > Dave, > > > > > > > > > > > > > > I agree we can't stop it, but maybe we can steer it to be at least > > > > > > > palatable. There are valid use cases for extension header insertion. > > > > > > > Ironically, SRv6 header insertion isn't one of them; the proponents > > > > > > > have failed to offer even a single reason why the alternative of IPv6 > > > > > > > encapsulation isn't sufficient (believe me, we've asked _many_ times > > > > > > > for some justification and only get hand waving!). There are, however, > > > > > > > some interesting uses cases like in IOAM where the operator would like > > > > > > > to annotate packets as they traverse the network. Encapsulation is > > > > > > > insufficient if they don't know what the end point would be or they > > > > > > > don't want the annotation to change the path the packets take (versus > > > > > > > those that aren't annotated). > > > > > > > > > > > > > > The salient problem with extension header insertion is lost of > > > > > > > > > > > > And the problems that can be introduced by changing the effective path MTU... > > > > > > > > > > > Eric, > > > > > > > > > > Yep, increasing the size of packet in transit potentially wreaks havoc > > > > > on PMTU discovery, however I personally think that the issue might be > > > > > overblown. We already have the same problem when tunneling is done in > > > > > the network since most tunneling implementations and deployments just > > > > > assume the operator has set large enough MTUs. As long as all the > > > > > overhead inserted into the packet doesn't reduce the end host PMTU > > > > > below 1280, PMTU discovery and probably even PTB for a packet with > > > > > inserted headers still has right effect. > > > > > > > > > > > > attribution. It is fundamental in the IP protocol that the contents of > > > > > > > a packet are attributed to the source host identified by the source > > > > > > > address. If some intermediate node inserts an extension header that > > > > > > > subsequently breaks the packet downstream then there is no obvious way > > > > > > > to debug this. If an ICMP message is sent because of the receiving > > > > > > > data, then receiving host can't do much with it; it's not the source > > > > > > > of the data in error and nothing in the packet tells who the culprit > > > > > > > is. The Cisco guys have at least conceded one point on SRv6 insertion > > > > > > > due to pushback on this, their latest draft only does SRv6 insertion > > > > > > > on packets that have already been encapsulated in IPIP on ingress into > > > > > > > the domain. This is intended to at least restrict the modified packets > > > > > > > to a controlled domain (I'm note sure if any implementations enforce > > > > > > > this though). My proposal is to require an "attribution" HBH option > > > > > > > that would clearly identify inserted data put in a packet by > > > > > > > middleboxes (draft-herbert-6man-eh-attrib-00). This is a tradeoff to > > > > > > > allow extension header insertion, but require protocol to give > > > > > > > attribution and make it at least somewhat robust and manageable. > > > > > > > > > > > > > > Tom > > > > > > > > > > > > FWIW the SRv6 header insertion stuff is still under discussion in > > > > > > spring wg (last I knew). I proposed one option that could be used to > > > > > > > > > > It's also under discussion in 6man. > > > > > > > > > > > avoid insertion (allow for extra scratch space > > > > > > https://mailarchive.ietf.org/arch/msg/spring/UhThRTNxbHWNiMGgRi3U0SqLaDA), > > > > > > but nothing has been conclusively resolved last I checked. > > > > > > > > > > > > > > > > I saw your proposal. It's a good idea from POV to be conformant with > > > > > RFC8200 and avoid the PMTU problems, but the header insertion > > > > > proponents aren't going to like it at all. First, it means that the > > > > > source is in control of the insertion policy and host is required to > > > > > change-- no way they'll buy into that ;-). Secondly, if the scratch > > > > > space isn't used they'll undoubtedly claim that is unnecessary > > > > > overhead. > > > > > > > > > > Tom > > > > > > > > > > > As everyone probably knows, the draft-ietf-* documents are > > > > > > working-group-adopted documents (though final publication is never > > > > > > guaranteed). My current reading of 6man tea leaves is that neither > > > > > > "ICMP limits" and "MTU option" docs were terribly contentious. > > > > > > Whether code reorg is important for implementing these I'm not > > > > > > competent enough to say. > > > > > > > > > > > > -- > > > > > > -- > > kernel Dev <ahabdels.dev@gmail.com>
The fundamental rationale here is to make various TLVs, in particular Hop-by-Hop and Destination options, usable, robust, scalable, and extensible to support emerging functionality. Specifically, this patch set: 1) Allow modules to register support for Hop-by-Hop and Destination options. This is useful for development and deployment of new options. 2) Allow non-privileged users to set Hop-by-Hop and Destination options for their packets or connections. This is especially useful for options like Path MTU and IOAM options where the information in the options is both sourced and sinked by the application. The alternative to this would be to create more side interfaces so that the option can be enabled via the kernel-- such side interfaces would be overkill IMO. 3) In conjunction with #2, validation of the options being set by an application is done. The validation for non-privileged users is purposely strict, but even in the case of privileged user validation is useful to disallow allow application from sending gibberish (for instance, now a TLV could be created with a length exceeding the bound of the extension header). 4) Consolidate various TLV mechanisms. Segment routing should be able to use the same TLV parsing function, as should UDP options when they come into the kernel. 5) Option lookup on receive is O(1) instead of list scan. Subsequent patch sets will include: 6) Allow setting specific (Hop-by-Hop and Destination) options on a socket. This would also allow some options to be set by application and some might be set by kernel. 7) Allow options processing to be done in the context of a socket. This will be useful for FAST and PMTU options. 8) Allow experimental IPv6 options in the same way that experimental TCP options are allowed. 9) Support a robust means of extension header insertion. Extension header insertion is a controversial mechanism that some router vendors are insisting upon (see ongoing discussion in 6man list). The way they are currently doing it breaks the stack (particularly ICMP and the way networks are debugged), with proper support we can at least mitigate the effects of the problems being created by extension header insertion. 10) Support IPv4 extension headers. This again attempts to address some horrendous and completely non-robust hacks that are currently being perpetuated by some router vendors. For instance, some middlebox implementations are currently insert into TCP or UDP payload their own data with the assumption that a peer device will restore correct data. If they ever miss fixing up the payload then we now have systematic silent data corruption (IMO, this is very dangerous in a large scale deployment!). We can offer a better approach... Changes in this patch set: - Reorganize extension header files to separate out common API components - Create common TLV handler that will can be used in other use cases (e.g. segment routing TLVs, UDP options) - Allow registration of TLV handlers - Elaborate on the TLV tables to include more characteristics - Add a netlink interface to set TLV parameters (such as alignment requirements, authorization to send, etc.) - Enhance validation of TLVs being sent. Validation is strict (unless overridden by admin) following that sending clause of the robustness principle - Allow non-privileged users to set Hop-by-Hop and Destination Options if authorized by the admin v2: - Fix build errors from missing include file. v3: - Fix kbuild issue for ipv6_opt_hdr declared inside parameter list in ipeh.h v4: - Resubmit v5: - Fix reverse christmas tree issue v6: - Address comments from Simon Horman - Remove new EXTHDRS Kconfig symbol, just use IPV6 for now - Split out introduction of parse_error for TLV parsing loop into its own patch - Fix drop counters in HBH and destination options processing - Add extack error messages in netlink code - Added range of permissions in include/uapi/linux/ipeh.h - Check that min data length is <= max data length when setting TLV attributes v7: - Fix incorrect index in checking for nonzero padding - Use dev_net(skb->dev) in all cases of __IP6_INC_STATS for hopopts and destopts (addresses comment from Willem de Bruijin) v8: - Elaborate on justification for patches in the summary commit log Tom Herbert (9): ipeh: Fix destopts counters on drop ipeh: Create exthdrs_options.c and ipeh.h ipeh: Move generic EH functions to exthdrs_common.c ipeh: Generic TLV parser ipeh: Add callback to ipeh_parse_tlv to handle errors ip6tlvs: Registration of TLV handlers and parameters ip6tlvs: Add TX parameters ip6tlvs: Add netlink interface ip6tlvs: Validation of TX Destination and Hop-by-Hop options include/net/ipeh.h | 209 ++++++++ include/net/ipv6.h | 12 +- include/uapi/linux/in6.h | 6 + include/uapi/linux/ipeh.h | 53 ++ net/dccp/ipv6.c | 2 +- net/ipv6/Makefile | 3 +- net/ipv6/calipso.c | 6 +- net/ipv6/datagram.c | 51 +- net/ipv6/exthdrs.c | 514 ++----------------- net/ipv6/exthdrs_common.c | 1216 ++++++++++++++++++++++++++++++++++++++++++++ net/ipv6/exthdrs_options.c | 342 +++++++++++++ net/ipv6/ipv6_sockglue.c | 39 +- net/ipv6/raw.c | 2 +- net/ipv6/tcp_ipv6.c | 2 +- net/ipv6/udp.c | 2 +- net/l2tp/l2tp_ip6.c | 2 +- net/sctp/ipv6.c | 2 +- 17 files changed, 1942 insertions(+), 521 deletions(-) create mode 100644 include/net/ipeh.h create mode 100644 include/uapi/linux/ipeh.h create mode 100644 net/ipv6/exthdrs_common.c create mode 100644 net/ipv6/exthdrs_options.c