Bug 1279005 - Can't bind() to IPv6 Link-Local somewhat hidden address on loopback interface
Can't bind() to IPv6 Link-Local somewhat hidden address on loopback interface
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: fedora-kernel-networking
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-06 22:08 EST by markzzzsmith
Modified: 2016-07-19 14:25 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 14:25:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description markzzzsmith 2015-11-06 22:08:00 EST
Description of problem:

Although not shown via 'ip addr show dev lo', I've recently discovered that loopback interfaces do now have link-local addresses e.g.,

--
[mark@opy ~]$ ip addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback ce:eb:be:d5:8c:35 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
[mark@opy ~]$ 
--

--
[mark@opy ~]$ ip -6 route show table local | grep fe80
local fe80::1c2d:d1ff:fe2e:2a68 dev lo  proto none  metric 0 
[mark@opy ~]$
--

--
[mark@opy ~]$ ping6 -I lo -c 1 fe80::1c2d:d1ff:fe2e:2a68
ping6: Warning: source address might be selected on device other than lo.
PING fe80::1c2d:d1ff:fe2e:2a68(fe80::1c2d:d1ff:fe2e:2a68) from fe80::1c2d:d1ff:fe2e:2a68 lo: 56 data bytes
64 bytes from fe80::1c2d:d1ff:fe2e:2a68: icmp_seq=1 ttl=64 time=0.076 ms

--- fe80::1c2d:d1ff:fe2e:2a68 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.076/0.076/0.076/0.000 ms
[mark@opy ~]$
--

However, my application (https://github.com/markzzzsmith/replicast), which supports using LL addresses, cannot bind to it:

--
[mark@opy replicast]$ ./replicast -nodaemon -6in [fe80::1c2d:d1ff:fe2e:2a68%lo]:1234 -4out 192.0.2.1:1234
replicast v0.1
inet6 rx src: [fe80::1c2d:d1ff:fe2e:2a68%lo]:1234
inet tx dsts: 192.0.2.1:1234
inet tx opts: out intf rt table, mc ttl 1
inet6_to_inet_rcast():1956 error: Cannot assign requested address
[mark@opy replicast]$
--

If I add a Link-Local address to the lo interface, it now appears in the 'ip addr' output, and my application can now bind to the new and visible Link-Local address:

--
[mark@opy ~]$ sudo ip addr add fe80::5678/64 dev lo
[sudo] password for mark: 
[mark@opy ~]$ ip -6 addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 
    inet6 fe80::5678/64 scope link 
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
[mark@opy ~]$
[mark@opy replicast]$ ./replicast -nodaemon -6in [fe80::5678%lo]:1234 -4out 192.0.2.1:1234
replicast v0.1
inet6 rx src: [fe80::5678%lo]:1234
inet tx dsts: 192.0.2.1:1234
inet tx opts: out intf rt table, mc ttl 1
--


So I think the problem is that while lo does have a LL address, it isn't a one that is visible to applications.

Ideally, I'd like the whole fe80::/64 Link-Local prefix to behave on the loopback interface the same way the IPv4 127.0.0.0/8 prefix does - applications can bind to any address within the prefix, even if it is not visible/configured via 'ip addr show' e.g.

--
[mark@opy replicast]$ ip -4 addr show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
[mark@opy replicast]$
[mark@opy replicast]$ ./replicast -nodaemon -4in 127.1.2.3:1234 -4out 192.0.2.1:1234
replicast v0.1
inet rx src: 127.1.2.3:1234
inet tx dsts: 192.0.2.1:1234
inet tx opts: out intf rt table, mc ttl 1
--

Version-Release number of selected component (if applicable):

Kernel 4.2.5-201.fc22

How reproducible:

All the time.


Steps to Reproduce:
1. Attempt to bind to the LL address assigned to the Loopback interface

Actual results:

bind() call fails with errno 99, "Cannot assign requested address."

Expected results:

bind() call succeeds.

Additional info:


I've recently written an Internet Draft on how to use Link-Local addresses in applications, review and comments welcome.

"How to use IPv6 Link-Local Addresses in Applications"
https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00
Comment 1 markzzzsmith 2015-11-07 00:52:51 EST
Actually, to clarify a bit better what I'd ideally like on loopback with LLs:

- the currently hidden automatic LL address appears on the lo interface like 127.0.0.1/8 currently does

- all other addresses within the fe80::/64 prefix on the lo interface can be bind()'d to, as all other addresses within 127.0.0.0/8 can be.

IOW, same behaviour and appearance for the loopback interface fe80::/64 prefix and address as occurs with the 127.0.0.0/8 prefix and address.

(This is a bit of a half step, ideally I'd like a larger loopback prefix for IPv6 so that it wasn't necessary to specify interfaces when using LLs on a loopback interface:

"A Larger Loopback Prefix for IPv6"
https://datatracker.ietf.org/doc/draft-smith-v6ops-larger-ipv6-loopback-prefix/)
Comment 2 Fedora End Of Life 2016-07-19 14:25:57 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.