Ive been doing some research on how to pull this off, and come to find no solutions anywhere online. Winsock alone will only retrieve your local ip address and not your external ip address. Other solutions and recommendations were to rely on 3rd party websites such as whatismyip.com. Scripting was another way. And also found that it is possible to do in C++ but is very difficult and you would need to create your own function. Even though this has been mentioned, the solutions were not presented at all. And what would really suck is if i were to rely on assembly code. Could anyone point me in the right direction on the steps needed to pull this off without resorting to 3rd party websites? Thanks in advance

You would need to rely on something like UPnP, which _might_ work in many scenarios. Even external websites can fail in certain cases, the best way is to just not rely on having the external ip. What do you need it for anyway?

To give clients on external machines the public ip address of my server to connect to.

You'll hit a roadblock because there's no universal solution that will always work.

When the computer is directly connected to the internet (i.e. Dial Up modems, broadband USB modems, Ethernet in bridged mode); the winsock option is what you need to get the IP address; since the OS knows the external IP address.

When the computer is behind a NAT (i.e. Ethernet or wifi in most router configurations); the OS only knows the local IP address because THAT's the computer's IP address.

What you would like to know is the router's IP. You could ask the router's for its address (i.e. UPnP), but the router could refuse to tell it, or lie. Furthermore, if the router is behind another router.

You would have to ask the second router its IP address, that is, assuming you somehow learnt that there are 2 routers in the configuration (may be because router 1 told you, or analyzing packets streams, or through UPnP assuming it actually works).

And router 2 could be behind another NAT, router 3...

You could also try UDP punch through which exploits a loop hole in NAT implementations that would let you directly communicate with external clients. But it doesn't work with all routers (it's a hack!)

That's why an external website is often the best bet. The external website will only see the IP address of the last router in the chain and report that address to the client. Even that can fail because, if the user is behind a proxy, the external website will see the proxy's IP.

You can't do anythong on the local client machine to make this robust. The closest you can come would be to attempt to discover/configure a gateway that uses UPnP. Different platforms have somewhat different libraries/support for that -- there's no single API like for UNIX sockets / WinSock.
However, UPnP is only a half-solution, because very often, it doesn't work. The real solution is one of the following:

1) Tell users to set up port forwarding on their gateways/firewalls.
2) Use an external NAT introducer/match-making server.

Or you could wait for 100% IPv6 adoption. (don't hold your breath)

IPv6 doesn't have NAT.....however I have heard rumors of SOHO routers with NAT for IPv6 even though the IPv6 working group forbids it.

One of the goals of IPv6 was to bring back old school end-to-end connectivity just like how it was in the 90's.

IPv6 doesn't have NAT

You *can* do NAT in IPv6, just like IPv4. It's just that, from a network address allocation point of view, you're not supposed to have to do it.

One of the goals of IPv6 was to bring back old school end-to-end connectivity just like how it was in the 90's.

There are many good reasons to want to do NAT (or DNAT, server side) that have nothing to do with address allocation.