ipv6 routing and neighbour discovery

Hi all,

I've just spent a good afternoon setting up a 6to4 tunnel so I can
finally start enjoying the wonders of the wider world :)

Basic network functionality from my server is working, but I can't seem
to get my desktop behind it configured correctly... any pointers are
appreciated. So here's my setup:

desktop|eth0 <---> ethi|server|ethe <---> WAN

with the following addresses (manually) assigned:

eth0: <6to4>::2/16
ethi: <6to4>::35/16
ethe: <6to4>::1/16
(<6to4> is currently 2002:5571:f9d3, but this is better readable).

From the server, I can ping all three addresses without a problem. From
the desktop machine, I can ping the ::35 address (the LAN side of the
server), but I cannot ping the ::1 side; it says Address Unreachable.

The neighbour list from the desktop machine:
2002:5571:f9d3::1 dev eth0 ref 1 used 0/0/0 FAILED
2002:5571:f9d3::35 dev eth0 lladdr 00:40:63:d9:d4:12 router ref 2 used
0/0/0 REACHABLE

And from the server:
2002:5571:f9d3::2 dev ethi lladdr 00:0b:6a:56:4f:c2 ref 2 used 2/2/2
REACHABLE

Now I don't have a sniffer on the server currently, so I tried to abuse
netfilter for it (logging every ICMP packet with type 135 and 136).
Here's the results:

pinging the desktop from the server:
SRC=::35 DST=ff02::1:ff00:2 PROTO=ICMPv6 TYPE=135
SRC=::2 DST=::35 PROTO=ICMPv6 TYPE=136
SRC=fe80::<eth0> DST=::35 PROTO=ICMPv6 TYPE=135
SRC=::35 DST=fe80::<eth0> PROTO=ICMPv6 TYPE=136
SRC=fe80::<ethi> DST=fe80::<eth0> PROTO=ICMPv6 TYPE=135
SRC=fe80::<eth0> DST=fe80::<ethi> PROTO=ICMPv6 TYPE=136

etc. Now, pinging the ethi address from the desktop works pretty much
the same way. But when I try to ping the ethe side (::1), I get only
this in the logs:

SRC=::2 DST=ff02::1:ff00:1 PROTO=ICMPv6 TYPE=135
SRC=::2 DST=ff02::1:ff00:1 PROTO=ICMPv6 TYPE=135
SRC=::2 DST=ff02::1:ff00:1 PROTO=ICMPv6 TYPE=135

in other words, the server never replies. I'm logging all interfaces, so
I'm pretty sure it's not a misconfigured route on the server. ip6tables
(pruned):

Chain INPUT (policy DROP 448 packets, 32096 bytes)
289 23104 ACCEPT all ethi any anywhere anywhere
Chain FORWARD (policy DROP 0 packets, 0 bytes)
Chain OUTPUT (policy ACCEPT 528 packets, 53380 bytes)


last question, slightly off-topic: why must 6to4 be configured with a
/16 prefix (according to TLDP, this is very important)? I'd think a
/48-prefix would be equally suitable...

Thanks,
Arno
.

Relevant Pages

  • Re: iptables help needed
    ... These logged packets are when Evolution is fetching the ... is the IP address of the laptop ... side-effect of your provider running a "no servers" policy, ... worked fine only a few weeks ago, so any "no server" policy shouldn't ...
    (Fedora)
  • Re: Diagnose co-location networking problem
    ... it was from the client. ... Actually there's significant indication of lost packets and clues that ... 540 retransmit timeouts ... are you using any packetfiltering on the server? ...
    (freebsd-net)
  • Re: Dns bind9 not foward
    ... I attach my log files about query with dig to opendns server. ... Chain FORWARD (policy ACCEPT 0 packets, ...
    (Debian-User)
  • Re: FC4 NTPD problem
    ... > server xxxxxxx.xxx ... > restrict xxxxxxx.xxx mask 255.255.255.255 nomodify notrap noquery ... Chain FORWARD (policy ACCEPT) ...
    (Fedora)
  • Re: Improving FreeBSD NFS performance (esp. directory updates)
    ... >> I don't think the network is at fault, nor is the server really going ... 155645171 data packets ... discarded for bad header offset fields ... 790 connections established ...
    (freebsd-questions)