[mikewest]

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

[jerf]

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

[SysArchitect]

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

There is none of this 127/8 mess.

[the8472]

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

[TimWolla]

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

[the8472]

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

[inopinatus]

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!