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

21–30 of 150 posts

Re: Fun with IP address parsing

#21

Post by jeffbee »

kortilla wrote: post #11

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.

There is no use case. It's a meaningless outcome of the fact that `strtoul` is involved somewhere.

Re: Fun with IP address parsing

#22

Post by strenholme »

Since I write a Lua-parsed DNS server which works with IPv6, even when compiled for an ancient version of MINGW on Windows XP (which has IPv6 support but no built-in IPv6 parser), I had to write an IPv6 address parser (no inet_pton(), which is what most programs use for IPv6 parsing, on that system).

No, I did not add dotted quad notation to the parser. No, you can not have more than four hex digits in a single quad; 00000001:2::3 is a syntax error. It supports “normal” stuff like ::, ::1, 2001:db8::1, and even non-normal stuff like “2001-0db8-1234-5678 0000-0000-0000-0005” (to be compatible with the really basic IPv6 parser I put in MaraDNS’s recursive resolver nearly two years ago), but does not support any of the IPv6 corner cases in the linked article.

The IPv6 test cases in the automated test for the parser are at: https://github.com/samboy/MaraDNS/blob/master/deadwood-githu... (The final three lines are supposed to return errors)

Re: Fun with IP address parsing

#23

Post by proactivesvcs »

arkadiyt wrote: post #17

These different representations also lead to frequent server side request forgery (SSRF) bypasses - someone might be blocking local IPv4 but you can still access their AWS metadata endpoint at ::ffff:169.254.169.254, etc. For anyone using Ruby, I'm the author of a gem [1] that comprehensively protects against SSRF bugs. For anyone using Golang I recommend this [2] blog post. [1]: https://github.com/arkadiyt/ssrf_filt…

I wonder how many of these bugs are the result of people thinking "Well I've read the spec but most of it is 'cursed' so I'll just implement this subset which fits my idea of 'acceptable'".

Re: Fun with IP address parsing

#24

Post by proactivesvcs »

I'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".

Re: Fun with IP address parsing

#26

Post by capitainenemo »

jancsika wrote: post #10

Where are the weirdo IPv4 forms used in practice?

I don't know if it counts as in practice, but I use the notation he chose not to parse quite a lot on internal networks.. ssh 10.0.0.123 is already a nice quick address to type out, but ssh 10.123 or ping 10.123 is even quicker. Works in all kinds of random things. Web browsers of course, but games work just fine too usually, if they hand it off to the system to look up.

Re: Fun with IP address parsing

#27

Post by ben0x539 »

jancsika wrote: post #10

Where are the weirdo IPv4 forms used in practice?

I write 127.1 all the time when I'm too lazy to type 127.0.0.1. Then I'm sad when it doesn't work because the nearest ip address parser wasn't written in the previous millennium.

Oh, yeah, and 1.1 is the only DNS server address I memorized.

Re: Fun with IP address parsing

#28

Post by morelisp »

augusto-moura wrote: post #13
kortilla wrote: post #11

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.

Serialization for non human readable code. Usually IPv4 addresses are stored as int32 in databases or memory

Perhaps rather "ideally" than "usually." I have worked on several codebases that wasted gigabytes of memory / traffic on this.

Re: Fun with IP address parsing

#29

Post by the_mitsuhiko »

arkadiyt wrote: post #17

These different representations also lead to frequent server side request forgery (SSRF) bypasses - someone might be blocking local IPv4 but you can still access their AWS metadata endpoint at ::ffff:169.254.169.254, etc. For anyone using Ruby, I'm the author of a gem [1] that comprehensively protects against SSRF bugs. For anyone using Golang I recommend this [2] blog post. [1]: https://github.com/arkadiyt/ssrf_filt…

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.

Re: Fun with IP address parsing

#30

Post by thwarted »

chungy wrote: post #19

> I’m on the fence about that last one, the “IPv6 with an embedded dotted decimal” form. My reference parser (Go’s net.ParseIP) understands it, but it’s not really that useful any more in the real world. At the dawn of IPv6, the idea was that you could upgrade an address to IPv6 by prepending a pair of colons, as in ::1.2.3.4, but modern transition mechanisms no longer offer anything as clear-cut as this, so the nota…

> It turns out that programs can bind their listen address to just ::, and the kernel will still allow connections from IPv4, with the address mapped to ::ffff:0.0.0.0/32 -- outbound connections use the same notation.

This is only true if the sysctl bindv6only or socket option IPV6_V6ONLY is 0, and is defined by RFC3493.

Post reply on HN