Hacker News Reader

That's not perfectly true. RFC5735 defines 127/8 as loopback addresses, but it leaves the door open for other addresses to be assigned to the loopback interface. And indeed doing so is a common pattern for network devices, and a less common (but very useful) pattern for services.

I don't mean to overconstrain the definition of loopback. If you have a good mechanism for specifying a specific IP range as loopback, and that mechanism can be understood by client software and resolution APIs, then I don't see any reason not to allow it.

The salient distinction from my perspective is traffic within a specific host, and traffic that traverses the network. If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)

I also find it curious that this draft allows only address queries (presumably A and AAAA) under .localhost. I'd like to know the rationale for that restriction. For example, there may well be applications that only use SRV records.

https://twitter.com/dbrower/status/781001487157719040 raises similar concerns. The rationale is simple: I wanted to make the smallest change possible to RFC6761, and item 3 of https://tools.ietf.org/html/rfc6761#section-6.3 already contains the address query restriction.

It's probably reasonable to reconsider it, that's just a larger change than the one I was specifically trying to make. :)

"If you have suggestions for language that make that distinction more clearly than the document currently does, I'm happy to incorporate it. :)"

Currently where it says "an IP loopback addresses", it may be worth saying something like "any of the IP loopback addresses for the device".

I agree that technically "an IP loopback address" ought to be sufficient, but I have also found it is a very common belief, probably even the majority belief, among people who use networking that "127.0.0.1" is the one and only loopback address. (I've lost count of the systems I've slightly broken just by feeding them 127.1.1.1 or equivalent.) I'm sure people who are the sort to read and write standards know better, but since it doesn't hurt the standard itself to emphasize the point, perhaps it's worth it.

Thankfully IPv6 defined a single "localhost" or loopback IP: ::1/128

There is none of this 127/8 mess.

that "mess" is great for testing though, you can spin up numerous instances each on their own loopback address.

You can use a link local address of your public interface in IPv6.

That's just one, adding more require elevated privileges, with 127.0.0.0/8 you have 256³ at your disposal.

Hey, thanks for the considered reply. I rustled up alternative language you might consider for section 3.1 paragraph 1:

"Name resolution APIs and libraries MUST recognize localhost names as special, and MUST always return a unicast address that cause the node to send an IP datagram to itself."

This deliberately echoes the language of RFC4291 and RFC6890 when defining loopbacks. Can I also suggest revising references, looks like RFC5735 has been obsoleted by RFC6890.

Overall I think this draft is a helpful clarification, thanks for creating it!

> So let's say I've assigned 10.1.1.1/32 to a device loopback interface, I'm announcing it in my IGP, and I've bound a particular service to listen on 10.1.1.1:1234. Should the local resolver library be allowed to return 10.1.1.1 for servicename.localhost? Under this draft's (re)definition of loopback addresses, definitely not. So now we've lost that symbolic way to configure a service consumer to connect locally. You're left inventing workarounds such as your own namespace for loopbacks, or changing the service to also bind to, say, 127.1.1.1.

Setting localhost to resolve to 10.1.1.1 works, sometimes, for this particular use case, but it doesn't work particularly well. Consider what happens when your served is multi-homed: which interface's address should "localhost" resolve to? What if you have one service at 10.1.1.1 and another at 192.168.0.1, both are on the same box, and both want to be called "localhost".

If you're single-homed, then why not bind INADDR_ANY and let localhost be 127.0.0.1?

Ah, I think you've assumed that the assignment of 10.1.1.1/32 to lo in that example is to replace 127.0.0.1/8. It's in-addition-to. The most common case is multi-homed routers that wish to announce a management address into the IGP, but I've also used it for stuff from proxy farms to making containerized/virtualized microservices a bit more portable, and I'm far from the most sophisticated user. There's people out there doing exotic things with anycast or VPNs or VOIP or MPLS that do this too. I once built a Cisco UCCE site that required it as part of ensuring there was a diverse path for their queue state replication that was in a separate routing protocol convergence domain. And so on - it's far from unusual.

Aha, and you want to make servicename.localhost resolve there. That makes sense. Making plain "localhost" go somewhere special seems dubious.

I've commonly changed localhost to addresses outside the 127/8 region for debugging purposes (and assigned other names to loopback addresses which will presumably still be allowed). If this RFC is ratified, it will be one of those things I'll forget repeatedly for a while.

"You're left inventing workarounds such as your own namespace for loopbacks, or changing the service to also bind to, say, 127.1.1.1."

I don't understand this - you say you are "left with" an entire /8 that is universally recognized as the loopback ... what more could you want ?

I am genuinely curious - what is the utility of having lots of different network address ranges to define as the loopback ?

Mocking machines for testing is one reason.

And, in fact, 127.0.53.53 already has a special use (try `dig @8.8.8.8 -ta drive` and `dig @8.8.8.8 -tmx drive`)

https://www.iana.org/domains/root/db/drive.html

It's a valid TLD...

https://www.icann.org/news/announcement-2-2014-08-01-en

shows why drive. was set to return 127.0.53.53.

Same thing happened with prod. and other TLD's. These are all names that were/are being used internally and now are valid TLD's that are going to cause issues for people :/

Symbolic way to force a local application locally as follows:

16:04:25 speedy :{~} $ cat /etc/hosts

   ##
   # Host Database
   #
   # localhost is used to configure the loopback interface
   # when the system is booting.  Do not change this entry.
   ##
   127.0.0.1       localhost
   10.1.1.1        servicelocalhost

> IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as "127.0.0.0/8".

Did you just assume IPv4? That's IPist!

Seriously though. IPv6 exists. And it has a different address and notation for localhost (::1). Which means that using an IP(v4)-address alone is not guaranteed to be bulletproof.

The only bulletproof way to ensure that you bind to a genuine loopback interface is letting the OS tell you which address that is. And for that you need a "localhost" hosts-file entry or equivalent.

> Did you just assume IPv4? That's IPist!

The next line in the document is "IPv6 loopback addresses are defined in Section 3 of [RFC5156] as '::1/128'." :)