I'm having trouble connecting updating the software list and it seems to be an IPv6 issue on the router only. IPv6 works on my LAN and from the router I can ping local ipv6 addresses but I can't ping internet IPv6 addresses. I'm assuming it's a firewall or default route for local host but I just can't figure this last bit out.
/etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdf1:2909:14cc::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
option mtu '1500'
option mtu6 '1500'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
option ip6hint '10'
list dns_search 'ttfn'
config interface 'wan'
option device 'eth1'
option proto 'dhcp'
option peerdns '0'
list dns '208.67.222.123'
list dns '208.67.220.123'
config interface 'wan6'
option device 'eth1'
option proto 'dhcpv6'
list dns '2620:119:35::35'
list dns '2620:119:53::53'
option reqaddress 'force'
option reqprefix '56'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '1 2 3 4 0'
config device
option name 'wlan2'
option mtu '1500'
option mtu6 '1500'
config device
option name 'wlan1'
option mtu '1500'
option mtu6 '1500'
config device
option name 'wlan0'
option mtu '1500'
ip -r route
default from 2606:5d00:9001::2815 via fe80::1 dev eth1 metric 384
default from 2606:5d00:9001::/64 via fe80::1 dev eth1 metric 384
default from 2606:5d00:9808:e400::/56 via fe80::1 dev eth1 metric 384
2606:5d00:9001::/64 dev eth1 metric 256
unreachable 2606:5d00:9001::/64 dev lo metric 2147483647
2606:5d00:9808:e410::/64 dev br-lan metric 1024
unreachable 2606:5d00:9808:e400::/56 dev lo metric 2147483647
fdf1:2909:14cc:10::/64 dev br-lan metric 1024
unreachable fdf1:2909:14cc::/48 dev lo metric 2147483647
fe80::/64 dev br-lan metric 256
fe80::/64 dev eth1 metric 256
fe80::/64 dev wlan1 metric 256
fe80::/64 dev wlan2 metric 256
fe80::/64 dev wlan0 metric 256
anycast 2606:5d00:9001:: dev eth1 metric 0
anycast 2606:5d00:9808:e410:: dev br-lan metric 0
anycast fdf1:2909:14cc:10:: dev br-lan metric 0
anycast fe80:: dev br-lan metric 0
anycast fe80:: dev eth1 metric 0
anycast fe80:: dev wlan1 metric 0
anycast fe80:: dev wlan2 metric 0
anycast fe80:: dev wlan0 metric 0
multicast ff00::/8 dev br-lan metric 256
multicast ff00::/8 dev eth1 metric 256
multicast ff00::/8 dev wlan1 metric 256
multicast ff00::/8 dev wlan2 metric 256
multicast ff00::/8 dev wlan0 metric 256
It is not necessary to configure ip6assign on wan6 interface. wan6 already has an IPv6, the one ending in 2815 in the first line of ip -6 route output.
However, under normal circumstances the traffic originating from the router will use as source IP the lowest one allocated to a lan interface.
If so, the gateway seems to be link-local; and therefore was incorrect.
True, we discussed that for an issue I had once with a remote IPv6 server and 2 local IPv6 WANs. In this case though, I see no other valid IPv6 gateway/default-route in the table for which the wan6 router's IPv6 addresses to reach (as wan6 is where the Internet exists). The existence of that link-local route is a function of the OP having requested a Prefix Delegation and the router "claiming it" for its IPv6 routing.
DHCPv6 does not provide the address, subnet mask, and default gateway that DHCP for IPv4 does.
You must still want obtain/announce an assignment thru RA/SLAAC on via a valid wan6 Internet interface to obtain a valid gateway.
Correct, the Internet is not on LAN, it's on wan6 (recall those are link-local IPs).
I've also edited the post marked as the solution to correctly reflect "valid gateway" instead of the IP address that was assigned (which it had received a CIDR via PD, making your statement true). My sincere apologies for the confusion.
Sure, but this is done by the ISP. And if there is any confusion, the dhcpv6 protocol mentioned in OpenWrt is a combination of RA+DHCP6, not plain DHCP6.
It is not on the lan, as eth1 is the wan interface. I believe you are confusing the from prefix which is used for the source validation.
The link-local IP can be used as a gateway. Eventually the router only needs to use the mac of the gateway to forward the packet, it doesn't actually care for the IP of the gateway.
My apologies. No I'm not confused. I made another assumption that you were aware fe80::1 is a special [anycast] address and not a dynamically-assigned host IP. Perhaps this link will better explain fe80::1. Also, regarding my "Internet is not on LAN" comment, see:
A better wording may be "the Internet is not on the Kernel (or all interfaces), it's on wan6".
One method to make things easier is to manually assign the link-local address to the upstream router’s interfaces. If you assign the link-local address FE80::1 on each of its interfaces and if that link-local address is unique on each of those LAN segments, then this becomes the default gateway for the hosts on those LANs. Therefore, each host, no matter on which LAN, will see FE80::1 as the next-hop IPv6 address for the default route in its routing table.
root@OpenWrt:~# ip route get fe80::1/64
fe80::1 from :: dev eth0 proto kernel src fe80::yyyy:xxxx:xxxx:xxxx metric 256 pref medium
root@OpenWrt:~# ip route get fe80::
anycast fe80:: from :: dev lo table local proto kernel src fe80::yyy:xxxx:xxxx:xxxx metric 0 pref medium
As you can see:
that is a special IP
that network exists on all of the OP's interfaces (hence my comment "the Internet is not on LAN")
The SRC IP is not Global
(in my case) as you see, the corresponding link-local is not in the same subnet
additionally, my eth0 is the local-facing interface which is tagged VLANs.
Most importantly for this thread, fe80::1 doesn't seem to be the ISPs router's (valid, manually-assigned) upstream link-local IP on wan6, the EUI64 probably is - which is normal
Try: ip route get oif <PHY> fe80::1 to see what I mean.
Also try: ping6 :: - (i.e. the IPv4 equivalent of ping 0.0.0.0. If you're not used to the subtle differences of IPv6 addressing/routing, the response might freak you out!
Every interface with enabled IPv6 has a link local address. ip -6 addr
I beg to differ that
is in fact global.
Again you are confusing something. All IPv6 enabled interfaces have a link local address in the fe80::/64. There is no point to do a ip route get for link local IPs.
It is the next hop and that is all we care.
I don't see how these are connected to the problem that we are discussing.
Apolgies I'm being unclear. Nonetheless the solution exists.
I'm not sure why ip route didn't make things clear and show you fe80::1 is a non existent anycast address. Therefore the fe80::1 gateway is ivnalid in this case because it's likely not the IP set on ISP side (the unicast EUI64 like normal seems to be).
I also knew fe80::1 was a "red flag" because in IPv6 lessons - it was noted about the possible use of manual/static assignment of this anycast address for "all valid routers on this network".
???
I never said the 2606::xxx wasnt global. I'm not sure how you got that. It's an IP issued by PD as I noted already.
Nonetheless, the OP's issue is solved by getting a valid gateway with a proper config. Glad it's working. Feel free to PM me if you're still confused or want links to more clear resources, RFCs, etc.
If the OP wants to show the new ip -6 route - it would provide definitive clarity.
Edit: Maybe I should note that I think it's possible the PD/DHCPv6 server of the OP's ISP may be 2 separate devices from the router itself. An fe80::1 (improperly configured or something) may have issued the PD (server) - but not the gateway (RA on router). In any case fe80::1 is valid for "no gateway but global IPs" - I knew instantly. Which I was more clear, though.
I would not call it anycast, more like a virtual IP in terms of high availability. But this is not that important.
No they are not. All link local addresses are in fe80::/64 and wan6 interface also has one as we can see in the routing table.
Then to which SRC IP are you referring?
I can provide you with mine, and maybe you can explain to me why it is working without adding the ip6assign on the wan6.
root@barracuda:[~]#ip -6 ro
default from 2001:1234:5e:16a::/64 dev 6in4-henet proto static metric 550 pref medium
default from 2001:1234:5f:16a::/64 dev 6in4-henet proto static metric 550 pref medium
default from 2a0f:6789:abc:75::/64 via fe80::30 dev pppoe-wan proto static metric 512 pref medium
default from 2a0f:6789:abc:7500::/56 via fe80::30 dev pppoe-wan proto static metric 512 pref medium
2001:470:20::2 via 2001:1234:5e:16a::1 dev 6in4-henet proto static metric 550 pref medium
2001:1234:5e:16a::/64 dev 6in4-henet proto static metric 550 pref medium
2001:1234:5f:16a::/64 dev eth0.3 proto static metric 1024 pref medium
unreachable 2001:1234:5f:16a::/64 dev lo proto static metric 2147483647 pref medium
2a00:1450:4001:809::200e dev pppoe-wan proto static metric 512 pref medium
unreachable 2a0f:6789:abc:75::/64 dev lo proto static metric 2147483647 pref medium
2a0f:6789:abc:7500::/64 dev br-lan proto static metric 11 pref medium
2a0f:6789:abc:7530::/64 dev eth0.3 proto static metric 1024 pref medium
unreachable 2a0f:6789:abc:7500::/56 dev lo proto static metric 2147483647 pref medium
fd00:bbbb::/64 dev br-lan proto static metric 11 pref medium
fd00:bbbb:0:20::/64 dev eth0.2 proto static metric 1024 pref medium
fd00:bbbb:0:30::/64 dev eth0.3 proto static metric 1024 pref medium
unreachable fd00:bbbb::/48 dev lo proto static metric 2147483647 pref medium
fd00:bbbb:10::/64 dev roadwarrior proto kernel metric 256 pref medium
fd00:cccc::/64 dev elvetias proto kernel metric 256 pref medium
fe80::30 dev pppoe-wan metric 1 pref medium
fe80::80e2:544d:1f68:75b0 dev pppoe-wan proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0.2 proto kernel metric 256 pref medium
fe80::/64 dev eth0.3 proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
fe80::/64 dev 6in4-henet proto kernel metric 256 pref medium
fe80::/64 dev ifb4pppoe-wan proto kernel metric 256 pref medium
unreachable fc00::/6 dev lo proto static metric 240 pref medium
config interface 'wan'
option device 'eth1'
option proto 'pppoe'
option username 'user'
option metric '10'
option password 'pass'
option keepalive '6 10'
option ipv6 '1'
option peerdns '0'
config interface 'wan6'
option proto 'dhcpv6'
option macaddr '00:1e:10:1f:00:00'
option clientid '00030001001e101f0000'
option reqprefix 'auto'
option reqaddress 'none'
option device '@wan'
option peerdns '0'
option metric '512'
Aaah! I was referring to the link local (which I agree must in the same fe80::/64, apologies). I was specifically referring to the fact that the fe80::1 existed on the table and not an [Globally-unique] EUI64 (apparently seen on the ISP-side). I actually spotted that instantly. My wording was indeed poor there.
Absolutely! As we discussed here - both of your IPv6 interfaces have the "gift" I was wishing for:
You do not need a Layer 2 gateway (via Ethernet) specified as the destination to send your routes. You have a PPPoE (point-to-point) interface or HE Tunnel. If the SRC are the ISP-issued addresses, your router merely throws them at the PPPoE, or HE IP to HE tunnel respectively.
On Ethernet IPv6 there's a concept of mutiple routers in existence, anycast receipt of forwarded packets, new router sends RAs, etc. - and nonetheless in any case, just like IPv4, you must specify the Layer 2 gateway with a valid Layer 3 address.
Basically fe80::1 doesn't seem the valid hop to OP's ISP IPv6 gateway as announced by RA. Your protocols don't need an RA for a gateway and none of your global IPv6 addresses are issued over a pure Ethernet link - where other devices could physically exist but merely be OPs IPv6 neighbors (i.e. a neighbor's router on the same customer ISP broadcast domain).
There is no such thing as Layer 2 gateway. If there is ethernet uplink connection, like in your case or the OP's, there is a Layer 3 gateway and via arp in IPv4 or neighbour discovery in IPv6 you find the mac address of the destination to form the ethernet frame and send it. In my case of pppoe, the step of arp request or neighbor solicitation is not taking place.
The concept exists in IPv4 as well, look at first hop redundancy protocols, like HSRP, VRRP, GLBC.
It is a valid hop as explained in the link earlier. Whether it is assigned to one router or it is used as virtual IP by many doesn't change much.
To take a step back, because we have deviated from my initial observation, what you achieve with ip6assign on the wan6 interface is to allocate it an IP from the delegated prefix. That's all. It doesn't change the gateway. Most likely the problem the OP has is that the IPv6 address the wan6 interface has acquired by the ISP is not allowed to be routed, but delegated IPs are. And with the addition of ip6assign on the wan6 interface, the router is using the delegated IPv6 as source for locally originated packets.
Trendy we debated layer 2 or 3 the last time. So I used your terminologies.
Good day on this thread, ill PM you or just direct you to any guide to address an Ethernet client with an IP address and gateway for Internet connectivity.
I'm not sure if this pretending not to follow addressing an Ethernet device with a simple IP and Gateway for Internet is being done on purpose, or likely I'm just unclear - so it's best to direct message to pursue this fruther. Thanks.
That requires a RA with the correct gateway IPv6 to proceed with that notion, I hope you agree (direct message to discuss if not). You get an RA thru...configuring your device to request an assignment.
Yet I never used the term layer 2 gateway, as there is no such thing.
I'm not fooling around here. I might as well be wrong so I wouldn't mind taking a second opinion. Feel free to invite someone else here to share their view.
