[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3cde6506-821c-43f9-a53e-4ddddbb90f79@frank.fyi>
Date: Sun, 13 Apr 2025 22:56:57 +0000
From: Klaus Frank <vger.kernel.org@...nk.fyi>
To: jon@...def.net, netdev@...r.kernel.org
Subject: Re: Is there a way for ifconfig to return wan ip addresses?
Hi,
the short or the long answer?
The short answer "yes, but no".
Also your router may not even know your wan ip either (in case of CG-NAT).
The long anser:
It is quite complicated as there are way too many "standards" for this
and none of them is universal. Basically you'd have to try a bunch of
different approaches and somehow also figure out what to do with
conflicting information. I'll provide them as a kind of list as maybe
one of them alone (without having a truely universal algorithm for it)
may be enough. Further I'm going to assume you mean for IPv4 as in an
IPv6 network you'd already have your GUA(s) on your interface (well, or
at least on a interface, not necessarily the upstream one but anyway
thats a different topic).
* RFC 7788 "Home Network Control Protocol"
* RFC 7618 "Dynamic Shared IPv4 Allocation"
* RFC 6886 "NAT Port Mapping Protocol (NAT-PMP)"
* RFC 6970 "Universal Plug and Play (UPnP) Internet Gateway Device -
Port Control Protocol Interworking Function (IGD-PCP IWF)"
* RFC 7291 "DHCP Options for the Port Control Protocol (PCP)"
* RFC 7225 "Discovering NAT64 IPv6 Prefixes Using the Port Control
Protocol (PCP)"
* RFC 2663 "IP Network Address Translator (NAT) Terminology and
Considerations" See address binding and e.g. RSIP, RSA-IP, RSAP-IP in
Section 5
* RFC 3022 "Traditional NAT" Section 5.3 says your border router may
allow some hosts to use public IPs and may (without mentioning how)
advertise information (like the public IP) from the public link to them.
* [RFC 5597 "NAT DCCP Requirements" Section 1: "Also, a separate,
unspecified mechanism may be needed, such as Unilateral Self Address
Fixing (UNSAF) [RFC3424] protocols, if an endpoint needs to learn its
own external NAT mappings."]
* RFC 3424 "IAB Considerations for UNilateral Self-Address Fixing
(UNSAF) Across Network Address Translation"
* RFC 2766 "Network Address Translation - Protocol Translation (NAT-PT)"
* RFC 2765 "Stateless IP/ICMP Translation Algorithm (SIIT)" can be
parsed out of the statelessly translated IPv6 address interestingly that
RFC also mentions "Determine when (...) needs to be allocated and then
allocation needs to be refreshed/renewed" but it doesn't mention how to
do this.
* MIPv6 RFC 3519, RFC 5944, ...: But doesn't specify how the
implementation looks like, just that it is needed. "In the presence of
NATs, an improved solution would require the ability to discover the
translations done by each NAT along the route"
* RFC 3027 "Protocol Complications with NAT" Section 2.3, and 5
* draft-ermagan-lisp-nat-traversal-20 "NAT traversal for LISP" also
specifies a way to discover the public IP
* Host_Identity_Protocol RFC 9028 and RFC 5207 Section 4
* RFC 8445, RFC 8489, RFC 5245, RFC 8656, RFC 5128,
draft-rosenberg-mmusic-ice-nonsip-01 aka. ICE, STUN, TURN, WebRTC, SIP, ...
* RFC 5853 "Requirements from Session Initiation Protocol (SIP) Session
Border Control (SBC) Deployments" Section-3.4.2
* RFC 2205 "Resource ReSerVation Protocol (RSVP)" + RFC 6780 "RSVP
ASSOCIATION Object Extensions"
* RFC 7599, RFC 7598, RFC 6145 "MAP-T"
* RFC 7597, RFC 7598, RFC 2473 "MAP-E"
* RFC 6346 "The Address plus Port (A+P) Approach to the IPv4 Address
Shortage"
* RFC 7600 "IPv4 Residual Deployment via IPv6 - A Stateless Solution
(4rd)" by reversing the address mapping or if the CE supports it using
one of the other approaches.
* TR-069 CWMP (WAN/ISP side)
* TR-064 LAN side
* "curl -4 https://ifconfig.co"
But if you're asking for advice on how to handle this I'd say:
1. Try to go IPv6-first and/or IPv6-mostly, just way less headach and
better performance.
2. Where not possible either go the kinda radical way and use tor or i2p
as an overlay and have them deal with nat traversal or if that is
undesirable use something like libp2p or a webrtc library.
3. If all of that doesn't work try to connect to and proxy through a
TURN server.
4. If that also doesn't work try to connect to a HTTP(S) proxy that
supports HTTP-CONNECT tunnel
5. (no experience so far, but is newer and could work in some
environments) the *-over-QUIC RFCs (RFC 9250, RFC 9221, RFC 9000, RFC
9220, RFC 9484, RFC 9298, RFC 9297, and ongoing drafts:
https://datatracker.ietf.org/wg/masque/documents/)
Tbh I personally when neither going IPv6-only or working around the v4
NAT with e.g. a VPN isn't an option would just use tor, i2p, libp2p, or
Yggdrasil as my overlay and let them deal with the hard parts. Basically
I'd use e.g. the Tor Projects Arti project as my transport layer
https://gitlab.torproject.org/tpo/core/arti Tor and i2p have the added
benefit of being fully End-to-End encrypted and the endpoint addresses
being unambiguous and cryptographically ensured.
Also just a note if you're leaving the SOHO and SMB environments and
also having to deal with enterprise networks then you basically don't
have any way to autodetect this as there are ofte multiple (literally
countless) nats to different public IPs depending on destination,
protocol, or even network saturation. You basically have to let the
admin/user provide one manually.
(And side note, I also have already used it to link stuff together
without a centralized public server)
Sincerely,
Klaus Frank
On 2025-04-13 10:51:29, Jon wrote:
> Maybe by interfacing with the router?
>
> You can somehow send some kind of query to the router using router protocols, and it’ll process a return packet with the wan ip address I think, per wan ip address attached to the router
>
> Or you can flat out make a standard for all routers to adhere to when returning wan ip addresses, along with others stuff like live latency checks or some kind of network security module
>
> Or someone awesome can implement some kind of protocol or handshake method for linux router distributions to return the wan ip address directly from the linux router
>
> I think my packet thing will work
>
> You can send a packet through the lan network, and it should return the wan ip address, I think, just through multiple layers or something
Powered by blists - more mailing lists