I’m puzzled by much of this discussion. We want a way for an application to indicate that it wants a loopback connection to another port on the local host.
People widely use “localhost” for this. But other people argue that a mere RFC can’t guarantee that a host doesn’t violate the assumption that “localhost” means “local host”. So, to indicate that it wants a loopback connection to another port on the local host, an application needs to use “127.0.0.1”. By, by the same logic, a mere RFC can’t guarantee that a host doesn’t violate the assumption that “127.0.0.1” means loopback. Who knows what a host OS will do with that address, if it does not follow the relevant RFCs? [*] Forgive me, I forgot, “127.0.0.1” is obsolete. I should have written, “::1”. I’ll try again: So, to indicate that it wants a loopback connection to another port on the local host, an application needs to use “::1”. By, by the same logic, a mere RFC can’t guarantee that a host doesn’t violate the assumption that “::1” means loopback. Who knows what a host OS will do with that address, if it does not follow the relevant RFCs? So, “127.0.0.1” and “::1” are not suitable, both because a host OS might choose not to follow the relevant RFCs, and more importantly, they’re both address-family-specific. What we really need is some symbolic way for an application to indicate unambiguously that it wants a loopback connection to another port on the local host. We should reserve a specific string and define that it has this meaning. Some operating systems will follow the specification, and will work as expected, and others will not, which is a bug. Don’t use those products. A nice mnemonic string would be good. Something memorable, which conveys the meaning, “local host”. I suggest “localhost”. Stuart Cheshire [*] If you think it’s stupid to suggest a host might not treat “127.0.0.1” as meaning loopback, why is that any more stupid than suggesting that a host might not treat “localhost” as meaning loopback? Both are just as arbitrary. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
