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
Fun with IP address parsing
51–60 of 150 posts
Re: Fun with IP address parsing
#52Earlier quoted context omitted.
Unfortunately the blacklisting approach that works on IPv4 is completely broken for IPv6 since you can't really know where your own services are. I still did not find a good generic way to protect IPv6 and ended up just disallowing it so far everywhere.
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.
Re: Fun with IP address parsing
#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.
Re: Fun with IP address parsing
#54Where are the weirdo IPv4 forms used in practice?
I once used some of these weird notations to pack config data (mainly IP addresses) for remote installations into a product-key-like string that field techs could receive over the phone
Re: Fun with IP address parsing
#55Can 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.
Re: Fun with IP address parsing
#56> So, it’s a de-facto standard that boils down to mostly “what did 4.2BSD understand?“
By the way 4.2BSD was being compatible with older or contemporary implementations, like ITS which was running TCP before any Unix was.
For example plenty of machines back then used octal as a preferred human representation. In fact that’s why octal is the default format of numeric constants in C: C, like Unix, was initially developed for an 18-bit (six octal digits) PDP-7. The smaller 16-bit PDP-11 version came later.
Re: Fun with IP address parsing
#57Earlier quoted context omitted.
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"?
The way to handle security problems with corner cases is to just return a parse error if something unusual is seen. With security, the rule is to be conservative with what you accept; anything unusual should be rejected. In cases where backwards compatibility is needed, just use inet_pton() and let the libc maintainers deal with the bug reports (I believe inet_pton() dropped octal and hex support for ipv4 addresses)
> I believe inet_pton() dropped octal and hex support for ipv4 addresses
Correct.
It also doesn't support truncation unlike inet_aton. e.g. inet_aton considers "1.2.3" and "1.2.0.3" to be the same address.
Re: Fun with IP address parsing
#58I'm not convinced these are "cursed". They may be the result of bygone networking conventions, implementation ideas that never came to mainstream fruition, flexibility for use-cases etc. Just because we don't understand something that looks strange, doesn't mean it's cursed, nor that one can simply turn one's nose up and say "I don't understand why these exist so I'll just ignore them when I implement x".
Well, adding support for hex or octal IP addresses was a bit much with hindsight!
Re: Fun with IP address parsing
#59Earlier quoted context omitted.
Perhaps rather "ideally" than "usually." I have worked on several codebases that wasted gigabytes of memory / traffic on this.
Ugh. I would hate to see the code to enumerate a network, or calculate masks, or determine broadcast addresses without using unsigned ints.
I had, unfortunately. Bitwise operations are scary for some people, so they prefer working with 4 ints or worse, using a string
Re: Fun with IP address parsing
#60I'm not convinced these are "cursed". They may be the result of bygone networking conventions, implementation ideas that never came to mainstream fruition, flexibility for use-cases etc. Just because we don't understand something that looks strange, doesn't mean it's cursed, nor that one can simply turn one's nose up and say "I don't understand why these exist so I'll just ignore them when I implement x".
I can help here: these definitely aren't cursed, because curses aren't real. I was exagerating for comic effect, because this was just a twitter rant that got out of control :)
That said, many of those representations no longer make sense in the modern world, and I'm actively choosing to not support them. That doesn't mean I don't understand why they came about in the first place, au contraire! I'm explicitly deciding that their historical reason for existing no longer applies.