Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fun with IP address parsing

blog.dave.tf

Post reply on HN
Print view View original

71–80 of 150 posts

Re: Fun with IP address parsing

#71

Post by bnjms »

psim1 wrote: post #43
londons_explore wrote: post #41

Writing a parser and saying "I'm dropping support for all these old ways of doing things" seems like poor form. Unless there is a big reason, never drop backwards compatibility. In this case, supporting all those forms would be very do-able. The best way to support them would be to find some old BSD parsing code and port it, then you can be sure every corner case is handled the exact same way. Handling corner cases d…

There is a good reason: many of the unusual forms are unused except as tricks and exploits. The whole internet uses IPv4 classless routing. There is no value in keeping pre-CIDR forms. Graybeards might object because they have been typing "127.1" for forty years. It's merely an old habit. Who is to say how big a reason is required to "never drop backwards compatibility"?

Disagree. We want the four octet form to remain since it mirrors the four octet wildcard form which does not have an equivalent CIDR form.

Re: Fun with IP address parsing

#72

Post by nealabq »

abotsis wrote: post #48

Wow, this. One thing I didn’t see mentioned was “0”. You mentioned it, but it didn’t grok to something I know to work in some implementations: “ping 0” behaves like “ping 127.0.0.1”.

Maybe ping is treating 0 like 0.0.0.0 aka INADDR_ANY ( https://en.wikipedia.org/wiki/0.0.0.0 ). And interpreting it as all the IPv4 addrs mapped to the local machine (including localhost).

Re: Fun with IP address parsing

#73

Post by skeletonjelly »

voxic11 wrote: post #68
skeletonjelly wrote: post #67

I think they've got Class A/B/C wrong? Or at least they're using it in a way that I never learnt > The familiar 192.168.140.255 notation is technically the “Class C” notation. You can also write that address in “class B” notation as 192.168.36095, or in “Class A” notation as 192.11046143. What we’re doing is coalescing the final bytes of the address into either a 16-bit or a 24-bit integer field. According to this: h…

from the linked article > Traditionally, each of the regular classes (A-C) divided the networking and host portions of the address differently to accommodate different sized networks. Class A addresses used the remainder of the first octet to represent the network and the rest of the address to define hosts. This was good for defining a few networks with a lot of hosts each.

There you go, thanks! Should have properly read the article I linked. So it's been repurposed to be as OP's linked article states? Not so much ranges but the amount of bits in the netmask?

Re: Fun with IP address parsing

#74

Post by jackewiehose »

z3t4 wrote: post #51

I'm now going to change my LAN to use 10.0.0.1 instead of 192.168.0.1 so that I can just type 10.1 This will help not only when testing stuff on mobiles only to have to rewrite the whole adress again because you forgot http:// but also when telling the kids what IP to connect to when setting up LAN games. Or coworkers when telling them them some LAN/router IP. Time server is on 10.36

I like the idea and will do the same.

But we'll see how well that works... I just fed the first 4 google results for "ip address converter" with 10.1: Three converters gave an error message and one came up with 0.0.0.10.

Re: Fun with IP address parsing

#75

Post by sunsetMurk »

lrossi wrote: post #55

Can confirm that visiting http://127.1 on ipad indeed works and redirects to http://127.0.0.1 . This is very surprising and, at least for me, humbling. I think I will quote this article any time I see someone using regex to validate or parse IPs.

All my regex (are now) a lie

Re: Fun with IP address parsing

#76

Post by Dylan16807 »

the_mitsuhiko wrote: post #52
arkadiyt wrote: post #45

Earlier quoted context omitted.

IPv6 has internal ranges defined just like IPv4 does - anything in an internal range should be blocked, and anything in an external range is safe to pass through.

Since there is no NAT in an IPv6 deployment unsafe services you typically want to prevent access to look like non internal ranges. Whereas in your normal IPv4 deployment you might have your protected service on 192.168.4.111 with IPv6 it will just share the same prefix (potentially) as your host.

Isn't this what the fd/8 local addresses are for?

Re: Fun with IP address parsing

#77

Post by dfox »

skeletonjelly wrote: post #73
voxic11 wrote: post #68

Earlier quoted context omitted.

from the linked article > Traditionally, each of the regular classes (A-C) divided the networking and host portions of the address differently to accommodate different sized networks. Class A addresses used the remainder of the first octet to represent the network and the rest of the address to define hosts. This was good for defining a few networks with a lot of hosts each.

There you go, thanks! Should have properly read the article I linked. So it's been repurposed to be as OP's linked article states? Not so much ranges but the amount of bits in the netmask?

It is other way around: in the original class-ful internet the numerical range of first octet directly implied what is in CIDR called netmask length. The original IPv4 implementations probably did not even have concept of netmask and this was instead hardcoded. Implementing the routing decision as netmask is nice optimalization which then probably inspired the CIDR concept, because at sufficently high level the only thing you need for that to work is making the netmask (or at least the length) freely configurable.

Re: Fun with IP address parsing

#78

Post by jsrcout »

lucb1e wrote: post #53

"All possible notations of this IPv4 address" https://lucb1e.com/rp/php/funnip.php?link&ip=80.100.131.150 It was a surprising amount of work to figure out all the different formats an IP address can be shown in and convert a given IP into all those formats.

That's impressive. And somewhat scary :-)

Re: Fun with IP address parsing

#79

Post by daenney »

jpxw wrote: post #16

As Go’s net package IP parsing was mentioned, here’s a fun fact: under their API it is impossible to distinguish between an IPv4-mapped IPV6 address and the equivalent normal IPv4 address.

I find this to be a great feature. net.IPNet.Contains takes this into account, so you don’t have to worry about or deal with shenanigans like IPv4 mapped addresses. It makes implementing SSRF protection much easier.
Post reply on HN