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

111–120 of 150 posts

Re: Fun with IP address parsing

#111

Post by growse »

octoberfranklin wrote: post #110
growse wrote: post #105

Earlier quoted context omitted.

Maybe I'm misunderstanding you, but one of the points of the article in that you can represent IPv4 addresses in IPv6. In other words, IPv4 is a subset of IPv6. If I'm on an ipv6-only host and blast UDP at ::ffff:1.2.3.4, they should get delivered to 1.2.3.4, no? The actual, real-world problem with 4 being a subrange of 6 is that 4-only hosts are blissfully unaware that the super-range exists, so have no mechanism to…

> If I'm on an ipv6-only host and blast UDP at ::ffff:1.2.3.4, they should get delivered to 1.2.3.4, no? No, it won't necessarily! That's precisely the problem. Until NAT64 was introduced it was in fact impossible for an IPv6 router to deliver your packet to the IPv4 host 1.2.3.4. NAT64 still isn't mandatory (and likely never will be), so if you're writing software you can't assume those packets will get through even…

Ah! T see what you mean. Thanks for clarifying and correcting me.

I possibly have some sympathy with the anti-NAT view taken at the time, even if it ended up being the wrong thing to do it hindsight. Adding more mandatory complexity to implementors would have harmed adoption rates, and I've seen some weird edge cases with NAT64 - it's not necessarily a trivial thing to implement correctly.

Re: Fun with IP address parsing

#112

Post by octoberfranklin »

growse wrote: post #111
octoberfranklin wrote: post #110

Earlier quoted context omitted.

> If I'm on an ipv6-only host and blast UDP at ::ffff:1.2.3.4, they should get delivered to 1.2.3.4, no? No, it won't necessarily! That's precisely the problem. Until NAT64 was introduced it was in fact impossible for an IPv6 router to deliver your packet to the IPv4 host 1.2.3.4. NAT64 still isn't mandatory (and likely never will be), so if you're writing software you can't assume those packets will get through even…

Ah! T see what you mean. Thanks for clarifying and correcting me. I possibly have some sympathy with the anti-NAT view taken at the time, even if it ended up being the wrong thing to do it hindsight. Adding more mandatory complexity to implementors would have harmed adoption rates, and I've seen some weird edge cases with NAT64 - it's not necessarily a trivial thing to implement correctly.

Yes, but having two entirely separate internets, like we do today, is much more complex than any amount of NATting!

I fault the IPv6 proponents for not forseeing our current situation. DJB saw it with crystal clarity in 2001. Lots of people warned them that this would happen.

Re: Fun with IP address parsing

#113

Post by the_mitsuhiko »

icedchai wrote: post #87
the_mitsuhiko wrote: post #52

Earlier quoted context omitted.

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.

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 your internal services. Do you need application level protections. With IPv6 you're basically forced to declare your CIDR explicitly whereas with IPv4 you could easily achieve a secure by default system.

Re: Fun with IP address parsing

#114

Post by m463 »

An "fun" use of ip addresses is in NTP.

in the ntp config file, you will have stuff like this:

  server 127.127.1.0 # local clock
or:

  server 127.127.20.0 minpoll 4 iburst prefer  # gps clock
where the "ip address" is of the form: 127.127..

here's a page explaining the clock types:

https://www.eecis.udel.edu/~mills/ntp/html/refclock.html

but basically it's a weird anachronism. I'm not sure if NTP will actually bind to those addresses using the tcp/ip stack, or if it someone just got lazy and coopted the ip address parser for off-label use.

Re: Fun with IP address parsing

#115

Post by GlitchMr »

geoffpado wrote: post #46

> This is the same IP address: 3232271615. You get that by interpreting the 4 bytes of the IP address as a big-endian unsigned 32-bit integer, and print that. This leads to a classic parlor trick: if you try to visit http://3232271615 , Chrome will load http://192.168.140.255 . This was the source of one of my favorite “bugs” ever. I was working on multiple mobile apps for a company, and they had a deep link setup th…

Curiously, this appears to be a bug in Windows Phone. In URIs, part following `//` is called authority, which is essentially a host with some optional additional stuff (like port number).

According to RFC 1123, hostname could legally be entirely numeric, and web browser shouldn't attempt to "correct" it (as it is a valid URI) for schemas it doesn't know anything about - as it doesn't know the rules for hostname for a given protocol. This is also not a valid IP address according to RFC 3986 (which specifies URI syntax), as this specification requires #.#.#.# format with three dots.

That said, using authority for something that isn't technically a hostname is misusing the field. I think using `:` would have been a better idea.

Re: Fun with IP address parsing

#116

Post by friend-monoid »

octoberfranklin wrote: post #90

How about the PGP word list? https://en.wikipedia.org/wiki/PGP_word_list $ ping stairway scavenger tracker upcoming PING 209.216.230.240 (209.216.230.240) 56(84) bytes of data. 64 bytes from 209.216.230.240: icmp_seq=1 ttl=50 time=68.2 ms 64 bytes from 209.216.230.240: icmp_seq=2 ttl=50 time=69.5 ms 64 bytes from 209.216.230.240: icmp_seq=3 ttl=50 time=67.2 ms

This is neat but Im so disappointed by the chosen word list

Re: Fun with IP address parsing

#117

Post by tomcooks »

alasdair_ wrote: post #70
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.

Same here, pity that many things I've learned through that jewel of a site have been rendered useless by the same very constant updates Fravia himself warned us against.

Re: Fun with IP address parsing

#118

Post by knorker »

FreshFries wrote: post #101
lrossi wrote: 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.

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

#119

Post by whereistimbo »

geoffpado wrote: post #46

> This is the same IP address: 3232271615. You get that by interpreting the 4 bytes of the IP address as a big-endian unsigned 32-bit integer, and print that. This leads to a classic parlor trick: if you try to visit http://3232271615 , Chrome will load http://192.168.140.255 . This was the source of one of my favorite “bugs” ever. I was working on multiple mobile apps for a company, and they had a deep link setup th…

Well I read how foobar2000 dev (Peter) developed his apps on Windows Phone. He said it was so annoying compared to other two major mobile platform and he was considering to refund the crowdsourced money which comes from pledging Windows Phone.

Re: Fun with IP address parsing

#120

Post by Sharlin »

SoSoRoCoCo wrote: post #63

> a big-endian unsigned 32-bit integer This is how embedded stacks (LWiP) store IPv4. Didnt' know browsers could respond to it thought. Mixing IPv4 and IPv6 is just evil.

It’s how any reasonable software represents IPv4 addresses. Dotted decimal is only for human convenience (and honestly, I’d argue that 0xDEADBEEF would be just as convenient, after all people turned out to handle HTML/CSS hex colors just fine!)
Post reply on HN