IPv6 semantics differ from Kubernetes without Linkerd

[howardjohn]

What is the issue?

If a workload is created in a dual stack cluster, with a dual stack service, but the pod does NOT listen on IPv6, all traffic will fail. Without linkerd this generally works since the client will happy-eyeballs between the two ipfamilies (or maybe not; but curl does).

With linkerd, it appears regardless of the IP family of the incoming request, the IPv6 pod IP will always be used.

How can it be reproduced?

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo
spec:
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      securityContext:
        sysctls:
        - name: net.ipv4.ip_unprivileged_port_start
          value: "0"
      containers:
      - name: echo
        image: gcr.io/istio-testing/app:latest
        imagePullPolicy: IfNotPresent
        args:
        - --port=80
        - --bind-ip=80
        env:
        - name: INSTANCE_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
---
apiVersion: v1
kind: Service
metadata:
  name: echo
spec:
  ipFamilies:
  - IPv6
  - IPv4
  ipFamilyPolicy: RequireDualStack
  selector:
    app: echo
  ports:
  - name: http
    port: 80

Example app above that only binds to IPv4 address.

Logs, error output, etc

Error is a 502 gateway error. Sorry I tore down the env so don't have the full log. linkerd diagnostics endpoints only shows one IPv6 address.

output of linkerd check -o short

n/a

Environment

v1.30.0 kind edge-24.6.1

Possible solution

I am not sure really what is the right behavior. Part of what led me down this path was exploring how we should behave in this scenario in Istio. I thought it might be helpful to bring up in case this was unexpected, or warrants some document, etc.

Additional context

No response

Would you like to work on fixing this bug?

no