[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: auto6to4



>>>>> "Andrew" == Andrew Shadura <bugzilla@tut.by> writes:
    Andrew> On Wed, 06 Jun 2012 11:04:04 -0400 Michael Richardson
    Andrew> <mcr@sandelman.ca> wrote:

    >> Miredo is almost always more reliable.

    Andrew> I don't agree. It's more reliable in that meaning that in
    Andrew> works regardless of you being behind NAT, but the quality of
    Andrew> service can't be better most probably.

Given miredo, when I type "ssh some-ipv6-host" it works.
If I don't have miredo, I get "no route to host".
Miredo has quite a large number of relay agents out there thanks to
Microsoft.

    >> What I wish is that the Linux kernel's 6to4 code would be updated
    >> so that I could create routes over the sit interface for non
    >> 2002: traffic.

    Andrew> What prevents you from routing non-2002:: traffic over sit
    Andrew> interfaces?

On a *BSD machine with an stf0 device configured, one can literally do:

route add -net -inet6 2001:4830:16ca:: -prefixlen 48 2002:84d5:ee07::1
route add -net -inet6 2001:4830:116e:: -prefixlen 48 2002:84d5:ee07::1
route add -net -inet6 2001:4978:2ad::  -prefixlen 48 2002:84d5:eefa::1

and this works fine.  (I'm typing this on my Linux laptop at home from
my Linux desktop at work, via Linux and *BSD routers)

The target machine (a Linux router) has a sixxs tunnel, and also has a
sit0 interface configured with 6to4.  The packets are received by Linux
and decapsulated fine, but the reverse does not work.

I investigated a bunch and found that at the code in net/ipv6/sit.c:
(I last looked at 2.6.26, maybe a newer kernel fixes this)

static int ipip6_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
{
..
	if (!dst)
		dst = try_6to4(&iph6->daddr);
..


this pulls the "layer-2" next hop/neighbour out of the IPv6 *header*,
rather than taking it from the route target.   This makes sense for a
packet which is routed onto the 6to4 "LAN", but not if it got there with
a route target.

When I debugged this a year and a half ago, I realized I was descending
into IPv6 neigh/flow cache, which I find challenging to puzzle out. 
(The part of my brain that even knew the right terminology from my days
of doing IPsec ten years ago is also gone, so please excuse the
incomplete explanation)
 
I created an explicit tunnel on my work router for my home, and that
"solved" the problem, and I went about my work.  My v6 packets now
follow my v4 packets, despite my work being behind a sixxs.net tunnel.
(Stupidly, my work is on an R&E network, but the university can't spell
"Internet")

If I had a spare 2 days, I'd fix it.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 



Attachment: pgpS1rB7i922m.pgp
Description: PGP signature


Reply to: