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

141–150 of 150 posts

Re: Fun with IP address parsing

#141

Post by the_mitsuhiko »

icedchai wrote: post #135
the_mitsuhiko wrote: post #113

Earlier quoted context omitted.

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…

In these situations, store your IPv6 prefixes in a config. This doesn’t sound like a hard problem to solve.

Which is a manual process and because it is one it leaves many systems unprotected.

Re: Fun with IP address parsing

#142

Post by icedchai »

the_mitsuhiko wrote: post #141
icedchai wrote: post #135

Earlier quoted context omitted.

In these situations, store your IPv6 prefixes in a config. This doesn’t sound like a hard problem to solve.

Which is a manual process and because it is one it leaves many systems unprotected.

Systems that crawl user provided URLs are in the minority. For most systems it is irrelevant.

Re: Fun with IP address parsing

#143

Post by beaugunderson »

I maintain a JavaScript library that does exactly this (called ip-address). Unit tests are very important for handling the esoteric formats, though there are a couple that were new to me in David's post.

One of my motivations for writing the library was being able to grep for IPv6 addresses in text files; it's surprisingly difficult to match all valid representations of a simple IPv6 address as seen in the example here:

https://twitter.com/beaugunderson/status/527393872909828096

I also maintain a site for examining IPv6 addresses that may be useful to people working with IPv6:

http://v6decode.com/

Re: Fun with IP address parsing

#144

Post by lmm »

octoberfranklin wrote: post #140
lmm wrote: post #127

Earlier quoted context omitted.

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

And having two completely separate internets (IPv6 and IPv4) forever isn't a wasteful burden? 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…

> And having two completely separate internets (IPv6 and IPv4) forever isn't a wasteful burden?

Your proposal would force maintaining IPv4 for longer and in more networks: every IPv6 router would have to have IPv4 connectivity and probably a routeable IPv4 address, so it wouldn't even solve the address exhaustion problem for long (perhaps not even at all).

> Not requiring backwards compatibility in IPv6 guaranteed that IPv4 would be around forever. IPv4 is never, ever going away because of this.

IPv4 has already been eliminated from newer edge networks, and for those networks the vast majority of upstream traffic is IPv6. No doubt those networks will have to maintain 464XLAT for a long time as the long tail of upstream sites that are only v4-accessible, but they'll be able to have a smaller and smaller pool of 464XLAT servers and outsource the v4 connectivity support further and further upstream (just as with Usenet), until eventually v4 connectivity becomes a paid add-on and then goes away entirely. Home routers for use with PCs will probably have to offer 4over6 for a long time, because it's hard for an ISP to be confident all their users are up to date, but that doesn't actually reduce the benefits that much (all your internal network management can still be v6, only the little home user LANs are v4), and organisations that manage all their endpoint devices don't even need that much.

Re: Fun with IP address parsing

#145

Post by ECBicalho »

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

Interesting article. If I understand correctly, the equivalent for the decimal 216 (hexadecimal D8) must be "stormy" or "stupendous".

And in this case "209.216.230.240" translates to "stairway stupendous tracker upcoming".

Thanks for sharing.

Re: Fun with IP address parsing

#146

Post by Dagger2 »

growse wrote: post #105
octoberfranklin wrote: post #92

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

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…

::ffff:0:0/96 is for representing v4 addresses in v6 APIs. If you tell the kernel you want to send a packet to ::ffff:1.2.3.4, you're actually telling it you want to send a (v4!) packet to 1.2.3.4, you're just doing it using an AF_INET6 socket rather than an AF_INET one.

Since packets aren't APIs, you should never see ::ffff:0:0/96 in packets on the wire. A v6-only host can't use this prefix to send v4 packets to v4 hosts.

(What would the source address of those packets even be?)

Re: Fun with IP address parsing

#147

Post by Dagger2 »

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.

Bigger nitpick: as per RFC 5952, canonically :: is ::. 0000:0000:0000:0000:0000:0000:0000:0000 is a valid way of writing the same address, but it's not the canonical way.

Re: Fun with IP address parsing

#148

Post by knorker »

firethief wrote: post #138
knorker wrote: post #118

Earlier quoted context omitted.

0 connects to localhost. It's shorter.

0 is 0.0.0.0, which is not a valid address for most purposes. Some programs, like iputils ping, have special handling for that case (i.e. using it as an alias for the unroutable host address); some programs, like FreeBSD's ping, do not [1]. Unlike most of these address tricks, it's not standardized, except that treating it as a normal address is technically disallowed. 1: https://unix.stackexchange.com/questions/9933…

Not quite. Yes, that may be true for ping, but ping is very much special. It builds its raw packets.

But do a "strace -econnect nc 0 22" and you'll see that yes, actually, a connect() syscall to "0.0.0.0" does connect to localhost.

Re: Fun with IP address parsing

#149

Post by the_mitsuhiko »

icedchai wrote: post #142
the_mitsuhiko wrote: post #141

Earlier quoted context omitted.

Which is a manual process and because it is one it leaves many systems unprotected.

Systems that crawl user provided URLs are in the minority. For most systems it is irrelevant.

I strongly disagree. Almost every single system has webhooks which by definition are user supplied URLs.

Re: Fun with IP address parsing

#150

Post by firethief »

knorker wrote: post #148
firethief wrote: post #138

Earlier quoted context omitted.

0 is 0.0.0.0, which is not a valid address for most purposes. Some programs, like iputils ping, have special handling for that case (i.e. using it as an alias for the unroutable host address); some programs, like FreeBSD's ping, do not [1]. Unlike most of these address tricks, it's not standardized, except that treating it as a normal address is technically disallowed. 1: https://unix.stackexchange.com/questions/9933…

Not quite. Yes, that may be true for ping, but ping is very much special. It builds its raw packets. But do a "strace -econnect nc 0 22" and you'll see that yes, actually, a connect() syscall to "0.0.0.0" does connect to localhost.

Interesting. That doesn't seem to be specified in the RFC1122 standard or the Linux ip(7) docs, but it's an explicit special case in the kernel (ip_route_output_key_hash_rcu):

        if (!fl4->daddr) {
                fl4->daddr = fl4->saddr;
                if (!fl4->daddr)
                        fl4->daddr = fl4->saddr = htonl(INADDR_LOOPBACK);
                ...
Post reply on HN