5 ms·

Isn't there a problem here? This draft says: IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as "127.0.0.0/8". That's not perfectly true. RFC5

Isn't there a problem here? This draft says: IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as "127.0.0.0/8". 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. 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. 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. Unnecessary restrictions can have unexpected & unknowable consequences. "Tools not policy".

ghshephard 10y ago
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
mikewest 10y ago
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 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 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 10y ago
  "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 10y ago
    Thankfully IPv6 defined a single "localhost" or loopback IP: ::1/128 There is none of this 127/8 mess.
    - the8472 10y ago
      that "mess" is great for testing though, you can spin up numerous instances each on their own loopback address.
      - TimWolla 10y ago
        You can use a link local address of your public interface in IPv6.
        the8472 10y ago
        That's just one, adding more require elevated privileges, with 127.0.0.0/8 you have 256³ at your disposal.
- inopinatus 10y ago
  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!
josteink 10y ago
> 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.
- mikewest 10y ago
  > 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'." :)
smoyer 10y ago
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.
amluto 10y ago
> 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?
- inopinatus 10y ago
  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.
  - amluto 10y ago
    Aha, and you want to make servicename.localhost resolve there. That makes sense. Making plain "localhost" go somewhere special seems dubious.
facetube 10y ago
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`)
- SysArchitect 10y ago
  https://www.iana.org/domains/root/db/drive.html 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 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 :/
rsync 10y ago
"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 ?
- brohee 10y ago
  Mocking machines for testing is one reason.

ghshephard 10y ago

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

mikewest 10y ago

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 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 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 10y ago
"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 10y ago
  Thankfully IPv6 defined a single "localhost" or loopback IP: ::1/128 There is none of this 127/8 mess.
  - the8472 10y ago
    that "mess" is great for testing though, you can spin up numerous instances each on their own loopback address.
    - TimWolla 10y ago
      You can use a link local address of your public interface in IPv6.
      - the8472 10y ago
        That's just one, adding more require elevated privileges, with 127.0.0.0/8 you have 256³ at your disposal.
inopinatus 10y ago
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!

josteink 10y ago

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

mikewest 10y ago
> 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'." :)

smoyer 10y ago

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.

amluto 10y ago

> 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?

inopinatus 10y ago
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.
- amluto 10y ago
  Aha, and you want to make servicename.localhost resolve there. That makes sense. Making plain "localhost" go somewhere special seems dubious.

facetube 10y ago

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

SysArchitect 10y ago
https://www.iana.org/domains/root/db/drive.html 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 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 :/

rsync 10y ago

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

brohee 10y ago
Mocking machines for testing is one reason.