On Aug 2, 2017, at 9:07 AM, Mike West <mk...@google.com> wrote: > I was typing basically this when Richard's message came in. So I'll simply > add that Problem 8 in > https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-5 > <https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-5> > suggests that we already know that this kind of hard-coding will cause issues > for future migrations. Just as we'd like to discourage folks from hard-coding > `127.0.0.1` to be certain that they're talking to the loopback interface, it > seems reasonable to discourage folks from hard-coding `::1`.
I don't think I agree. It's entirely possible that at some future time, [::1] will have symbolic meaning but will not refer to a transport protocol destination address. But we are arguing that "localhost" should be treated specially by every piece of software that looks at it, when its default meaning is "look up localhost in the DNS and connect to one of the addresses that you get in response." The default meaning of "[::1]" is "connect to the local host." There isn't even an implicit indirection there. So if you have a host running IPv10, where [::1] doesn't have an explicit meaning, one of two things will be the case: either the piece of software looking at [::1] will do an explicit transformation from [::1] to the right thing, or it won't. If it does, things just work. If it doesn't, they fail safe: the connection fails. With localhost, if the software does the wrong thing, it does not fail safe.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
