Fun with IP address parsing
131–140 of 150 posts
Re: Fun with IP address parsing
#132Earlier quoted context omitted.
Well I did think of that, it technically is not a Class-A because it should have 2 parts. My conclusion was that maybe what happens is that "1", while incorrect, is flexibly parsed as "1.0" and thus it would become "1.0.0.0". But you're right that, given the uint32 representation does exist, the most correct thing to do seems to interpret it as "0.0.0.1"... unless an exception to the rule exists somewhere, and 'ip' i…
I was curious as well, turns out they're using a non-standard parsing with a comment in the function explaining why: /* This uses a non-standard parsing (ie not inet_aton, or inet_pton) * because of legacy choice to parse 10.8 as 10.8.0.0 not 10.0.0.8 */ src: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git... (the entry point to start tracing down to the above inner function is right around here: https:/…
Re: Fun with IP address parsing
#133There clearly should be a common library to take care of these things, which are way too complex for most of developers.
Re: Fun with IP address parsing
#134Earlier quoted context omitted.
I was curious as well, turns out they're using a non-standard parsing with a comment in the function explaining why: /* This uses a non-standard parsing (ie not inet_aton, or inet_pton) * because of legacy choice to parse 10.8 as 10.8.0.0 not 10.0.0.8 */ src: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git... (the entry point to start tracing down to the above inner function is right around here: https:/…
Conclusion: explicit is better than implicit, and what's more, in this case the implicit alternative was depending on a non-standard choice made in the specific tool for obscure, legacy reasons.
Re: Fun with IP address parsing
#135Earlier quoted context omitted.
NAT was meant to work around IP exhaustion issues, not act as a security layer. By accident, it often happens to provide some additional security. By keep in mind those "internal" IP addresses may be routable in some cases, due to either accidental or deliberate mis-configuration. IPv6, with end-to-end connectivity, is how the Internet is supposed to work. It's how it did work in the early 90's, even with IPv4. If yo…
It's nice that this is how the internet is "supposed to work". In practice not having a NAT makes "automatic" internal protection of web services hard to impossible. > If you want to secure your servers, use a firewall. Maybe it's a host-based firewall. Firewalls do not solve this problem because a you do want service to service communication. What you do not want is code that crawls to user supplied URLs to access y…
Re: Fun with IP address parsing
#136Re: Fun with IP address parsing
#137Earlier quoted context omitted.
This is one of the reasons why I appreciate the geekiness of Cloudflare with their DNS service IP addresses, particularly: 1.1 which to me is the shortest useful IP address I am aware of.
0 connects to localhost. It's shorter.
Re: Fun with IP address parsing
#138Earlier quoted context omitted.
This is one of the reasons why I appreciate the geekiness of Cloudflare with their DNS service IP addresses, particularly: 1.1 which to me is the shortest useful IP address I am aware of.
0 connects to localhost. It's shorter.
1: https://unix.stackexchange.com/questions/99336/how-does-ping...
Re: Fun with IP address parsing
#139I'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
Re: Fun with IP address parsing
#140Earlier quoted context omitted.
> IPv6, ..., is how the Internet is supposed to work No, the way the Internet is supposed to work is that you have one routable address space. If you need to expand it, the previous address space is imported as a subset of the new one. https://cr.yp.to/djbdns/ipv6mess.html I will never forgive the IPv6 for not making the 32-bit IPv4 space a subrange of the 128-bit IPv6 space. Years after winning the IPng wars they ad…
Mandating that every router has to do stateful connection tracking would have been an enormous, wasteful burden. NAT64 is there for those who need it; 464XLAT setups with IPv6-only clients are quietly the reality on networks that don't have too much legacy infrastructure (mostly mobile).
Not requiring backwards compatibility in IPv6 guaranteed that IPv4 would be around forever. IPv4 is never, ever going away because of this.
The only people who couldn't see this coming were from Bell System backgrounds where you could use centralized schemes like "Ma Bell says tomorrow is the Flag Day, flip the switch". In a decentralized system people don't stop using the old system until you give them a new system that is backwards compatible. Then you drop the backwards compatibility in a second, separate upgrade much later, on a timetable dictated by adoption, not flag days.