Reaching IPv4 Destinations

An identity is an IPv6 address. That is what makes it checkable: the reverse record, the forward record, the key pin and the registry entry all describe that one address. There is no IPv4 form of it, so what a destination sees depends on what the destination speaks.

The two cases

A destination reachable over IPv6 sees the agent's own address. Everything in The Address as Identity applies: the far end can run dig -x, read the registry and decide whether to let the connection in, with no key and no prior arrangement.

A destination that answers only on IPv4 sees a shared gateway address instead. The connection still leaves through Whisper, and your policy still applies to the name lookup that preceded it, but the source the destination logs is not unique to your agent.

Attributing a connection the far end cannot name

Your own records carry the attribution that the destination's records cannot. Connection rows name the agent that opened each flow, so you can answer "which of my agents talked to that host" from your side of the conversation:

whisper logs --agent checkout-bot --from -24h --kind conn

The same rows are available on the control plane through Read Query Logs, which is the surface to use when something else has to correlate them, such as a case record or an export.

Let this decide what you ask for when you negotiate access with somebody else's API. For an IPv6 destination, your address is the allowlist entry and it needs nothing else. For an IPv4-only destination, ask for a per-caller credential and keep the address out of the agreement, so the claim rests on something that identifies you alone.

Egressing from an IPv4-only host

The other direction is easier than it looks. The bound proxy accepts connections over IPv4, so a host or a container with no IPv6 connectivity can still reach it and still egress from the agent's address. The tier you land on does not change because of the host's own protocol support; see Connectivity Tiers.

Checking which one happened

The keyless echo reports the source it was reached from, so asking it over each protocol family tells you exactly what a destination of each kind would see:

whisper run curl -6 -s https://rdap.whisper.online/egress-ip
whisper run curl -4 -s https://rdap.whisper.online/egress-ip

The first answers with the agent's address. The second answers with the shared gateway address, and that is the value to expect in an IPv4-only destination's logs.