Re: Is there a way to know the ISP with the default installation of Stretch?
- Date: Wed, 3 Jan 2018 23:32:55 -0500
- From: Michael Stone <mstone@xxxxxxxxxx>
- Subject: Re: Is there a way to know the ISP with the default installation of Stretch?
On Wed, Jan 03, 2018 at 07:04:46PM -0600, David Wright wrote:
(In view of
do you mean public?)
No, it's a pretty common shorthand to say "routable" to mean "routable
on the public internet", especially where there's no real possibility of
confusing it with specifically non-routable blocks like 127.0.0.0/8.
Honestly, I considered it less likely to be confusing than calling them
RFC1918 addresses in this context.
As far as 169.254.0.0/16, it's defined as a link local range for address
autoconfiguration, but it can still be routed internally just as much as
the RFC1918 space can be. (Doing so just might not be a good idea,
because some devices might code in some assumptions or add a zeroconf
route by default. Which is annoying because the whole automatic zero
knowledge IPv4 autoconfiguration thing is just a spectacularly bad idea
anyway that typically causes far more trouble than it's worth. I guess
it was useful back in the days when someone might want to connect two
win98 machines together to copy a file without using a floppy disk but
couldn't think of a reason they might want to use the internet.) IPv6
has an entirely different (and more useful) concept of link local
addresses. Some of the other reserved ranges can also be internally
routed in practice, so trying to distinguish between "routable" and
"non routable" for some meaning other than "not routable on the public
internet" rapidly becomes a game of semantics and implementations.
But in that case, would https://www.whatismyip.com/ reveal an address
closer to the OP than whoever is providing *their* internet access?
(IOW does https://www.whatismyip.com/ ever yield a private address?)
No, it can't. It will show a public IP that connections from the web
client to connect to that particular web site, not a private IP. In the
case of a NAT environment there may be multiple different IPs in use, or
there may be different IPs for different routes, but there's no reliable
way to enumerate every possible IP you might be NATed to.
Back to the traceroute idea: it's fairly common for a residential
endpoint to have a publically routable IP (usually on the router or
"modem") but traceroute won't help identify that--instead, you'll see
the private IP that the modem uses to communicate with the machine
running traceroute. (In general, traceroute will only show one of many
IPs that a particular hop has.) So what you're getting from traceroute
isn't going to be the IP you use when communicating with web sites, it's
going to be the IP your router uses to communicate with you, then IPs
associated with other routers along the way (some of which may also be
using RFC1918 space, though it's more common these days for large
providers to just pass around encapsulated traffic in a way that's
opaque to traceroute, likely over IPv6). In theory another option for
finding the public-side gateway IP is UPnP IGD or PCP, but I wouldn't
expect those to work on any arbitrary network.