my fastest way to confirm I have access to the internet (ignoring dns)
Try 127.0.0.2 it's your 2nd home, up to 255. These adresses can be useful to get around certain localhost checks, to avoid looping, etc. - like RDP/VNC
Not all of us can afford two homes much less 1. I rent
TIL. Using this from now on.
for those of you playing at home ping 134744072
hits google dns
Ah yes, a forbidden shortcut
Okay, now tell me what is the shorter domain you use to ping?
Holly molly, I wasted millions of keystrokes with 1.1.1.1.
Let me "impress" you even more:
ping 127.0.0.1
ping 127.1
ping 127.0.1
ping 0x7f000001
ping 2130706433
ping 017700000001
It's all the same. (And always was.)
Edit: added base8
This feels wrong... IPv6, fine, go ahead, but with IPv4... not so much.
Also this:
is some form of warcrime.
oh so 0x7f000001 is a war crime but you're fine with 2130706433 ?!?!?!?
yes officer, this maniac right here.
Why, I think I will use 2130706433 from now on, just to confuse the interns.
0118, 999, 881, 999, 119, 725...3.
Exactly. And now I feel compelled to explain why to the people who don't actually know any language more bare-metal than Java. Your computer has to convert the decimal octets to binary chunks anyway to process the input, and hex is really just a more concise way to represent binary. It's actually surprisingly legible still.
d0 127 0 0 1
0x 7f 00 00 01
But that horrific decimal string is doing a bastardized encoding of those hex chunks into a new base ten number, completely obscuring and defeating the purpose of the clean four octets. It's a total novelty, and course it needs to work for your operating system to run, but actually taking advantage of it for anything legitimate, requiring any amount of manipulation, say, attempting base ten math to determine a subnet mask, enters a realm of psychosis I dare not tread.
I personally find
ping 2130706666
easier to remember. I can type it from memory and it always gets a reaction.Call me a madman but I actually like the hex style better
What about mixing a few together?
Mixing it is fairly cursed.
You can do it shorter as well:
ping 0x7f.1
ping 0x7f.0x1
I agree with the other guy, 0x7f-1 isn't even a pain to remember, it's 8 characters after x, so fill the dash with enough 0s
And it actually makes sense, you just need to learn hexadecimal, using decimal is the insane one
There's nothing impressive about this, it's just an int.
The only thing weird here is 127.1 expanding to 127.0.0.1 instead of 0.0.127.1 or at least 127.1.0.0
Makes sense to me. First and last octet shouldn't be 0, missing octets assumed to be 0 and expanded
ipv6 is the same I think, where you can do :: and anything in between that is just zeroed out and whatever you have in front and behind is kept.
And unlike ipv4, it's actually pretty nice since the addresses are horribly long.
There is no issue with the last octet to be 0 when it’s not the first IP in a subnet. F.e. 10.1.0.0 is valid address in 10.0.0.0/8. ipcalc may be useful
Neat. Thanks for the knowledge.
That's not correct. It works because each component is interpreted from left to right, and the size of all components is 32 bits big-endian encoded:
[8].[8].[8].[8]
[8].[8].[16]
[8].[24]
[32]
In the case of 127.1, 127 is parsed as an 8-bit integer, and 1 is parsed as a 24-bit big endian integer: 00 00 01, which fills the middle octets with 0.
Technically, in this format, you could have "127.300" which would parse out to 127.0.1.44. This is likely going to be unsupported in a lot of software, though, and another comment mentioned such a case.
The shorthand format entirely is deprecated due to such ambiguity. You can support it, but you shouldn't expect it to be supported.
I'm pretty sure "127.300" is supported by all Hollywood networks. Just make sure there isn't someone at 127.300.23.562 hacking you back, or you might be fighting firewalls all night!
Neat
you specify the first
and lastbyte and the remainderWhat's more interesting is that ping accepts little endian values and dotnet stores IP in big endian
Because network byte order is big endian.
No, you don't specify the first and last byte.
You specify the first octet and the remainder. In
a.b
style IP addresses,b
can be up to 3 bytes:127.1000
is still a valid loopback IP address.you're correct, you could do
ping 1.16777215
Note that 127.1000 should work fine with ping, but it is still a distinct address from 127.0.0.1. So if you listen on 127.0.0.1 port 443, and then go to https://127.1000/ in your browser, it won't work. This is occasionally useful as you can easily set up multiple hosts file entries that all point to localhost, but on different IPs so you can easily test different services.
Because network byte order.
It expands to 127 0x7f000000 + 0x00000001, 127.1.1 will be 127.1.0.1 :)
just because it’s an int doesn’t mean the software will or should read it in decimal, hex and oct., and nobody expects it to because thats not the standard way of writing ipv4.
I didn't know this, and often have to work with the integer/hexadecimal representation of IP adresses and often convert between the 2. This could save me a lot of time.
Came for the memes, learned something new.
you want to be impressed? How about
ping 127.1000
?Ain't working. Darwin/linux resolves to 127.0.3.232, OpenBSD -- does not resolve at all, Plan9 resolves to 127.0.0.232.
Then your system is non-compliant, 127.0.0.0/24 should all be loopback addresses.
First, so you know, loopback is actually 128/8. Second, read what I wrote. Your example expoits UB (undefined behavior) and it is different on different systems.
Aha yes, I wrote it the wrong way around. Yes, I meant 127/8, which means
127.0.0.3.232
is a loopback address - which means if it doesn't resolve on your system, your system is wrong. (see RFC 5735)And yes, it appears the "dot-decimal" notation is ill-defined - but the result is that the interpretation of
127.0.0.1
also doesn't follow any standards, neither does127.1
or127.1000
.But linux does define it: https://linux.die.net/man/3/inet_ntoa
And it also works on windows, and all webbrowsers AFAIK.
So again - your system seems to be deliberately non-compliant and hiding behind "well, there is no real standard".
I didn't say, it ain't ping loopback. I said it resolves differently. Going beyond uint8 for a tuple is UB and "well, there is no real standard" is a totally valid statement.
Edit: https://www.rfc-editor.org/rfc/rfc3779
prefix - a bit string that consists of some number of initial bits of an address, written as an address followed by a "/", and the number of initial bits. 10.5.0.0/16 and 2001:0:200:3:0:0:0:0/64 (or 2001:0:200:3::/64) are examples of prefixes. A prefix is often abbreviated by omitting the less-significant zero fields, but there should be enough fields to contain the indicated number of initial bits. 10.5/16 and 2001:0:200:3/64 are examples of abbreviated prefixes.
So… not saying you are wrong, but you are wrong.
The short-hand format comes from BSD libc, which allowed any 32-bit value, including
127.1000
which is equivalent to127.0.3.232
, as the second component is parsed as a 24 bit big endian integer. RFC 3986 deprecated the entire shorthand format and required all 4 components in dotted-decimal notation.If software aims to support the short-hand format, 127.1000 and such values should be supported as well, since it's literally what gives that format meaning.
That section you quoted has no relation to what I am arguing? That is very clearly talking about prefixes, not about addresses.
If you were correct, then
127.1
would resolve to127.1.0.0
as described in that quote, which we both know to not happen on any system.If you want to smugly correct someone, at least make sure what you are saying is true.
And I have no problem with calling you a moron for not being able to read simple text correctly. You seem to have some reservation to calling people out for BS?
I wasn't expecting all of these to also work in FireFox, I'm definitely going to be using 127.1 as a shorthand from now on for web development.
127.127.127.127
127.1.2.7
Can I use these in a browser?
Edit: lol, I can if I specify protocol manually