ssh, X, IPv6, and localhost

I've got a couple Fedora and Red Hat boxes mostly moved to IPv6. I've
noticed a quirk with transporting X over ssh over IPv6.

/etc/hosts on Fedora and Red Hat defines localhost as 127.0.0.1 and
localhost6 as ::1.

"ssh -X" automatically defines DISPLAY as localhost:10.0 on the remote
system.

Unfortunately, the local port (6010) is on ::1 (localhost6), not
127.0.0.1 (localhost).

I can manually change the definition of DISPLAY to localhost6:10.0 and
everything works fine.

What do other distros do to define ::1 symbolically? Is localhost6
really the convention or is it RH/Fedora-specific? Have I found a bug
in ssh dealing with IPv6?

FWIW, I noticed that Fedora's bind package defines localhost as both
127.0.0.1 (A) and ::1 (AAAA) by default. It doesn't define localhost6
at all.

Thanks for any wisdom you can provide.

"Allen Kistler" <(E-Mail Removed)> wrote in message
newsRIfl.14679$(E-Mail Removed)...
> I've got a couple Fedora and Red Hat boxes mostly moved to IPv6. I've
> noticed a quirk with transporting X over ssh over IPv6.
>
> /etc/hosts on Fedora and Red Hat defines localhost as 127.0.0.1 and
> localhost6 as ::1.

That's your problem. Such a definition is WRONG. Regardless, "/etc/hosts"
defines IP addresses as names, not names as IP addresses. Each line is one
address followed by one or more hostnames.

> "ssh -X" automatically defines DISPLAY as localhost:10.0 on the remote
> system.
>
> Unfortunately, the local port (6010) is on ::1 (localhost6), not
> 127.0.0.1 (localhost).

And why is that a problem? Linux IPv6 binding defaults to accepting IPv4
via IPv6 sockets. IPV6_ONLY is an option that defaults to off.

> I can manually change the definition of DISPLAY to localhost6:10.0 and
> everything works fine.
>
> What do other distros do to define ::1 symbolically? Is localhost6
> really the convention or is it RH/Fedora-specific? Have I found a bug
> in ssh dealing with IPv6?
>
> FWIW, I noticed that Fedora's bind package defines localhost as both
> 127.0.0.1 (A) and ::1 (AAAA) by default. It doesn't define localhost6
> at all.

That's because BIND does it correctly.

D. Stussy wrote:
> "Allen Kistler" <(E-Mail Removed)> wrote in message
> newsRIfl.14679$(E-Mail Removed)...
>> I've got a couple Fedora and Red Hat boxes mostly moved to IPv6. I've
>> noticed a quirk with transporting X over ssh over IPv6.
>>
>> /etc/hosts on Fedora and Red Hat defines localhost as 127.0.0.1 and
>> localhost6 as ::1.
>
> That's your problem. Such a definition is WRONG. Regardless, "/etc/hosts"
> defines IP addresses as names, not names as IP addresses. Each line is one
> address followed by one or more hostnames.

Well, everyone who runs Fedora or Red Hat would have the same problem.
The localhost/localhost6 schism is something that installs by default.
I didn't create it.

>> "ssh -X" automatically defines DISPLAY as localhost:10.0 on the remote
>> system.
>>
>> Unfortunately, the local port (6010) is on ::1 (localhost6), not
>> 127.0.0.1 (localhost).
>
> And why is that a problem? Linux IPv6 binding defaults to accepting IPv4
> via IPv6 sockets. IPV6_ONLY is an option that defaults to off.

It's a problem because, without redefining DISPLAY, I get the error
"cannot open display: localhost:10.0" when I try to start an X app.

>> I can manually change the definition of DISPLAY to localhost6:10.0 and
>> everything works fine.
>>
>> What do other distros do to define ::1 symbolically? Is localhost6
>> really the convention or is it RH/Fedora-specific? Have I found a bug
>> in ssh dealing with IPv6?
>>
>> FWIW, I noticed that Fedora's bind package defines localhost as both
>> 127.0.0.1 (A) and ::1 (AAAA) by default. It doesn't define localhost6
>> at all.
>
> That's because BIND does it correctly.

Can you point to a reference? I'm willing to believe that their default
is wrong, but I'd like to see a more authoritative source.

Hello,

D. Stussy a écrit :
> "Allen Kistler" <(E-Mail Removed)> wrote :
>
>> Unfortunately, the local port (6010) is on ::1 (localhost6), not
>> 127.0.0.1 (localhost).
>
> And why is that a problem? Linux IPv6 binding defaults to accepting IPv4
> via IPv6 sockets.

Only when binding to the unspecified IPv6 address ::, not when binding
to a specific IPv6 address such as ::1. So this socket won't accept IPv4
connections.

>> What do other distros do to define ::1 symbolically?

In Debian /etc/hosts defines ::1 as ip6-localhost and ip6-loopback.

>> FWIW, I noticed that Fedora's bind package defines localhost as both
>> 127.0.0.1 (A) and ::1 (AAAA) by default.

Where do you see this ?

Pascal Hambourg wrote:
> D. Stussy a écrit :
>> "Allen Kistler" <(E-Mail Removed)> wrote :
>>
>>> Unfortunately, the local port (6010) is on ::1 (localhost6), not
>>> 127.0.0.1 (localhost).
>>
>> And why is that a problem? Linux IPv6 binding defaults to accepting IPv4
>> via IPv6 sockets.
>
> Only when binding to the unspecified IPv6 address ::, not when binding
> to a specific IPv6 address such as ::1. So this socket won't accept IPv4
> connections.
>
>>> What do other distros do to define ::1 symbolically?
>
> In Debian /etc/hosts defines ::1 as ip6-localhost and ip6-loopback.

In my travels today, I think I've discovered that Gentoo defines
127.0.0.1 as "localhost localhost4" and ::1 as "localhost localhost6."

It's got an appealing symmetry to it. Also X apps seem OK with it (so
far), probably because most IPv6-aware apps prefer IPv6 addresses over
IPv4 addresses when both are available. (I seem to recall that behavior
is even in an RFC somewhere.)

>>> FWIW, I noticed that Fedora's bind package defines localhost as both
>>> 127.0.0.1 (A) and ::1 (AAAA) by default.
>
> Where do you see this ?

/var/named/named.localhost

Allen Kistler a écrit :
>
>>>> FWIW, I noticed that Fedora's bind package defines localhost as both
>>>> 127.0.0.1 (A) and ::1 (AAAA) by default.
>>
>> Where do you see this ?
>
> /var/named/named.localhost

I do not see such file in Debian's bind9 package. What does it contain ?

Pascal Hambourg wrote:
> Allen Kistler a écrit :
>>
>>>>> FWIW, I noticed that Fedora's bind package defines localhost as both
>>>>> 127.0.0.1 (A) and ::1 (AAAA) by default.
>>>
>>> Where do you see this ?
>>
>> /var/named/named.localhost
>
> I do not see such file in Debian's bind9 package. What does it contain ?

As distributed, it contains:

$TTL 1D
@ IN SOA @ rname.invalid. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
NS @
A 127.0.0.1
AAAA ::1


.... intended to be defined for zone "localhost," although I don't use
it. I define my own sightly differently.

"Pascal Hambourg" <boite-a-(E-Mail Removed)> wrote in message
news:glo0t2$odf$(E-Mail Removed)...
> D. Stussy a écrit :
> > "Allen Kistler" <(E-Mail Removed)> wrote :
> >
> >> Unfortunately, the local port (6010) is on ::1 (localhost6), not
> >> 127.0.0.1 (localhost).
> >
> > And why is that a problem? Linux IPv6 binding defaults to accepting
IPv4
> > via IPv6 sockets.
>
> Only when binding to the unspecified IPv6 address ::, not when binding
> to a specific IPv6 address such as ::1. So this socket won't accept IPv4
> connections.

But if his "localhost" were properly defined, his program should bind to a
socket for EACH address family. It's not - because the hostname definition
is wrong.

> >> What do other distros do to define ::1 symbolically?
>
> In Debian /etc/hosts defines ::1 as ip6-localhost and ip6-loopback.
>
> >> FWIW, I noticed that Fedora's bind package defines localhost as both
> >> 127.0.0.1 (A) and ::1 (AAAA) by default.
>
> Where do you see this ?

D. Stussy wrote:
> "Pascal Hambourg" <boite-a-(E-Mail Removed)> wrote ...
>> D. Stussy a écrit :
>>> "Allen Kistler" <(E-Mail Removed)> wrote :
>>>
>>>> Unfortunately, the local port (6010) is on ::1 (localhost6), not
>>>> 127.0.0.1 (localhost).
>>>
>>> And why is that a problem? Linux IPv6 binding defaults to accepting
>>> IPv4
>>> via IPv6 sockets.
>>
>> Only when binding to the unspecified IPv6 address ::, not when binding
>> to a specific IPv6 address such as ::1. So this socket won't accept IPv4
>> connections.
>
> But if his "localhost" were properly defined, his program should bind to a
> socket for EACH address family. It's not - because the hostname definition
> is wrong.

My "program" is sshd, which binds to ::1 to transport X because it's
configured "AddressFamily inet6" in sshd_config. sshd should only ever
bind to a loopback address to transport X, at least by default.
Anything else would be a significant security vulnerability.

In any case, now I wonder why different distros give each address family
a name unique to its respective loopback address. Obviously different
distributors thought it was a good idea once. Is it still? Was it
truly ever?

"Allen Kistler" <(E-Mail Removed)> wrote in message
news_Ufl.9702$(E-Mail Removed)...
> D. Stussy wrote:
> > "Pascal Hambourg" <boite-a-(E-Mail Removed)> wrote ...
> >> D. Stussy a écrit :
> >>> "Allen Kistler" <(E-Mail Removed)> wrote :
> >>>
> >>>> Unfortunately, the local port (6010) is on ::1 (localhost6), not
> >>>> 127.0.0.1 (localhost).
> >>>
> >>> And why is that a problem? Linux IPv6 binding defaults to accepting
> >>> IPv4
> >>> via IPv6 sockets.
> >>
> >> Only when binding to the unspecified IPv6 address ::, not when binding
> >> to a specific IPv6 address such as ::1. So this socket won't accept
IPv4
> >> connections.
> >
> > But if his "localhost" were properly defined, his program should bind
to a
> > socket for EACH address family. It's not - because the hostname
definition
> > is wrong.
>
> My "program" is sshd, which binds to ::1 to transport X because it's
> configured "AddressFamily inet6" in sshd_config. sshd should only ever
> bind to a loopback address to transport X, at least by default.
> Anything else would be a significant security vulnerability.
>
> In any case, now I wonder why different distros give each address family
> a name unique to its respective loopback address. Obviously different
> distributors thought it was a good idea once. Is it still? Was it
> truly ever?

....Because some of them have people that don't understand networking....

I see no problem giving the loopback entry a separate ALIAS for each
address family. However, the primary entry should be a unified entry, else
problems such as the above surface.