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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> Arno Schuring writes:
Arno> Hi all,

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

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

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

Arno> with the following addresses (manually) assigned:

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

All you need is to assign ethi, a subnet prefix from your 6to4 IPv6
prefix assigned to ethe. And enable IPv6 forwarding by setting
'net.ipv6.conf.all.forwarding' option (using sysctl) to '1'. e.g. your
ethi can be <6to4>:1::1/64, and eth0 could be <6to4>:1::2/64. After
you enable IPv6 forwarding, you're able to ping any ethe's IPv6
address from your 'desktop'.

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

If you assign a /16 prefix, then only non-2002::/16 address will be
routed via gateway, which is desired. Since all 2002::/16 address are
nothing but IPv4 hosts accepting 6to4 protocol's packets. So no need
to go via 6to4 relay, if target host is reachable via IPv4.

Arno> Thanks,
Arno> Arno

Happy IPv6-ing

HTH
- --
Ashish Shukla आशीष श�क�ल http://wahjava.wordpress.com/
·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHxwz5Hy+EEHYuXnQRAqXYAJ9BPjvCt3CsQ7P2gXtp7f XX0xXBHQCg7w5u
93jWRA45npKpjGIb/nczcls=
=a2Db
-----END PGP SIGNATURE-----

Hello,

Arno Schuring a écrit :
>
> I've just spent a good afternoon setting up a 6to4 tunnel so I can
> finally start enjoying the wonders of the wider world
>
> desktop|eth0 <---> ethi|server|ethe <---> WAN

Where is the 6to4 tunnel interface ?

> with the following addresses (manually) assigned:
>
> eth0: <6to4>::2/16
> ethi: <6to4>::35/16
> ethe: <6to4>::1/16

The prefix and lengths are wrong. First, the /16 prefix length must be
only on the 6to4 interface : 2002::/16 represents the whole 6to4 world.
Prefix length on an ethernet network is usually /64.
Second, you must have a different prefix on each network, as in IPv4.
Here ethi and ethe have the same prefix, which is wrong and leads to
confusion such as : is <6to4>:<whatever> reachable on ethi or ethe ?

2000::/3 is the current IPv6 global space (may grow bigger)
2002::/16 is the whole 6to4 address space
2002:5571:f9d3::/48 is your whole 6to4 prefix, from which you allocate a
/64 prefix for each LAN segment.

> From the server, I can ping all three addresses without a problem.

Well, you must be lucky. :-) It could have happened that you can not
even reach the desktop if the server had thought that it was reachable
on ethe instead of ethi.

Your neighbor discovery (ND) problems come from the wrong prefix
allocation. E.g. the desktop thinks that <6to4>::1 is on the network
directly attached to eth0 but it is not. Also note that unlike ARP ND
does not use link-layer broadcasts but specific link-layer multicasts
derived from the queried IPv6 address, so unlike in IPv4 a host may not
reply to ND queries for any of its local addresses received on any of
its interfaces.

Pascal, Ashish,

Thanks to both of you for the input. It's actually basic subnetting
rules that I neglected to follow. I know have a working IPv6 setup

Pascal Hambourg wrote:

>> desktop|eth0 <---> ethi|server|ethe <---> WAN
>
> Where is the 6to4 tunnel interface ?
You probably would've guessed correctly; it's a tunnel over ethe (the
only public address)

> Second, you must have a different prefix on each network, as in IPv4.
> Here ethi and ethe have the same prefix, which is wrong and leads to
> confusion such as : is <6to4>:<whatever> reachable on ethi or ethe ?
Yes, I seem to have messed up on my subnetting 101: never use the same
subnet on both sides of a router/gateway

> Well, you must be lucky. :-) It could have happened that you can not
> even reach the desktop if the server had thought that it was reachable
> on ethe instead of ethi.
Well it got me confused on this one. If I hadn't been so lucky I might
have realized my mistake sooner...


Thanks again,
Arno

"Arno Schuring" <(E-Mail Removed)> wrote in message
news:eacc3$47c7026a$5571f9d3$(E-Mail Removed) l...
> ...
> 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...

Your "local network" is the /48. The full 6to4 network is a /16. What the
code for the sit interfaces (really, just "sit0") does is if it doesn't have
a predetermined tunnel endpoint, it checks to see if the IPv6 address it's
trying to route is a "2002::/16", and if so, it auto-extracts the embedded
IPv4 from the 17-48th bits and copies that into the encapsulating IPv4
header. (It also performs a similar operation for "::/96" addresses other
than "::" and "::1", copying bits 97-128). Using "::192.88.99.1" for 6to4
addresses makes the network path LONGER than it has to be - because a direct
auto-tunnel is (presumed) available.

Don't forget to register your subnet at https://6to4.nro.net/ so that the
reverse DNS lookups work and any e-mail sent via IPv6 won't be rejected on
that basis.

Agreeing with other replies: The 6to4 address(es) should be assigned to the
"sit0" interface, not to "eth#". The ethernet interfaces should have only
NATIVE IPv6 addresses that come via your ISP (or other Internet connection
provider). Tunnel broker IPv6 addresses should be assigned to other "sit#"
addresses.

Don't forget: Auto-discovery will need these following packets to pass
through a firewall (iptables format):
-p icmp6 -s fe80::/10 -d fe80::/10 -j ACCEPT
-p icmp6 -s fe80::/10 -d ff00::/11 -j ACCEPT
-p icmp6 -s ::/128 -d ff00::/11 -j ACCEPT
Note that these rules are the same for both the INPUT and OUTPUT tables (and
the values are NOT swapped for output). The rules can further be limited to
neighbor and router discovery ICMP types, but probably left open to echo
types (for pings). As the first 2 rules specify sources of "fe80::/10",
only directly connected neighbors are permitted. For the really paranoid,
one could add a check of the TTL/hop-countdown field (=255). The last rule
is so that a host that doesn't yet know its IP address can request one - or
services requests from others (and it could be tuned to a destination like
"ff00::2/128" but I left it a bit more open so that other services within
the host that also need to auto-configure could do so).

D. Stussy a écrit :
>
> Agreeing with other replies: The 6to4 address(es) should be assigned to the
> "sit0" interface, not to "eth#". The ethernet interfaces should have only
> NATIVE IPv6 addresses that come via your ISP (or other Internet connection
> provider). Tunnel broker IPv6 addresses should be assigned to other "sit#"
> addresses.

Nonsense. Neither Ashish Shukla nor me said so.
You can use 6to4 (or tunnel broker assigned) IPv6 addresses inside your
network just as native global IPv6 addresses. You can subnet the 6to4
prefix on each LAN in your network and assign addresses from each subnet
to LAN interfaces of your hosts.

6to4 grants a /48 IPv6 prefix to any public IPv4 address. What would be
the use of such a range if a 6to4 address could only be assigned to the
tunnel interface, i.e. to the host owning the public IP address ? A
much smaller range would be enough (more than one, i.e. for virtual host
purpose).

"Pascal Hambourg" <boite-a-(E-Mail Removed)> wrote in message
news:fqj5ut$2nns$(E-Mail Removed)...
> D. Stussy a écrit :
> >
> > Agreeing with other replies: The 6to4 address(es) should be assigned to
the
> > "sit0" interface, not to "eth#". The ethernet interfaces should have
only
> > NATIVE IPv6 addresses that come via your ISP (or other Internet
connection
> > provider). Tunnel broker IPv6 addresses should be assigned to other
"sit#"
> > addresses.
>
> Nonsense. Neither Ashish Shukla nor me said so.

>> "First, the /16 prefix length must be only on the 6to4 interface :
2002::/16 represents the whole 6to4 world."

With that statement, I thought you had. Also, if you don't put the 6to4
address on the sit0 interface, it does work but the route that gets
auto-added (for other than a /128) gets added to the wrong interface and the
auto-lookup for the embedded IPv4 remote tunnel end breaks, unless you also
manually add "2002::/16" to sit0.

> You can use 6to4 (or tunnel broker assigned) IPv6 addresses inside your
> network just as native global IPv6 addresses. You can subnet the 6to4
> prefix on each LAN in your network and assign addresses from each subnet
> to LAN interfaces of your hosts.
>
> 6to4 grants a /48 IPv6 prefix to any public IPv4 address. What would be
> the use of such a range if a 6to4 address could only be assigned to the
> tunnel interface, i.e. to the host owning the public IP address ? A
> much smaller range would be enough (more than one, i.e. for virtual host
> purpose).

That's why you use smaller subnets than a /48 when attaching it to other
interfaces if you're using one IPv4's 6to4 equivalent for an entire network.
However, you still need the 2002::/16 route on sit0 for it to work with
OTHER PEOPLE's 6to4 addresses. Additionally, you will have at least one
address for your local host, and it really belongs on sit0 = so no reason
not to "ifconfig sit0 inet6 add 2002:xxxx:xxxx::1\16" where it's supposed to
be. Unlike IPv4, an interface can have multiple IPv6 addresses assigned to
it.

D. Stussy a écrit :
>
> Also, if you don't put the 6to4
> address on the sit0 interface, it does work but the route that gets
> auto-added (for other than a /128) gets added to the wrong interface and the
> auto-lookup for the embedded IPv4 remote tunnel end breaks, unless you also
> manually add "2002::/16" to sit0.

Of course the sit interface must have the 2002::/16 route. I did not say
otherwise. This does not mean that the sit interface must have a 6to4
address or other interfaces must not have 6to4 addresses.

> However, you still need the 2002::/16 route on sit0 for it to work with
> OTHER PEOPLE's 6to4 addresses.

Correct.

> Additionally, you will have at least one
> address for your local host, and it really belongs on sit0

No, it can be assigned to any interface. If the output interface has no
suitable address, the network stack will use a suitable address from
another interface. I.e. if you assigned a 6to4 address only to the LAN
interface, this address can be used for communications on the sit interface.

> = so no reason not to "ifconfig sit0 inet6 add 2002:xxxx:xxxx::1\16"
> where it's supposed to be.

One reason : it is not required when the host already has a 6to4 address
assigned to another interface.
Besides, why assign 2002:xxxx:xxxx::1 and not any other address in your
6to4 prefix such as 2002:xxxx:xxxx::, 2002:xxxx:xxxx::2,
2002:xxxx:xxxx:1234:5678:9abc:dead:beef... ?

> Unlike IPv4, an interface can have multiple IPv6 addresses assigned to
> it.

You mean *like* IPv4. An interface can have multiple IPv4 addresses. Do
not let ifconfig fool you.

$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:29:04:b6:61 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
inet 192.168.100.1/24 brd 192.168.0.255 scope global eth0:0
inet6 2001:7a8:6d23:1::1/64 scope global
inet6 2002:d529:ad23:1::1/64 scope global
inet6 fe80::2e0:29ff:fe04:b661/64 scope link

"Pascal Hambourg" <boite-a-(E-Mail Removed)> wrote in message
news:fqm0mj$hi4$(E-Mail Removed)...
> D. Stussy a écrit :
> >
> > Also, if you don't put the 6to4
> > address on the sit0 interface, it does work but the route that gets
> > auto-added (for other than a /128) gets added to the wrong interface and
the
> > auto-lookup for the embedded IPv4 remote tunnel end breaks, unless you
also
> > manually add "2002::/16" to sit0.
>
> Of course the sit interface must have the 2002::/16 route. I did not say
> otherwise. This does not mean that the sit interface must have a 6to4
> address or other interfaces must not have 6to4 addresses.
>
> > However, you still need the 2002::/16 route on sit0 for it to work with
> > OTHER PEOPLE's 6to4 addresses.
>
> Correct.
>
> > Additionally, you will have at least one
> > address for your local host, and it really belongs on sit0
>
> No, it can be assigned to any interface. If the output interface has no
> suitable address, the network stack will use a suitable address from
> another interface. I.e. if you assigned a 6to4 address only to the LAN
> interface, this address can be used for communications on the sit
interface.
>
> > = so no reason not to "ifconfig sit0 inet6 add 2002:xxxx:xxxx::1\16"
> > where it's supposed to be.
>
> One reason : it is not required when the host already has a 6to4 address
> assigned to another interface.
> Besides, why assign 2002:xxxx:xxxx::1 and not any other address in your
> 6to4 prefix such as 2002:xxxx:xxxx::, 2002:xxxx:xxxx::2,
> 2002:xxxx:xxxx:1234:5678:9abc:dead:beef... ?
>
> > Unlike IPv4, an interface can have multiple IPv6 addresses assigned to
> > it.
>
> You mean *like* IPv4. An interface can have multiple IPv4 addresses. Do
> not let ifconfig fool you.
>
> $ ip addr show dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
> link/ether 00:e0:29:04:b6:61 brd ff:ff:ff:ff:ff:ff
> inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
> inet 192.168.100.1/24 brd 192.168.0.255 scope global eth0:0
> inet6 2001:7a8:6d23:1::1/64 scope global
> inet6 2002:d529:ad23:1::1/64 scope global
> inet6 fe80::2e0:29ff:fe04:b661/64 scope link

That doesn't work on my system. To assign a second IPv4, I have to use
"eth0:1", "eth0:2", etc., i.e. a virtual extension interface.

D. Stussy a écrit :
> "Pascal Hambourg" <boite-a-(E-Mail Removed)> wrote
>>
>>You mean *like* IPv4. An interface can have multiple IPv4 addresses. Do
>>not let ifconfig fool you.
>>
>>$ ip addr show dev eth0
>>2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
>> link/ether 00:e0:29:04:b6:61 brd ff:ff:ff:ff:ff:ff
>> inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
>> inet 192.168.100.1/24 brd 192.168.0.255 scope global eth0:0
>> inet6 2001:7a8:6d23:1::1/64 scope global
>> inet6 2002:d529:ad23:1::1/64 scope global
>> inet6 fe80::2e0:29ff:fe04:b661/64 scope link
>
> That doesn't work on my system. To assign a second IPv4, I have to use
> "eth0:1", "eth0:2", etc., i.e. a virtual extension interface.

What exactly doen't work ? What tools, what commands did you try ?
These work for me :

ip addr add <address>/<prefixlen> broadcast <broadcast> dev <interface>

or

ifconfig <interface> add <address> netmask <mask> broadcast <broadcast>

I repeat : do not let ifconfig fool you. It is an obsolete tool for
address configuration which is broken in several ways ; use the more
modern and versatile "ip" tool from the iproute package instead.
"eth0:0" and the like are not interfaces, even virtual, but merely
labels attached to IPv4 addresses. You can see those labels at the end
of the "inet" lines in the output of "ip addr show".