tech-net archive

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

Re: IPv6 and ND on tap(4)


first of all, thanks for your insights.  Learned a lot today 
("route -n monitor" and the "cloning" route stuff).

Now towards the actual thread:

On Fri, Sep 16, 2011 at 08:47:51PM -0400, Greg Troxel wrote:
> It seems there is a bug in tap.
> In systems derived from 4.4BSD, the connected route should appear
> automatically when adding an address.   I would say it's a bug for
> systems that have the concept of cloning route not to add it
> automatically when configuring an address.
> summary: I tried to replicate on sparc64.  Both it and i386 seem to work
> correctly.

Things seem to be a bit more complicated than thought...

I rebooted (to test whether different values of ip6mode have an effect,
and to clear whatever garbage my previous route/ifconfig fumbling might
have left somewhere), and that makes it work "for a while"(!):

# date
Sat Sep 17 09:14:57 CEST 2011
# ifconfig tap0 create
# ifconfig tap0 inet6 2001:608:4:a053::1:0/64
# date
Sat Sep 17 09:15:32 CEST 2011
# netstat -rn -f inet6 |grep :4:
2001:608:4:a053::/64               link#3             UC          0        0    
  -  tap0
2001:608:4:a053::1:0               f2:0b:a4:00:02:7f  UHL         0        0    
  -  lo0

(I seem to get these "UHL / lo0" entries for all "local ip address"

... and after a while:

# date
Sat Sep 17 09:19:16 CEST 2011
# netstat -rn -f inet6 |grep :4:
2001:608:4:a053::1:0               f2:0b:a4:00:02:7f  UHL         0        0    
  -  lo0

... and when that happens, it will stay that way "no /64 UC" even if
I destroy and recreate the tap0.

"route -n monitor" shows the withdrawal of the /64 UC route:

got message of size 248 on Sat Sep 17 09:19:05 2011
RTM_DELETE: Delete Route: len 248, pid 0, seq 0, errno 0, flags: <DONE,CLONING>
locks:  inits: 
 2001:608:4:a053::  ffff:ffff:ffff:ffff:: tap0:f2.b.a4.0.2.7f 
got message of size 108 on Sat Sep 17 09:19:05 2011
RTM_NEWADDR: address being added to iface: len 108, metric 0, flags: 
sockaddrs: <NETMASK,IFP,IFA>
 ffff:ffff:ffff:ffff:: 2001:608:8003:0:a00:20ff:fec0:ffee
got message of size 168 on Sat Sep 17 09:19:05 2011
RTM_ADD: Add Route: len 168, pid 0, seq 0, errno 0, flags: <UP,HOST,LLINFO>
locks:  inits: 
sockaddrs: <DST,GATEWAY>

... and that makes me suspect it has to do with "ip6mode=autohost", as
the tap0 route disappears the very moment a SLAAC'ed IPv6 address shows
up on hme0.

Trying again with "ip6mode=host"...

$ netstat -rn |grep :4:
2001:608:4:a053::/64               link#3             UC          0        0    
  -  tap0
2001:608:4:a053::1:0               f2:0b:a4:00:04:a6  UHL         0        0    
  -  lo0

... waiting for incoming RA...

09:31:33.962892 IP6 fe80::21d:73ff:feb1:919c > ff02::1: ICMP6, router 
advertisement, length 80

... route still there!$ netstat -rn |grep :4:
2001:608:4:a053::/64               link#3             UC          0        0    
  -  tap0
2001:608:4:a053::1:0               f2:0b:a4:00:04:a6  UHL         0        0    
  -  lo0

... and in this scenario, OpenVPN-on-TAP does what I want (and the extra
"route" statement for the connected /64 properly gets rejected with 
"route: writing to routing socket: File exists")

So now this brings up more questions :-)

 - what exactly does "ip6mode=autohost" change?
 - should it have this effect  (UC routes on interface A going away
   if a RA is seen on interface B, while the ipv6 address is still there)?

> > fe80::f00b:a4ff:fe00:4dd2%tap0 f2:0b:a4:00:4d:d2 UHL 0 0 - lo0
> This one seems wrong.  I have no such entry but instead have an ND cache
> entry.   I suspect this and the missing cloning route are related.

I see "UHL... lo0" routes for all IPv6 addresses that the system has,
and "UHLc" for ND (+arp) cache entries:

$ netstat -rn |grep UHL        6e:02:b7:bc:b7:1d  UHLc        1       60      -  tap0         e4:1f:13:8e:80:b0  UHLc        0       32      -  hme0         e4:1f:13:8e:80:b0  UHLc        4     6179      -  hme0       00:a0:f9:00:7c:fa  UHLc        1        0      -  hme0
2001:608:4:a053::1                 6e:02:b7:bc:b7:1d  UHLc        2        8    
  -  tap0
2001:608:4:a053::1:0               f2:0b:a4:00:0a:32  UHL         1        0    
  -  lo0
2001:608:8003::beef                08:00:20:c0:ff:ee  UHL         0        0    
  -  lo0
2001:608:8003::ffff                00:1d:73:b1:91:9c  UHLc        1       14    
  -  hme0
fe80::21d:73ff:feb1:919c%hme0      00:1d:73:b1:91:9c  UHLc        0       45    
  -  hme0
fe80::a00:20ff:fec0:ffee%hme0      08:00:20:c0:ff:ee  UHL         0        0    
  -  lo0
fe80::1%lo0                        link#2             UHL         0        0    
  -  lo0
fe80::f00b:a4ff:fe00:a32%tap0      f2:0b:a4:00:0a:32  UHL         0        0    
  -  lo0

... I have no idea whether it should be that way or not, but it's
the same on other NetBSD machines I've checked.

> Note that you are doing this on sparc64, which is LP64, and big endian.
> I predict that this will turn out to matter (but mine works).

Can't test on anything else, but this morning's test hint at "autohost"
side effects...

> > As a cross-check, I just tried this on NetBSD 3.1, and indeed, the route
> > auto-appears on tap0, and ND starts
> >
> > 22:20:00.348908 2001:608:4:a253::1:0 > ff02::1:ff00:2: icmp6: neighbor
> > sol: who has 2001:608:4:a253::2
> >
> > (different prefix deliberately chosen)
> What hardware?

Also Sparc64.  Right now, I don't have an i386 installation available.

But that machine has "ip6mode=host" (default setting).

> I just did this on a sparc64 running 5.1_RC3.  (I know that's old, and I
> will update to recent netbsd-5 and can try again if you're still having
> trouble.).  After "ifconfig tap0 inet6 2001:db8::1", diff -u of "netstat
> -nr -f inet6" taken before and after shows:
> +2001:db8::/64                      link#7             UC 0 0 -  tap0 =>

Does this system has IPv6 on another interface, with incoming router
advertisements?  How is "ip6mode" set?  (Just cross-checking).

thanks again,


USENET is *not* the non-clickable part of WWW!
Gert Doering - Munich, Germany                    
fax: +49-89-35655025               

Attachment: pgp49p_oVoJJj.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index