#17510: /60 rather than /64 IPv6 'interface' route created on LAN interface
-----------------------------+-----------------------------------
Reporter: markzzzsmith@… | Owner: developers
Type: defect | Status: reopened
Priority: normal | Milestone:
Component: base system | Version: Barrier Breaker 14.07
Resolution: | Keywords:
-----------------------------+-----------------------------------
Comment (by cyrus):
No the issue I'm talking about is not an issue of understanding IPv6. I
know most of the trickery regarding on-link and off-link and DHCPv6
clients not honoring that or not honoring lifetimes etc. and were having
lots of fun with it until I decided I was just sick of it wrote DHCPv6 and
RA clients, servers and relays from scratch for OpenWrt.
The on-link route bug I'm talking about can actually be recreated very
easily:
ip a a 2001:db80::1/64 dev eth0 valid_lft 1200 preferred_lft 600
ip a d 2001:db80::1/64 dev eth0
ip -6 r l dev eth0
You will see that while the address gets removed by the second call the
on-link route still remains. Omit the valid_lft and preferred_lft in the
first call and the second call with remove both address and on-link route
correctly. One of the many funny IPv6 issues in the linux kernel, besides
IPV6_PKTINFO sometimes not working for RAW-sockets, Linux not accepting
MSRs / Route Info Options by default for no objective reason etc. etc.
Interesting matter in the draft though I don't really like the relaying
approach. FYI we try to handle the issue in homenet as well. See
http://tools.ietf.org/html/draft-ietf-homenet-hncp-01 (which I co-
authored) and a colleague's draft http://tools.ietf.org/html/draft-
pfister-homenet-prefix-assignment-02 where (as one out of many aspects) we
pick-up dhcpv6-options from uplinks and share and announce them to clients
in the whole homenet. Of course you can run into clashes when you have
multiple uplinks with conflicting information but that's something for the
mif-workinggroup to figure out. There is just no good solution for that
atm.
As for PPP and IPv6, I've enabled IPv6CP in trunk by default now (see
r42158) but won't do it for the BB-release since there are some weird ISP
servers that just kill the whole PPP session when they encounter an IPv6CP
handshake, so I want to see the actual effects in our unstable branch
before hand. In the BB-branch you simply have to set:
option ipv6 1 in the PPP-section in addition to having the wan6-interface
section which triggers our RA / DHCPv6 client to be run on-top.
--
Ticket URL: <https://dev.openwrt.org/ticket/17510#comment:10>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
