Hi Roy,
I finally had time to try it out.
(I left all text in for reference; reply at the bottom)
On Fri 10 Jun 2016 at 08:43:19 +0100, Roy Marples wrote:
> Hi
>
> On 08/06/2016 23:07, Rhialto wrote:
> > (oops, should have sent this to tech-net@ ...)
> >
> > Can it be that if I use dhcpcd to obtain an IPv6 prefix from my router
> > (a FritzBox in my case), and it assigns the prefix::1 address to the
> > desired interface, that still no routing in that direction occurs?
> >
> > Here is my case:
> >
> > dhcpcd.conf:
> >
> > interface re0
> > noipv4
> >
> > interface re1
> > # enable routing solicitation get the default IPv6 route
> > ipv6rs
> > # also the default IPv4 route will go here
> > gateway
> > # request an IPv6 address
> > ia_na 1
> > # get a /64 and assign it to re0
> > ia_pd 2 re0/0
> >
> > ifconfig re0:
> >
> > re0: ...
> > inet 10.0.0.16 netmask 0xffffff00 broadcast 10.0.0.255
> > inet6 fe80::d63d:7eff:fe2d:6798%re0 prefixlen 64 scopeid 0x1
> > inet6 2001:984:4b2a:fc::1 prefixlen 64
> >
> > # The route to internal addresses goes to the default (i.e. wrong) interface,
> > # not to re0 as it should:
> >
> > $ route get -inet6 2001:984:4b2a:fc:226:9eff:fece:8c54
> > route to: vargaz.falu.nl
> > destination: ::
> > mask: default
> > gateway: fe80::ca0e:14ff:feee:a54b%re1
> > local addr: fe80::5008:f7e9:73dd:7e21%re1
> > interface: re1
> > flags: <UP,GATEWAY,DONE,STATIC>
> > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
> > 0 0 0 0 0 0 1492 0
> >
> > $ netstat -rn -f inet6 | grep re0
> > fe80::%re0/64 link#1 UC - - - re0
> > fe80::222:15ff:fe60:7f54 00:22:15:60:7f:54 UHLc - - - re0
> > fe80::226:9eff:fece:8c54 00:26:9e:ce:8c:54 UHLc - - - re0
> > ff01:1::/32 link#1 UC - - - re0
> > ff02::%re0/32 link#1 UC - - - re0
> >
> > $ ndp -a | grep re0
> > Neighbor Linklayer Address Netif Expire S Flags
> > murthe.falu.nl d4:3d:7e:2d:67:98 re0 permanent R
> > fe80::222:15ff:fe60:7f54%re0 00:22:15:60:7f:54 re0 23h33m53s S
> > fe80::226:9eff:fece:8c54%re0 00:26:9e:ce:8c:54 re0 23h48m9s S
> > fe80::d63d:7eff:fe2d:6798%re0 d4:3d:7e:2d:67:98 re0 permanent R
>
> So it looks like the route to 2001:984:4b2a:fc is on the wrong
> interfacce. You've not shown the whole routing table, but is it by any
> chance on lo0 as a reject route?
Here is the full routing table. It doesn't seem to contain any route for
that address at all. My interpretation was that the default route was
chosen for my query.
Routing tables
Internet6:
Destination Gateway Flags Refs Use Mtu Interface
::/104 ::1 UGRS - - - lo0
::/96 ::1 UGRS - - - lo0
default fe80::ca0e:14ff:feee:a54b UGS - - 1492 re1
::1 ::1 UH - - 33648 lo0
::127.0.0.0/104 ::1 UGRS - - - lo0
::224.0.0.0/100 ::1 UGRS - - - lo0
::255.0.0.0/104 ::1 UGRS - - - lo0
::ffff:0.0.0.0/96 ::1 UGRS - - - lo0
2001:984:4b2a:1:1d38:3900:5871:2a5c 00:e0:4c:1f:96:8e UHL - - - lo0
2001:984:4b2a:1:5008:f7e9:73dd:7e21 00:e0:4c:1f:96:8e UHL - - - lo0
2001:984:4b2a:fc::1 d4:3d:7e:2d:67:98 UHL - - - lo0
2001:db8::/32 ::1 UGRS - - - lo0
2002::/24 ::1 UGRS - - - lo0
2002:7f00::/24 ::1 UGRS - - - lo0
2002:e000::/20 ::1 UGRS - - - lo0
2002:ff00::/24 ::1 UGRS - - - lo0
fc00::/7 ::1 UGRS - - - lo0
fe80::/10 ::1 UGRS - - - lo0
fe80::%re0/64 link#1 UC - - - re0
fe80::d63d:7eff:fe2d:6798 d4:3d:7e:2d:67:98 UHL - - - lo0
fe80::%re1/64 link#2 UC - - - re1
fe80::1268:3fff:fe4d:8134 10:68:3f:4d:81:34 UHLc - - - re1
fe80::5008:f7e9:73dd:7e21 00:e0:4c:1f:96:8e UHL - - - lo0
fe80::ca0e:14ff:feee:a54b c8:0e:14:ee:a5:4b UHLc - - - re1
fe80::%lo0/64 fe80::1 U - - - lo0
fe80::1 link#3 UHL - - - lo0
ff01:1::/32 link#1 UC - - - re0
ff01:2::/32 link#2 UC - - - re1
ff01:3::/32 ::1 UC - - - lo0
ff02::%re0/32 link#1 UC - - - re0
ff02::%re1/32 link#2 UC - - - re1
ff02::%lo0/32 ::1 UC - - - lo0
> I've made some fixes for PD upstream and show hopefully be releasing a
> new version next week. Can you test a snapshot for me please to see if
> it fixes it?
>
> http://roy.marples.name/projects/dhcpcd/tarball/dhcpcd-trunk.tar.gz
> (login as anonymous first)
Ok, trying that now. I get as output:
murthe.3:/tmp/dhcpcd-trunk$ sudo ./dhcpcd --debug --lastlease re1 re0
dhcpcd-6.11.0 starting
re0: disabling Kernel IPv6 auto link-local support
re0: disabling Kernel IPv6 RA support
re0: executing `/libexec/dhcpcd-run-hooks' PREINIT
re0: executing `/libexec/dhcpcd-run-hooks' CARRIER
re1: executing `/libexec/dhcpcd-run-hooks' PREINIT
re1: executing `/libexec/dhcpcd-run-hooks' CARRIER
DUID 00:01:00:01:1e:44:c7:c1:00:e0:4c:1f:96:8e
re0: IAID 7e:2d:67:98
re1: IAID 4c:1f:96:8e
re1: IAID 00:00:00:01
re1: IAID 00:00:00:02
re1: delaying IPv6 router solicitation for 0.4 seconds
re1: reading lease `/var/db/dhcpcd-re1.lease6'
re1: rebinding prior DHCPv6 lease
re1: delaying REBIND6 (xid 0x7e1789), next in 0.0 seconds
re1: delaying IPv4 for 0.2 seconds
re1: broadcasting REBIND6 (xid 0x7e1789), next in 1.0 seconds
re1: REPLY6 received from fe80::ca0e:14ff:feee:a54b
re1: adding address 2001:984:4b2a:1:5008:f7e9:73dd:7e21/128
re1: pltime 3600 seconds, vltime 7200 seconds
re1: renew in 1800, rebind in 2880, expire in 7200 seconds
lo0: adding reject route to 2001:984:4b2a:fc::/62 via ::1
re1: writing lease `/var/db/dhcpcd-re1.lease6'
re1: delegated prefix 2001:984:4b2a:fc::/62
re0: adding address 2001:984:4b2a:fc::1/62
re0: pltime 3600 seconds, vltime 7200 seconds
if_addaddress6: Invalid argument
re0: changing route to 2001:984:4b2a:fc::/62
re0: executing `/libexec/dhcpcd-run-hooks' DELEGATED6
re1: executing `/libexec/dhcpcd-run-hooks' REBIND6
forking to background
forked to background, child pid 9146
The "if_addaddress6: Invalid argument" seems worrying.
On the other hand, I never got "
re1: delegated prefix 2001:984:4b2a:fc::/62
re0: adding address 2001:984:4b2a:fc::1/62
before (according to grep on my syslog files).
And I do seem to have an additional route entry:
2001:984:4b2a:fc::/62 link#1 UC
- - - re0
Full netstat -rn -f inet6 now, after stopping the old dhcpcd and
starting the new one:
Routing tables
Internet6:
Destination Gateway Flags Refs Use Mtu Interface
::/104 ::1 UGRS - - - lo0
::/96 ::1 UGRS - - - lo0
default fe80::ca0e:14ff:feee:a54b UGS - - 1492 re1
::1 ::1 UH - - 33648 lo0
::127.0.0.0/104 ::1 UGRS - - - lo0
::224.0.0.0/100 ::1 UGRS - - - lo0
::255.0.0.0/104 ::1 UGRS - - - lo0
::ffff:0.0.0.0/96 ::1 UGRS - - - lo0
2001:984:4b2a:1:1d38:3900:5871:2a5c 00:e0:4c:1f:96:8e UHL - - - lo0
2001:984:4b2a:1:5008:f7e9:73dd:7e21 00:e0:4c:1f:96:8e UHL - - - lo0
2001:984:4b2a:fc::/62 link#1 UC - - - re0
2001:984:4b2a:fc::1 d4:3d:7e:2d:67:98 UHL - - - lo0
2001:db8::/32 ::1 UGRS - - - lo0
2002::/24 ::1 UGRS - - - lo0
2002:7f00::/24 ::1 UGRS - - - lo0
2002:e000::/20 ::1 UGRS - - - lo0
2002:ff00::/24 ::1 UGRS - - - lo0
fc00::/7 ::1 UGRS - - - lo0
fe80::/10 ::1 UGRS - - - lo0
fe80::%re0/64 link#1 UC - - - re0
fe80::226:9eff:fece:8c54 00:26:9e:ce:8c:54 UHLc - - - re0
fe80::d63d:7eff:fe2d:6798 d4:3d:7e:2d:67:98 UHL - - - lo0
fe80::%re1/64 link#2 UC - - - re1
fe80::5008:f7e9:73dd:7e21 00:e0:4c:1f:96:8e UHL - - - lo0
fe80::ca0e:14ff:feee:a54b c8:0e:14:ee:a5:4b UHLc - - - re1
fe80::f90a:1570:1786:538d 5c:e0:c5:bc:25:b4 UHLc - - - re1
fe80::%lo0/64 fe80::1 U - - - lo0
fe80::1 link#3 UHL - - - lo0
ff01:1::/32 link#1 UC - - - re0
ff01:2::/32 link#2 UC - - - re1
ff01:3::/32 ::1 UC - - - lo0
ff02::%re0/32 link#1 UC - - - re0
ff02::%re1/32 link#2 UC - - - re1
ff02::%lo0/32 ::1 UC - - - lo0
So this looks like a nice improvement.
Thanks!
> Roy
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl -- are condemned to reinvent it. Poorly.
Attachment:
signature.asc
Description: PGP signature