Cannot get IPv6 address from router

ratcheer · 2017-01-01 02:13:58

I have been trying to get this configured for two days. I have done many searches, but I cannot determine a solution. I would appreciate any help.

I have a Hurricane Electric IPv6 tunnel. The endpoint is an Apple Airport Extreme router. My iPhone and iPad get IP addresses from the router with no additional configuration. So does my wife's Windows 7 PC. All of those hosts pass the ipv6-test.com tests and display the swimming turtle on kame.net, so I am sure the tunnel is working.

But, on my Arch PC, when I start dhcpcd, this is what happens. The Arch host cannot even detect that there is an IPv6 router.

Dec 31 17:49:46 tim-arch-ssd dhcpcd[3184]: DUID 00:01:00:01:1f:f9:e6:16:50:e5:49:3a:45:05
Dec 31 17:49:46 tim-arch-ssd dhcpcd[3184]: enp4s0: IAID 49:3a:45:05
Dec 31 17:49:46 tim-arch-ssd dhcpcd[3184]: enp4s0: IAID 00:00:00:01
Dec 31 17:49:46 tim-arch-ssd dhcpcd[3184]: enp4s0: soliciting a DHCPv6 lease
Dec 31 17:49:46 tim-arch-ssd dhcpcd[3184]: enp4s0: soliciting an IPv6 router
Dec 31 17:49:58 tim-arch-ssd dhcpcd[3184]: enp4s0: no IPv6 Routers available
Dec 31 17:50:16 tim-arch-ssd systemd[1]: dhcpcd@enp4s0.service: Control process exited, code=exited status=1
Dec 31 17:50:16 tim-arch-ssd systemd[1]: Failed to start dhcpcd on enp4s0.
Dec 31 17:50:16 tim-arch-ssd systemd[1]: dhcpcd@enp4s0.service: Unit entered failed state.
Dec 31 17:50:16 tim-arch-ssd systemd[1]: dhcpcd@enp4s0.service: Failed with result 'exit-code'.

My dhcpcd.conf is:

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private
noipv4ll

# Added by TEC 12/31/2016
ipv6only
denyinterfaces wlp6s0
interface enp4s0
ipv6rs
ia_na 1

systemd-networkd and systemd-resolved are both running. This is my networkd configuration:

[Match]
Name=enp4s0

[Network]
DHCP=ipv6
Address=10.0.1.24/24
Gateway=10.0.1.1
Gateway=2001:xxxx:xxxx:xxxx::2
DNS=10.0.1.1
DNS=2001:xxxx:xxxx:xxxx::2

My ipv6 firewall configuration is:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all      lo     *       ::/0                 ::/0
    0     0 ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
    0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all      *      lo      ::/0                 ::/0
    5   876 ACCEPT     all      *      *       ::/0                 ::/0                 state NEW,RELATED,ESTABLISHED
    4   224 ACCEPT     icmpv6    *      *       ::/0                 ::/0

Again, thanks for any assistance to fix this.

Tim

ratcheer · 2017-01-01 15:48:05

A document I found advised me to add the following ip6tables rule. Unfortunately, it did not help.

ip6tables -A INPUT -p udp -m udp --dport 546 -j ACCEPT

Tim

Head_on_a_Stick · 2017-01-01 21:35:06

Did you try

DHCP=yes

as I suggested?

EDIT: reference: https://forums.bunsenlabs.org/viewtopic … 511#p42511

Last edited by Head_on_a_Stick (2017-01-01 21:36:01)

ratcheer · 2017-01-01 23:50:14

Yes, I think it shows in the systemd-networkd .network file, shown in the top post:

DHCP=ipv6

Unless you mean somewhere else.

Thanks,
Tim

ratcheer · 2017-01-04 18:09:33

Ok, I give up. I cannot even connect to the router, manually.

I dug into the configuration of my son's Macbook Pro and several iOS devices. The Macbook pro is pointing to fe80::1. The iOS devices are pointing to the full IPv6 router address, fe80::26a2:e1ff:fee9:51bf. Again, all of these devices, plus a Win 7 PC, an XBox One, and a PS4 connect and use the tunnel, completely automatically.

On my Arch PC, I pointed the default route to both of the above addresses. I still cannot even ping the router over IPv6.

ping -I enp4s0 fe80::1
PING fe80::1(fe80::1) from fe80::52e5:49ff:fe3a:4505%enp4s0 enp4s0: 56 data bytes
From fe80::52e5:49ff:fe3a:4505%enp4s0 icmp_seq=1 Destination unreachable: Address unreachable
From fe80::52e5:49ff:fe3a:4505%enp4s0 icmp_seq=2 Destination unreachable: Address unreachable
From fe80::52e5:49ff:fe3a:4505%enp4s0 icmp_seq=3 Destination unreachable: Address unreachable

ping -I enp4s0 fe80::26a2:e1ff:fee9:51bf
PING fe80::26a2:e1ff:fee9:51bf(fe80::26a2:e1ff:fee9:51bf) from fe80::52e5:49ff:fe3a:4505%enp4s0 enp4s0: 56 data bytes
From fe80::52e5:49ff:fe3a:4505%enp4s0 icmp_seq=1 Destination unreachable: Address unreachable
From fe80::52e5:49ff:fe3a:4505%enp4s0 icmp_seq=2 Destination unreachable: Address unreachable
From fe80::52e5:49ff:fe3a:4505%enp4s0 icmp_seq=3 Destination unreachable: Address unreachable

Tim

Last edited by ratcheer (2017-01-04 18:10:26)

