[net-next,0/3] exthdrs: Make ext. headers & options useful - Part I

Extension headers are the mechanism of extensibility for the IPv6
protocol, however to date they have only seen limited deployment.
The reasons for that are because intermediate devices don't handle
them well, and there haven't really be any useful extension headers
defined. In particular, Destination and Hop-by-Hop options have
not been deployed to any extent.

The landscape may be changing as there are now a number of serious
efforts to define and deploy extension headers. In particular, a number
of uses for Hop-by-Hop Options are currently being proposed, Some of
these are from router vendors so there is hope that they might start
start to fix their brokenness. These proposals include (IOAM, Path MTU,
Firewall and Service Tickets).

Assuming that IPv6 extension headers gain traction, that leaves a
noticeable gap in IPv4 support. IPv4 options have long been considered a
non-starter for deployment. An alternative being proposed is to enable
use of IPv6 options with IPv4 (draft-herbert-ipv4-udpencap-eh-01).

This series of patch sets endeavours to make extension headers IPv6
options useful and easy to use. The following items will be included:

  - Reorganize extension header files
  - 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
  - Add an API that allows individual Hop-by-Hop and Destination
    Options to be set or removed for a connected socket. The
    backend end enforces permissions on what TLVs may be set and
    merges set TLVs per following the rules in the TLV parameter table
    (for instance, TLV parameters include a preferred sending order
    that merging adheres to)
  - Enable IPv4 extension headers

------

This patch series is Part I. It reorganizes the extension header related
files to make them easier to maintain and update. They are:

exthdrs6.c (originally exthdrs.c) - This file contains IPv6 specific
           extension header processing including the TLV parsing loop
           and routing header processing

exthdrs6_offload.c (originally exthdrs_offload.c) - This file contains
           IPv6 GRO/GSO offload support for extension headers.

exthdrs6_options.c (new) - This file contains the code for processing
           specific Hop-by-Hop and Destination options (HAO, RA,
	   Jumbo payload, and Calipso)

exthdrs_core.c (existing) - This file contains only generic functions
	   and helpers for extension headers and options. The intent
	   is that its functions will also be called for IPv4
	   extension headers.

Tested:

Set Hop-by-Hop options on TCP/UDP socket and verified to be functional.

Tom Herbert (3):
  exthdrs: Create exthdrs_options.c
  exthdrs: Move generic EH functions to exthdrs_core.c
  exthdrs: Rename EH files that are IPv6 specific

 include/net/ipv6.h          |   15 +
 net/ipv6/Makefile           |    6 +-
 net/ipv6/exthdrs.c          | 1172 -------------------------------------------
 net/ipv6/exthdrs6.c         |  830 ++++++++++++++++++++++++++++++
 net/ipv6/exthdrs6_offload.c |   41 ++
 net/ipv6/exthdrs6_options.c |  201 ++++++++
 net/ipv6/exthdrs_core.c     |  138 +++++
 net/ipv6/exthdrs_offload.c  |   41 --
 8 files changed, 1228 insertions(+), 1216 deletions(-)
 delete mode 100644 net/ipv6/exthdrs.c
 create mode 100644 net/ipv6/exthdrs6.c
 create mode 100644 net/ipv6/exthdrs6_offload.c
 create mode 100644 net/ipv6/exthdrs6_options.c
 delete mode 100644 net/ipv6/exthdrs_offload.c

From: Tom Herbert <tom@herbertland.com>
Date: Tue,  2 Apr 2019 19:36:25 -0700

> This patch series is Part I. It reorganizes the extension header related
> files to make them easier to maintain and update. They are:

If we don't see the patches that add ipv4 support alongside this I'm
not going to apply patches that just move stuff all over the place for
no actual tractable benefit.