The difference lies in the timing and location of the service load balancing decision within the eBPF-powered datapath. In a standard Cilium with kube-proxy replacement, the service load balancing for traffic between pods happens at the socket level. The load balancing resolves the ClusterIP to the backend pod IP at the pod's network interface, resulting in traffic showing the backend IP (e.g., 10.233.66.81). Meanwhile on a GKE Dataplane v2, the service load balancing and IP translation happen at the packet level, so the ClusterIP (e.g., 34.118.232.190) is visible on the pod's interface, and the DNAT to the backend pod IP (e.g., 10.80.5.15) happens later in the node's network stack.