ewaller · 2017-01-04 19:19:21

I am still learning about IPv6, so I may have my head up and locked, but....

fe80:: addresses are self assigned addresses that machines pick in the absence of a DHCP server. From my system:

ewaller@turing ~ 1003 %ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 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
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether d0:bf:9c:97:e9:4c brd ff:ff:ff:ff:ff:ff
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 34:e6:ad:17:fe:53 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global dynamic wlo1
       valid_lft 59598sec preferred_lft 59598sec
    inet6 2602:100:8ae5:dac6:36e6:adff:fe17:fe53/64 scope global mngtmpaddr noprefixroute dynamic
       valid_lft 593sec preferred_lft 593sec
    inet6 2602:100:8ae5:dac6:b33f:b566:7703:d2a8/64 scope global mngtmpaddr noprefixroute dynamic
       valid_lft 593sec preferred_lft 593sec
    inet6 fe80::36e6:adff:fe17:fe53/64 scope link
       valid_lft forever preferred_lft forever
ewaller@turing ~ 1004 %ping google.com
PING google.com(dfw06s48-in-x0e.1e100.net (2607:f8b0:4000:80c::200e)) 56 data bytes
64 bytes from dfw06s48-in-x0e.1e100.net (2607:f8b0:4000:80c::200e): icmp_seq=1 ttl=53 time=119 ms
64 bytes from dfw06s48-in-x0e.1e100.net (2607:f8b0:4000:80c::200e): icmp_seq=2 ttl=53 time=146 ms
64 bytes from dfw06s48-in-x0e.1e100.net (2607:f8b0:4000:80c::200e): icmp_seq=3 ttl=53 time=105 ms
64 bytes from dfw06s48-in-x0e.1e100.net (2607:f8b0:4000:80c::200e): icmp_seq=4 ttl=53 time=187 ms
^C
--- google.com ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4005ms
rtt min/avg/max/mdev = 105.265/139.615/187.050/31.165 ms
ewaller@turing ~ 1005 %

The 2602: addresses are assigned by my router. It gets that prefix from my ISP.

Edit:

From Wikipedia:

fe80::/10 — Addresses in the link-local prefix are only valid and unique on a single link. Within this prefix only one subnet is allocated (54 zero bits), yielding an effective format of fe80::/64. The least significant 64 bits are usually chosen as the interface hardware address constructed in modified EUI-64 format. A link-local address is required on every IPv6-enabled interface—in other words, applications may rely on the existence of a link-local address even when there is no IPv6 routing. These addresses are comparable to the auto-configuration addresses 169.254.0.0/16 of IPv4.

ratcheer · 2017-01-04 20:33:39

Yes, @ewaller. That was how I started (using addresses from the assigned client tunnel, 2001:470:7:a79::2/64).

But that didn't work either. My days of searching for a solution led me to find that the local addresses are preferable, because they are permanent and stable. So, to the best of my knowledge, the router can be addressed as either 2001:470:7:a79::2 or as fe80::26a2:e1ff:fee9:51bf, and the latter is preferred within the LAN.

But, in my case, neither seem to work.

Thanks,
Tim

Last edited by ratcheer (2017-01-04 22:59:36)

ewaller · 2017-01-04 22:37:38

You are correct that you should be able to hit the router using a fe80:: address. I had thought from your first post that the goal was to get to the outside; you had mentioned kame.net.
Do the other systems on your network have 2001:: addresses? You had indicated only fe80:: type addresses.

Have you access to the router logs?

ratcheer · 2017-01-04 22:59:14

The only thing I'm trying to use the fe80 address for is to get to the router. At first, I couldn't get to it by the 2001:: addresses, so I was trying the fe80. Until I can get to the router, I won't be able to do anything else. All the other hosts (which surf the outside IPv6 internet, successfully) are addressing the router by the local fe80 addresses. But, they then acquire 2001:: addresses from the router.

I also tried manually assigning 2001:470:7:a79:10:0:1:24 to my Arch system's ethernet interface. The assignment was successful, but it still didn't work.

LOL, I have no idea whether that little Apple router even has any logs. But, I will try to check on that.

tl;dr I was originally trying to get total IPv6 connectivity using systemd-networkd, systemd-resolved, and dhcpcd@enp4s0. When I failed at that after four days of researching and trying different stuff, I tried to simplify the problem and just get manual connectivity to the IPv6 router. But, I couldn't even do that.

Tim

ratcheer · 2017-01-04 23:06:07

LOL, here is what I found about logs for this router:

"You cannot.. the utility no longer has access to the log. Which is fine because the new version has no log.

The new AC version of the Extreme has no SNMP.. it is completely without resources.

See how happy this has made Apple router users.

https://discussions.apple.com/thread/5101886?tstart=0"

Arch Linux

#1 2017-01-01 02:13:58

Cannot get IPv6 address from router

#2 2017-01-01 15:48:05

Re: Cannot get IPv6 address from router

#3 2017-01-01 21:35:06

Re: Cannot get IPv6 address from router

#4 2017-01-01 23:50:14

Re: Cannot get IPv6 address from router

#5 2017-01-04 18:09:33

Re: Cannot get IPv6 address from router

#6 2017-01-04 19:19:21

Re: Cannot get IPv6 address from router

#7 2017-01-04 20:33:39

Re: Cannot get IPv6 address from router

#8 2017-01-04 22:37:38

Re: Cannot get IPv6 address from router

#9 2017-01-04 22:59:14

Re: Cannot get IPv6 address from router

#10 2017-01-04 23:06:07

Re: Cannot get IPv6 address from router

Board footer