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

61–70 of 150 posts

Re: Fun with IP address parsing

#61

Post by proactivesvcs »

dave_universetf wrote: post #60
proactivesvcs wrote: post #24

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

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

Thank you for the clarification, it does sound like you've done more background research than the linked blog entry may explain. Was this the result of simply reading the RFCs or did you come across other resources that expand on the obsolete IP address representations?

Re: Fun with IP address parsing

#62

Post by proactivesvcs »

mirthflat83 wrote: post #50
proactivesvcs wrote: post #24

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

He’s joking with that word choice.

Yes. I do understand the modern-day usage of the word "cursed" in this context :-)

Re: Fun with IP address parsing

#64

Post by chrismorgan »

ben0x539 wrote: post #27
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.

I use mtr 1.1 all the time. (Like, literally all the time, I normally have it running in the background so I can see whether it’s my computer’s wi-fi adapter, the wi-fi router or the local ISP that’s playing up this time.)

I remember it was a few days after they came out with 1.1.1.1 and 1.0.0.1 that it dawned on my that I could drop the zeroes. I’d been wondering why they hadn’t chosen 1.2.3.4, but once I realised 1.0.0.1 was just 1.1, it became fairly obvious why they had chosen it.

(P.S. mtr’s stripchart with latency information is super great for this sort of thing; I have MTR_OPTIONS=--displaymode=2 set in my environment.)

Re: Fun with IP address parsing

#65

Post by dave_universetf »

skissane wrote: post #44
phoe-krk wrote: post #9

> Fully canonically, :: is 0000:0000:0000:000:0000:0000:0000:0000. Nitpick: missed a single zero in the middle there.

The following comment "My apologies to trypophobic readers" makes me think that the mistake was intentional.

It wasn't, but I'm glad to have plausible deniability :) I fixed the typo.

Re: Fun with IP address parsing

#67

Post by skeletonjelly »

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:

https://www.digitalocean.com/community/tutorials/understandi...

Which details my understanding, classes refer to the ranges, not so much grouping the latter part

Happy to be corrected!

Re: Fun with IP address parsing

#68

Post by voxic11 »

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.

Re: Fun with IP address parsing

#69

Post by IgorPartola »

thwarted wrote: post #30
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.

I definitely frequently used this in code I had written and ran. It is very nice to not have to worry about both stacks and IPv6 is the future anyways. It’s nice to make this configurable for your daemons but I think the default should be true. And also this allows you to not have two separate bind address config lines and all the confusion that comes with that.

Re: Fun with IP address parsing

#70

Post by alasdair_ »

tomcooks wrote: post #8

Boomers like me know all of the IPv4 obfuscation techniques thanks to Fravia' Searchlores, may he forever rest in peace. https://www.theoryforce.com/fravia/searchlores/obscure

Not a boomer but still saddened every time I remember +Fravia is dead. I remember checking his site every day for most of 1995 and 1996.
Post reply on HN