Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Internet Draft: Let 'localhost' be localhost

tools.ietf.org

Post reply on HN
Print view View original

151–160 of 179 posts

Re: Internet Draft: Let 'localhost' be localhost

#151

Post by justinclift »

user5994461 wrote: post #149
p1mrx wrote: post #97

Earlier quoted context omitted.

Ideally, a server binding to "localhost" should create a listening socket for each of its IP addresses (e.g. 127.0.0.1 and ::1), and a client connecting to "localhost" should try each IP address in order, until one succeeds. But a lot of standard libraries (including parts of Java and Go) get this wrong, and pick exactly one IP address arbitrarily. When you combine a buggy client with a buggy server, and their prefer…

An interface on linux has only one ip address. The "localhost" interface will either designate the ipv4 127.0.0.1 interface or the ipv6 ::1 interface. That's the realm of undefined behavior and system specifics. This whole IETF draft looks like a mess. They should reserve the names localhost4 and localhost6.

> An interface on linux has only one ip address.

Just to point out, while the behaviour of any one OS is a useful data point for the discussion, it's not super useful to say "because OS 'foo' does things in a certain way, a well used programming language should limit it's design to that OS's way of doing things." :)

Hmmm, I guess I'm trying to say that (at least) Go should be fairly OS agnostic about this.

Re: Internet Draft: Let 'localhost' be localhost

#152

Post by __david__ »

user5994461 wrote: post #149
p1mrx wrote: post #97

Earlier quoted context omitted.

Ideally, a server binding to "localhost" should create a listening socket for each of its IP addresses (e.g. 127.0.0.1 and ::1), and a client connecting to "localhost" should try each IP address in order, until one succeeds. But a lot of standard libraries (including parts of Java and Go) get this wrong, and pick exactly one IP address arbitrarily. When you combine a buggy client with a buggy server, and their prefer…

An interface on linux has only one ip address. The "localhost" interface will either designate the ipv4 127.0.0.1 interface or the ipv6 ::1 interface. That's the realm of undefined behavior and system specifics. This whole IETF draft looks like a mess. They should reserve the names localhost4 and localhost6.

> An interface on linux has only one ip address.

Eh?

    $ ifconfig lo
    lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 1000  (Local Loopback)

Re: Internet Draft: Let 'localhost' be localhost

#153

Post by wjoe »

thescriptkiddie wrote: post #122
RJIb8RBYxzAMX9u wrote: post #108

Earlier quoted context omitted.

Hey, Firefox's still alive and kicking. It's quite ancient, comparatively speaking. :-) Old wisemen may refer to it as a fire-breathing reptile, others a bird clad in flames. And despite suffering from declining market share in recent years, prophecy foretold that it will one day rise from the red ashes, stronger and more resilient than ever! (Apologies for running away with the joke)

Firefox has the awesome bar, which works almost exactly like Chrome's omnibox.

But Firefox has the option to disable search functionality in the URL bar - not sure if it still asks you or if it's hidden behind an about:config option these days though. It's also significantly better at matching parts of URLs and titles from your history in my experience.

Re: Internet Draft: Let 'localhost' be localhost

#154

Post by pas »

ploxiln wrote: post #84
deathanatos wrote: post #54

Earlier quoted context omitted.

> and that breaks everything If you're on a POSIX system, I'd argue that this is a bug in the client. Typically, the client should call getaddrinfo(3); as part of that, the application would either specify directly that it's only interested in AF_INET results, or just filter out non-AF_INET results. (Further, if you support IPv6 in the client, and thus request such results from getaddrinfo, you should skip to the nex…

I agree about getaddrinfo(). Applications should have specified AF_INET to gethostbyname() and then when updating to getaddrinfo(), handle ipv6 correctly or skip it. The IPv4-mapped IPv6 addresses thing is a terrible idea that ends up turned off everywhere it makes a difference. Like all of these "transition" ideas, it tries to help, but it just hurts by causing admins/ops/devs to just make sure ipv6 is off everywher…

Transition mechanisms suffer from the same problem as the upgrade to ipv6, the need for an upgrade.

So in this sense all were doomed to fail.

Remarkably the CGN devices are actually the best practical idea for this. Fake IPv4 addresses for the dumb ossified clients and that's it. If something important enough for the end user doesn't work, they'll finally upgrade.

Re: Internet Draft: Let 'localhost' be localhost

#155

Post by pas »

kbutler wrote: post #80
deathanatos wrote: post #54

Earlier quoted context omitted.

> and that breaks everything If you're on a POSIX system, I'd argue that this is a bug in the client. Typically, the client should call getaddrinfo(3); as part of that, the application would either specify directly that it's only interested in AF_INET results, or just filter out non-AF_INET results. (Further, if you support IPv6 in the client, and thus request such results from getaddrinfo, you should skip to the nex…

Does it matter if it's a bug in the client? Make it work like expected. Especially when changing infrastructure like IPV4->IPV6 - don't break existing userbase code! (This is a fundamental precept of Linux development.)

> Make it work like expected.

Expected by code or by the progammer(s)?

That said, strong API guarantees are the way, documentation should note the bug, introduce a fixed version for the API, maybe schedule deprecation in 10-15 years, and carry on with life.

It's not worth it to hunt down every client and make them fix your honest mistake.

Re: Internet Draft: Let 'localhost' be localhost

#156

Post by tialaramex »

