Support IP based Host matching in HTTPRoute.spec.hostnames (IPv4 and IPv6)

[alviss7]

What would you like to be added:

I would like to be able to route HTTP traffic based on IP addresses in HTTPRoute.spec.hostnames, for DNS over HTTPS (DoH) use cases, in a way that is consistent for both IPv4 and IPv6.

Today the Hostname type is documented as not allowing IPs, and validated with the regex:

^(\*\.)?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$

However, this regex actually matches IPv4-like values such as 192.0.2.10, and at least one implementation (Envoy Gateway) correctly accepts and routes a HTTPRoute with:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httproute-test
  namespace: httproute-test
spec:
  hostnames:
    - '192.0.2.10'
  parentRefs:
    - name: shared-gateway
      namespace: envoy-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: httpbin-a
          port: 8080

and successfully routes HTTP traffic where Host: 192.0.2.10.

I would like the spec to either:

1. Explicitly support IP addresses (both IPv4 and IPv6) in HTTPRoute.spec.hostnames for valid use cases like DoH, with a clear validation model,
   or
2. Explicitly clarify that IPs must not be allowed (including 192.0.2.10), and provide a standard, spec-compliant way to express this kind of routing (for example, a different field, route type, or documented pattern).

---

Why this is needed:

For DNS over HTTPS, some clients use an IP address as the endpoint, for example:

• https://192.0.2.10/dns-query
• https://[2001:db8::10]/dns-query

In these cases, the client sends an HTTP request with an IP in the Host header.

Today:

• The spec says IPs are not allowed in Hostname, but the regex still matches IPv4 values like 192.0.2.10.
• With Envoy Gateway, HTTPRoute.hostnames: ["192.0.2.10"] works correctly for IPv4.
• There is no way to express the same behavior for IPv6, because IPv6 strings (e.g. 2001:db8::10 or [2001:db8::10]) cannot match the Hostname regex.

This leaves me in an ambiguous state:

• For IPv4, I can rely on behavior that is effectively out of spec (the regex accepts the value and the implementation routes it).
• For IPv6, I have no standard way to express the same need.

[howardjohn]

One important thing to note is that the HTTPRotue hostname has interaction with the Gateway hostname. Which, for HTTPS, is the SNI. SNI cannot have an IP. This leads to a state where, in order to use HTTPS + IP match, you must not have a hostname in the Gateway.

Which is maybe fine, just wanted to call it out.

[alviss7]

Thanks for pointing that out.

That’s exactly how I tested it: I didn’t set any hostname on the Gateway, and only used hostnames: ["192.0.2.10"] on the HTTPRoute. In that setup, HTTPS + IP matching worked fine with Envoy Gateway.

[youngnick]

Yeah, I can see the use case, but I don't know if we need to change anything, given that it seems unlikely that you'll be having multiple HTTPRoutes that need different IP addresses as hostnames?

hostname is not required to be set for exactly this sort of reason - in that case, it's expected that any Host header is accepted, and the effect is that you can't have multiple HTTPRoutes with matching route matches, since there's no routing discriminator available.

I guess I'm saying that I'd prefer to say "IPs are not valid in hostname", and direct folks to just not set hostname instead.

(While also reminding them that you can use sectionName in HTTPRoute parentRef to ensure that the HTTPRoute only attaches to a specific Listener).

[streamnsight]

One important thing to note is that the HTTPRotue hostname has interaction with the Gateway hostname. Which, for HTTPS, is the SNI. SNI cannot have an IP. This leads to a state where, in order to use HTTPS + IP match, you must not have a hostname in the Gateway.

Which is maybe fine, just wanted to call it out.

With IP Certs, it's now possible

[alviss7]

SNI still cannot use an IP address.

Per RFC 6066 section 3, the host_name in the SNI extension must be a DNS name and literal IPv4/IPv6 addresses are not permitted:
https://datatracker.ietf.org/doc/html/rfc6066#section-3

When a client connects by IP (e.g. https://192.0.2.10) and does not send SNI, most TLS servers simply pick the first/default certificate configured for that IP:port.

If the intent was to use API Gateway + cert-manager to issue these certificates, I’ve updated cert-manager so that it no longer sets a hostname on the Gateway when we need to solve HTTP-01 challenges via an IP, which makes this setup workable:
cert-manager/cert-manager#8443

[streamnsight]

@alviss7
Not sure I am following your comment. I have it working fine with cert-manager and Gateway, but with an IPv4. Is it an issue specific to IPv6?

[alviss7]

This is a problem specific to IPv6, but cert manager's behavior is not correct in IPv4 even though it works. Look at the issue associated with the PR, everything is explained in there. cert-manager/cert-manager#8442