It is not possible to know your public IP address, except by fetching the information from a known entity on the public network.

And in some scenarios, your public IP will change frequently. There is no guarantee that it will be consistent across multiple requests.

  * /ip   responds with the src ip of the request
  * /req  responds with the full headers and body of the request

Once you have been allocated an IP address, there should be a way to fetch said address. That's the whole mechanism behind forging UDP packets. If I didn't know what my source IP address was, it would be OK to send 0.0.0.0 out into the world all the time.

Practically speaking, today, it is, considering most, but not all, ISPs won't let you do this and they will rewrite UDP packets that attempt to forge their source.

Edit: OK, since I'm not being clear, let me be explicit: There should be a mechanism in DHCP which allows for the querying of your public Internet address when receiving a packet from a client in one of the Private-Use Networks as defined in RFC 6890. This query should be exposed as a feature of ifconfig or ip, lest a user be forced to manually write such a packet to receive the data.

Particularly in these days of IPv6, just give everything a notionally publicly routable address and then every device can know its real address (of course this doesn't have to mean you actually route public traffic to every address if you don't want to).

In live networks, you don't always know which device presents your last-hop routable address to the public network, so it is not clear who can authoritatively answer the whatismyip question.

You can get an instantaneously-correct answer (i.e. correct in the instant, not necessarily quickly-answered) from an empirical test, but you need to choose an known (and trusted) entity on the public network to query. Querying multiple different entities might very well get you multiple different answers, depending on how your packets are routed and manipulated before they reach the public network.

And in all cases, there is no guarantee that your public address will be stable over time or location.

Also do keep in mind that an OS instance can have multiple Ethernet interfaces, and that each interface can have multiple IPs, and that not all DHCP gives out private addresses(University Wi-Fi gave me 133.xx back in the days ... behind NAT!), and that double NAT exists.

1: https://www.iana.org/assignments/bootp-dhcp-parameters/bootp...

Well, there’s assumption 1 that isn’t true, often, you aren’t allocated a public IP address…at least in IPv4 world

Upnp allows you to do that. But that relies on a lot of assumptions. Your address when connecting to X and Y could be different. It could be different depending on the port. It could be load-balanced and come randomly from a pool. It could vary depending on time of day. And many many other cases.

There is no singular thing called a "public Internet address". Imagine you're writing paper letters to someone. You write a letter, you put your own From address, you drop it in the slot. When the mailperson comes to collect the letter, they replace your mailing address with a special other codeword. And when they receive mail, they replace that codeword back with your original address. You would never know it was intercepted unless you asked around. There's no official protocol to ask for your codeword, it's just a trick the mail service does on your behalf.

Your home router does exactly this; it's known as "Network Address Translation", or NAT. It's not an official part of IPv4, and there's no protocol to ask what it is. Your computer thinks its local IP address (typically some variety of 192.168.0.1) is its real, public address, and your router does the swap behind your back.

There sort of is, it just doesn't help answer the question.

Both types of addresses have blocks explicitly carved out which are not unicast addresses to be routed over the public Internet. If you have one of those addresses, such as 192.168.0.1, that definitely isn't your "public Internet address" because people can't route stuff to it.

When the host has a non-private-use address, there might still be NAT, or there might be no Internet access. I have servers in 128...* without Internet access.

The "public" address might differ depending on the destination or anything else.

"ip ad" shows the address(es) the network interfaces has, nothing more.

Because traditionally if you're doing things right, you're not using NAT, which is against IP specs and a nonstandard kludge. So you just take your socket and query its local endpoint address using getsockname and voila.

Genuinely asking because I've always used the query

    dig +short myip.opendns.com @resolver1.opendns.com

I use Route53 and I either completely missed the checkip link or they simply don't mention it

dig... | tr... works fine without it.

also, `dig -4 ... ` to get your IPv4 address, for us dual-stacked folks. Otherwise it returns your V6 address by default.