wfunction wrote: post #103
splitrocket wrote: post #101

Earlier quoted context omitted.

I'd say this growth curve looks healthy and robust to me: https://www.google.com/intl/en/ipv6/statistics.html

Yeah you're right, it certainly does. I would be curious if it goes mainstream enough to replace IPv4 in the foreseeable future though, which was its intention.

The expectation is that networks will switch to IPv6 only internally, and eventually the IPv4-only remainder of the Internet decays until it's no longer an "IPv4 Internet" but just a handful of separate IPv4 networks that are connected to the (now IPv6 only) Internet by protocol converters.

Some US corporations did this already, rather than fuss with being "dual stack" and potentially introducing new IPv4-only services or systems, they switched wholesale to IPv6 and add converters at the edges. By choosing to do this they get most of the benefits of a future IPv6-only Internet today. For example, numbering internally is a breeze, they can auto-number almost everything because the address space is so vast there is no need to "plan" any of it.

Lots of other US corporations are still IPv4-only, indeed that's why the Google graph earlier has a distinct weekday vs weekends / holidays step change in it. At home a very large proportion of people in industrialised countries have IPv6, major ISPs supply it, common household routers understand how to use it, every modern OS groks it. But at work IPv6 is often disabled by policy, in favour of cumbersome IPv4 because that works and changing things at work is forbidden.

Re: Internet Draft: Let 'localhost' be localhost

#157

Post by tialaramex »

agwa wrote: post #32
aeorgnoieang wrote: post #10

Earlier quoted context omitted.

So, an RFRFC?

It's called an I-D, for "Internet Draft." Very roughly, a Standards Track document in the IETF goes through four stages: 1. Someone submits an I-D as an individual. Literally anyone can do this and such a document carries no weight. 2. A working group (WG) "adopts" the I-D and proceeds to work on the document as a group. The document still carries no weight at this stage. 3. The I-D is published as an RFC. When this…

To be fair this is the fourth draft of "Let localhost be localhost". Internet Drafts deliberately "expire" unless you write an updated version every so often proving it's still interesting and being worked on. @agwa says they have "no weight" but pragmatically what matters is always whether people do what the document says, not its supposed "weight" within a standards body.

For example many of you will have used Let's Encrypt, the whole of Let's Encrypt is built upon a standard issuance and management protocol, ACME. But ACME is still only an Internet Draft, albeit it's likely to go to RFC before the end of this year. So it didn't matter that in your view it "has no weight", it had millions of people using it.

If this I-D takes off and is widely accepted by, say, Microsoft and Apple, even if it never becomes an RFC it has a real effect. On the other hand, if it becomes a standards track RFC but Apple decides to ignore it and never promise that "localhost is localhost" in their operating systems then it's worthless despite the "Standard" tag.

Re: Internet Draft: Let 'localhost' be localhost

#158

Post by frubar »

kbutler wrote: post #80
deathanatos wrote: post #54

Earlier quoted context omitted.

> and that breaks everything If you're on a POSIX system, I'd argue that this is a bug in the client. Typically, the client should call getaddrinfo(3); as part of that, the application would either specify directly that it's only interested in AF_INET results, or just filter out non-AF_INET results. (Further, if you support IPv6 in the client, and thus request such results from getaddrinfo, you should skip to the nex…

Does it matter if it's a bug in the client? Make it work like expected. Especially when changing infrastructure like IPV4->IPV6 - don't break existing userbase code! (This is a fundamental precept of Linux development.)

Only in software development are we expected to go out of our way to support people who don't know what they're doing. Imagine a medical student complaining the professor that the scalpel doesn't cut on the dull end or a would-be airline pilot upside down in their seat complaining he can't reach the controls.

And your comment about never breaking existing userbase code is as ridiculous as it is unreasonable. This would only be a reasonable expectation if only correct code were possible to run. Since it's possible to run broken code (as this anecdote demonstrates) then it must be possible to fix the system even if that breaks some poorly written, but popular systems.

Does anyone want a world of e.g. Windows where decades old bugs have to be replicated because we can't dare break programs so old all the authors are retired or dead? I don't. Backwards compatibility has a cost and I'm not willing to pay it unconditionally.

Re: Internet Draft: Let 'localhost' be localhost

#159

Post by topranks »

rnxrx wrote: post #109
wfunction wrote: post #103

Earlier quoted context omitted.

Yeah you're right, it certainly does. I would be curious if it goes mainstream enough to replace IPv4 in the foreseeable future though, which was its intention.

It's been quite mainstream in certain contexts and geographies for a number of years now. As an example - most handsets on modern LTE (and newer) networks have been strong-majority v6 for quite a while. The fact that this hasn't been obvious is an argument in favor of v6's success.

I'm not sure that's the case. Certainly not in Europe anyway, although it is seeing wider adoption now (particularly 464XLAT based solutions).

Re: Internet Draft: Let 'localhost' be localhost

#160

Post by jaas »

piscisaureus wrote: post #79
rblatz wrote: post #55

Earlier quoted context omitted.

I hope you don't publish that record to the world.

It's already been done: https://git.daplie.com/Daplie/localhost.daplie.me-certificat... Which I find to be a very practical solution for connecting to localhost over https, it frees you from having to install a self-signed certificates/CAs on your machine.

Publishing private keys is a violation of the Let's Encrypt terms of service. We are revoking these certificates.

https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016...

Post reply on HN