Live data from Hacker News

Fun with IP address parsing

blog.dave.tf

121–130 of 150 posts

Re: Fun with IP address parsing

#121

What is the use-case of a decimal representation of a v6 address or a 32-bit int representation of an ipv4 address? I’ve never had someone tell me, “see if you can ping 143267841”. I’ve worked in networking for coming up on 30 years now and just haven’t found the use.

IPC at least. If you want to pass an IP address (whose natural native representation is a uint32) from program to program as text, having to format it as dotted decimal would be just unnecessary and inconvenient.

Re: Fun with IP address parsing

#122
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.

The real question who is using inet_aton(3). I'm betting none of the online converters.

Re: Fun with IP address parsing

#123
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'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

people doing lan-partys around 1995 called ...

just kidding, great you discovered it

Re: Fun with IP address parsing

#124
post #89

Earlier 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…

What are the practical reasons we should rearchitect our systems to remove NAT? (I know the weaknesses of NAT but the cat’s out of the bag at this point...the question isn’t really “why should we use NAT”, it’s “why should we go through the pain of breaking it”.)

IPv6 does nothing to break NAT, you could deploy the exact same kind of NAT and it would have the exact same behaviour, if you really want to make your router use a bunch more memory/CPU and make it a pain for users to do anything that needs a direct connection. But you gain nothing from doing that.

Re: Fun with IP address parsing

#125
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.

Would you be further humbled if the ipad accepted http://CXXVII.I also?

I'm never writing anything that positively accepts 127.1, or 0127.000.000.0001 as a valid address no matter what garbage implementations do.

The issue we have with this are situations when we have to accept only inputs that are domain names which are sure not to be treated as an IP address by some software downstream of us.

Re: Fun with IP address parsing

#126
post #81

> It does not process Class A/B notation, or hex or octal notation. I got to find that notation useful once , to make a shorter one-liner... without even knowing that there were different classes of IPv4 address, and that I was looking at one of them. It's a tiny function that gives me the IP address of my machine in the LAN, for either Linux and Mac: # Get main local IP address from the default external route (Inter…

Oh no, that's another shorthand that's different from all the others. A single number should be interpreted as a big-endian uint32, and so "1" should be "0.0.0.1". However, I can confirm that `ip` interprets it as "1.0.0.0", even though you should have to write "1.0" for that. Ugh.

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' is actually doing it right!

Re: Fun with IP address parsing

#127

Earlier 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…

> 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).

Re: Fun with IP address parsing

#129

Earlier quoted context omitted.

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

> 4 ints or worse, using a string

Or worse, in one case I've had to deal with both (plus another surprise twist):

    public class IP {
        byte[] value 
        // if true value is a variable-length ASCII dotted octet,
        // if false it is length 4 - with LSB in value[0].
        bool isString
    }

Re: Fun with IP address parsing

#130
post #126

Earlier quoted context omitted.

Oh no, that's another shorthand that's different from all the others. A single number should be interpreted as a big-endian uint32, and so "1" should be "0.0.0.1". However, I can confirm that `ip` interprets it as "1.0.0.0", even though you should have to write "1.0" for that. Ugh.

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://git.kernel.org/pub/scm/network/iproute2/iproute2.git... )

Post reply on HN