Re: connecting to 6bone problem
On Tue, 1 Aug 2000, Bernd Eckenfels wrote:
> > Otherwise it is much righter that most other scripts I've seen because it
> > properly associates the tunnel endpoint with the tunnel and not eth0 :>
>
> Actually this depends if you have alocal net or not. In my case I have it
> aded to eth0 since i havbe my own /126.
IMHO both the ethernet interface and the tunnel interface should be
labled in the case. That maintains a certain symetry with ipv4 tunnels..
> I dont see a reason for secifing 3ff8::1.2.3.4 vias for the tunnel if the
> ipv4 address is set up with ip tunnel/iptunnel, but thats only me :)
> ip tunnel add baol mode sit remote $REMOTE ttl 64
^^^^^^^^^^^^^^^^^^^
> ip route add 2000::/3 via fe80::$REMOTE dev baol
^^^^^^^^^^^^^^
Pouring over the IP route docs provides an answer to your question here ..
hang on to your seat!
Lets imagine here we construct a tunnel from pandora to surf.net:
ip tunnel add surfnet mode sit local 132.229.131.40 remote 192.87.106.15
ip link set surfnet up
ip addr add 3ffe:600:8000:8::32 dev surfnet
Okay. Now we have a tunneling device that says 'take IPv6 packets on
device 'surfnet' and cram them into IPv4 using a local IP of
132.229.131.40 and jam them over to 192.87.106.15'. We've also given the
tunnel device a local address [just to be very clear that the tunnel
operates in IPv4 space]
We *MUST* now establish some routing into the tunnel - like with ethernet
the only available destination is fe80::192.87.106.15 and
fe80::132.229.131.40 [more on this later]. Our tunnel example will be a
tunnel to the internet from an isolated IPv6 island, but it could just as
easially be a tunnel linking two islands of IPv6.
[Route A:
Next we can establish a host route to our tunnel peer:
ip -6 route add 3ffe:600:8000:8::31 dev surfnet onlink
and finally a default route through our peer:
ip -6 route add default via 3ffe:600:8000:8::31
* Pandora's tunnel is point to point between 3ffe:600:8000:8::31 <>
3ffe:600:8000:8::32, we do not have a subnet..
]
[Route B:
Next we can establish a route to the tunnel's peer link local address.
ip -6 route add default via fe80::192.87.106.15 dev surfnet
This way does not require the first host route.
* Note that the link local address of the peer is hidden and doesn't seem
to be shown by any of the utilities, it also seems the ONLY two link
addresses on a tunnel are the local address and the peer address, so
you cannot use fe80:: to other hosts, and you cannot use 0:: to
other hosts. This is basically the major draw back of point to point
tunnels
]
This has full symetry with an ipip tunnel. You have established the
internet tunnel endpoints via the 'ip tunnel add' command and then
established a network route over the tunnel using the forced device and
the onlink attribute - or by using a link local address. This is a pure
POINT TO POINT tunnel, not a NMBA tunnel. Think of it like a PPP link, the
steps above are very close to how a PPP connect is created in the kernel
(AFAIK) [ See #1 below ]
Now, the other option here is to use NBMA (non broadcast multiple
access) tunnels which is a sit tunnel with a wildcard remote address - the
kernel provides one of these for us called sit0.
Activate the NBMA device:
ip link set sit0 up
Attach a local address to it (unecessary if you have this on ethernet, in
fact this doesn't even make very much *sense* in this case.. but if the
etherenet isn't running ipv6 you haven't much choice where to attach it)
ip addr add 3ffe:600:8000:8::32 dev sit0
But notice that the NBMA device has mapped it's entire link
addressing model (IPv4) into the address space it is tunneling. It does
this using the reserved 0::x.x.x.x space
So now you can say:
ip -6 route add default via ::192.87.106.15 dev sit0
And directly establish the default route over the NBMA tunnel. You can do
this to arbitary hosts too, on pandora for instance I do:
ip -6 route add 3FFE:B00:C18:1FFF:0:0:0:227 via ::216.160.206.172 dev sit0
[which could be expressed as:
ip -6 route add lully.ipv6.debian.org via lully.debian.org dev sit0]
Now, the kernel has this funny looking route:
::/96 via :: dev sit0 metric 256 mtu 1480 rtt 375ms
Which is built by sit0, it catches the magic leading 0::x.x.x.x addresess
and takes them into the sit driver somehow.
So after our packet gets into the sit0 device with an address being from
<some real IPv6> to <some other real IPv6> via 0::192.87.106.15 the sit
driver says AHA! and uses 192.87.106.15 as it's ipv4 link address for
<some other real IPv6>. 192.87.106.15 is another NBMA device that undoes
the tunnel encoding looks at the to address and routes it.
Incoming packets presumably have the reverse done, they look to the kernel
as though they came in via 0::<whatever> and are destined to some IPv6 IP.
Firewalling rules (particularly forwarding!!) take care of the 'security'.
***** NOTE!!
These comments apply to 'ip' If you try to use ifconfig you will find it
does a few ood things. Primarily it always brings up sit0 when loading a
tunnel - this is not strictly necessary. Also, as I once heard..
sit0/sit1 ARE NOT PAIRS, they are totally different things :>
You may also see people applying routes to 2001 or 3ffe prefixes, 99% of
the time they probably ment to put 'default' :>
I hope this is actually correct information and can explain better
how all Linux tunnels work, I know it helped me alot :>
My personal recomendation is to use 'ip' and use NBMA tunnels when working
with IPv6, that gives the maximum flexability. To do this you need 2 bits
of information:
1) A single IP or a subnet for which a tunnel provider has a NBMA route
like:
ip -6 route add <MY PREFIX>/64 via ::<MY IPv4 IP> dev sit0
2) The IP of your tunnel provider
If a tunnel provider only provides point to point tunnels then things look
more traditional. Your 'sit1' device has a fixed /128 IP and a pair'd /128
IP and the provider routes a /64 to your fixed /128.
However this is only a conceptual difference and you can still use
use NBMA tunneling on your end.
Jason
#1 Here is some information from ifconfig and ip to show what this looks
like:
## Ifconfig
surfnet Link encap:IPv6-in-IPv4
inet6 addr: fe80::84e5:8328/128 Scope:Link
inet6 addr: 3ffe:600:8000:8::32/128 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
Notice that fe80::84e5:8328 is the link local scope and 84e5:8328 ==
132.229.131.40, which is our local host. You cannot see the remote pair on
ifconfig.
## ip rotue [snipped]
fe80::/10 via :: dev surfnet proto kernel metric 256 mtu 1480 rtt 375ms
default via 3ffe:600:8000:8::31 dev surfnet metric 1024 mtu 1480 rtt 375ms
3ffe:600:8000:8::31 dev surfnet metric 1024 mtu 1480 rtt 375ms
Notice 3ffe:600:8000:8::31 doesn't have a destination? It just goes into
the device and presumably comes out the other end... <grin> IIRC you can
only do host routes like this.
#2 NBMA example:
## ifconfig
sit0 Link encap:IPv6-in-IPv4
inet6 addr: ::132.229.131.40/96 Scope:Compat
inet6 addr: 3ffe:600:8000:8::32/128 Scope:Global
inet6 addr: ::127.0.0.1/96 Scope:Unknown
UP RUNNING NOARP MTU:1480 Metric:1
Notice it ain't point to point anymore dorthy. Has no broadcast/multicast
either!
# ip route [snipped]
::/96 via :: dev sit0 metric 256 mtu 1480 rtt 375ms
default via ::192.87.106.15 dev sit0 metric 1024 mtu 1480 rtt 375ms
Reply to: