Forum - rtadvd question :: SixXS - IPv6 Deployment & Tunnel Broker

rtadvd question

Shadow Hawkins on Friday, 07 March 2014 10:58:43

I've had an IPv6 tunnel running for a while now. Recently, client machines have not had internet access via IPv6 and I've traced this back to an issue with rtadvd. Clients are being given the correct IPv6 addresses but the router address being advertised is the getaway's link local address. Manually overriding the IPv6 router address on the client machines gets things working. I've futzed with rtadvd.conf but to no avail. I was wondering if anyone here has any pointers for me. Gateway is a Mac running 10.6.8 server. /etc/rtadvd.conf contains: en0:\ :addr="2a01:123:123::":prefixlen#64:tc=ether:noifprefix:nolladdr: And rtadvd is restarted with the -s option: sudo rtadvd -s en0 But still the link local address is being advertised as the router address. What bit of magic invocation am I missing? TIA Simon

rtadvd question

Jeroen Massar SixXS Staff

on Friday, 07 March 2014 11:04:54

the router address being advertised is the getaway's link local address.

That is completely correct.

Manually overriding the IPv6 router address on the client machines gets things working.

If you need to do that, you likely have a completely different problem.

Gateway is a Mac running 10.6.8 server.

10.6.8? That has a rather old IPv6 stack. You might want to upgrade to the 10.9 (free) which has a much updated and current one.

What bit of magic invocation am I missing?

The fix to make sure that your clients can reach the link local. As a starter, can you ping6 the gateway address from your other client hosts?

rtadvd question

Shadow Hawkins on Friday, 07 March 2014 12:52:39

the router address being advertised is the getaway's link local address.

That is completely correct.

So the gateway's IPv6 address which appears to be assigned to lo0 (as opposed to en0) is the correct one to be advertising? fe80::yadda:yadda?

Manually overriding the IPv6 router address on the client machines gets things working.

If you need to do that, you likely have a completely different problem.

As you can tell, my routing foo is not strong.

Gateway is a Mac running 10.6.8 server.

10.6.8? That has a rather old IPv6 stack. You might want to upgrade to the 10.9 (free) which has a much updated and current one.

Indeed it is. An upgrade is on the cards but it's been on the cards for a good six months now. (Work keeps on getting in the way). But let's be clear, it's been managing IPv6 routing tasks for three years now without (significant) issue.

What bit of magic invocation am I missing?

The fix to make sure that your clients can reach the link local. As a starter, can you ping6 the gateway address from your other client hosts?

If I manually change the router IPv6 address on the clients, yes. Otherwise, no. Let's back up a bit as my terminology may be off here. On the client machines, the IPv6 addresses they are given by the gateway look like 2a01.348... they are from my SixXS' subnet. However, the router address on the client machines is given as fe80::.... I am confident that the router address the client machines used to get from the gateway was from the 2a01.348... subnet which makes sense to me.

rtadvd question

Jeroen Massar SixXS Staff

on Friday, 07 March 2014 13:53:12

Simon Forster wrote:

So the gateway's IPv6 address which appears to be assigned to lo0 (as opposed to en0) is the correct one to be advertising? fe80::yadda:yadda?

That does not sound correct. You should have something like:

$ ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=3<RXCSUM,TXCSUM> inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 nd6 options=1<PERFORMNUD> ... en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV> ether aa:bb:cc:dd:ee:ff inet6 fe80::aabb:ccff:fedd:eeff%en0 prefixlen 64 scopeid 0xa inet6 2001:db8:2000::1 prefixlen 64 inet 192.0.2.1 netmask 0xffffff00 broadcast 192.0.2.255 nd6 options=1<PERFORMNUD> media: autoselect (1000baseT <full-duplex>) status: active

The gateway that your clients, attached to en0 should see is: fe80::aabb:ccff:fedd:eeff (Example MAC address used, yours will differ)

As you can tell, my routing foo is not strong.

Then time to debug and learn ;)

Indeed it is. An upgrade is on the cards but it's been on the cards for a good six months now. (Work keeps on getting in the way).

Upgrading OSX is about 60 minutes (download + waiting for it to update and 'fix' things).

If I manually change the router IPv6 address on the clients, yes. Otherwise, no.

Please show output of 'ifconfig' and 'netstat -rn' on both router and one client. (put them in [ code ] blocks as shown on the right when posting for nice formatting).

On the client machines, the IPv6 addresses they are given by the gateway look like 2a01.348... they are from my SixXS' subnet. However, the router address on the client machines is given as fe80::...

A link-local router address is completely fine and the right thing, it is directly connected afterall. Some people though sometimes configure the global unicast address as the gateway address as then the link-local/MAC-address can change without affecting all other hosts.

rtadvd question

Shadow Hawkins on Friday, 07 March 2014 17:06:47

Jeroen Massar wrote:

You should have something like:

Thanks for the datapoint. I confirmed that things looked similar to those as given in your post and then dug deeper. I think you were right. It's not simply an rtadvd issue. Also, you were right that I need to upgrade the gateway machine. And if I'm upgrading that machine, I'll need to reinstall all the IPv6 tunnelling pieces. So I decided to kill off tunnelling using the Mac and moved it to a fairly recently purchased ADSL modem which also does IPv6 tunnelling. It took about 10 minutes to set up. Everything seems to be running fine. I'll leave it at that. :-) Thanks for you help.

Please note Posting is only allowed when you are logged in.