Add ALPN (Application-Layer Protocol Negotiation) support for client-side / outbound TLS connections

To emphasize why this is a blocking limitation rather than an optimization: ALPN is not optional for HTTP/2 over TLS.

RFC 9113 (HTTP/2, obsoleting RFC 7540) requires that a client making an HTTP/2 connection over TLS use ALPN (RFC 7301) with the protocol identifier "h2". There is no other standardized mechanism to establish an "h2" connection over TLS — protocol negotiation must happen in the TLS handshake itself. A TLS client that omits the ALPN extension therefore cannot, by specification, speak HTTP/2 to a TLS-protected backend at all.

The practical consequence for DataPower: as long as outbound TLS connections cannot advertise ALPN in the ClientHello, HTTP/2 and gRPC (which runs over HTTP/2) to any spec-compliant TLS backend is structurally impossible from the appliance — it is not a matter of the backend being overly strict. Backends that require ALPN (AWS ALB with gRPC/HTTP/2 target groups, GCP load balancers, most gRPC servers) will either reject the handshake with a no_application_protocol alert or silently downgrade to HTTP/1.1, breaking gRPC entirely.

Given that this is a hard protocol requirement defined by the IETF standards themselves (RFC 7301 + RFC 9113), client-side ALPN support should be treated as a baseline interoperability requirement, not an enhancement. Requesting this be high prioritized accordingly.

RFC 7301 defines ALPN (Application-Layer Protocol Negotiation), a TLS extension published by the IETF in July 2014.

The problem it solves: when a client connects to a server over TLS, both sides may support multiple application protocols on the same port (for example, HTTP/1.1 and HTTP/2 on port 443). Without a negotiation mechanism, they'd need extra round trips after the TLS handshake to figure out which protocol to speak.

How it works: the client includes an ALPN extension in its TLS ClientHello listing the protocols it supports, in order of preference (e.g. "h2", "http/1.1"). The server picks one and returns its choice in the ServerHello. The negotiation happens inside the TLS handshake itself, so no additional round trips are needed, and the chosen protocol is established by the time the handshake completes. If the server supports none of the client's protocols, it can abort with a "no_application_protocol" alert.

Some context worth knowing:

• ALPN replaced NPN (Next Protocol Negotiation), an earlier Google-designed extension used with SPDY. A key difference is that in ALPN the server makes the final protocol selection rather than the client, and the choice is sent in the clear (though in TLS 1.3 the server's extensions are encrypted).
• Its most important use case is HTTP/2: browsers require ALPN to negotiate h2 over TLS. It's also used for HTTP/3 negotiation signaling, gRPC, and other protocols.
• Protocol identifiers are registered with IANA in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry.

The authors were Stephan Friedl, Andrei Popov, Adam Langley, and Emile Stephan. If you want the full text, it's at https://www.rfc-editor.org/rfc/rfc7301.