IPv6 Woes...

[Bruce A. Mah]

If memory serves me right, Eric F Crist wrote:
> On Jun 26, 2007, at 4:32 PMJun 26, 2007, Bruce A. Mah wrote:

[big snip]

>> I wonder if the problem I've seen with bridge(4) might be related to
>> your IPv6 problems (since you're terminating the tunnel on your
>> firewall).  If so, maybe switching to if_bridge(4) as I've described
>> above might help things.
>>
>> In any case, good luck!
> 
> Bruce! Thanks for all the help!  That did the trick!  Only one more  
> thing that's holding me up.

Cool...I was half-guessing on this one.

> On my gateway, I've got 2001:4980:1:111::145/64 as the primary IP  
> address.  In addition, I've got 2001:4980:1:111::1/128 as an alias.   
> I can ping/connect to the xxx:145 address, but not the xxx:1  
> address.  What did I configure wrong?  Here's the output of netstat - 
> r -f inet6:
> 
> Routing tables
> 
> Internet6:
> Destination                    Gateway                         
> Flags    Refs      Use    Mtu    Netif Expire
> ::                             localhost.secure-computing.net  
> UGRS        0        0  16384      lo0 =>
> default                        2001:4980:1::5                  
> UGS         0        0   1280     gif0
> localhost.secure-computing.net localhost.secure-computing.net  
> UHL         5        0  16384      lo0
> ::ffff:0.0.0.0                 localhost.secure-computing.net  
> UGRS        0        0  16384      lo0
> 2001:4980:1::4                 link#7                          
> UC          0        0   1280     gif0
> 2001:4980:1::5                 link#7                          
> UHLW        2        4   1280     gif0
> 2001:4980:1::6                 link#7                          
> UHL         1        4   1280      lo0
> 2001:4980:1:111::              link#1                          
> UC          0        1   1500     fxp0
> 2001:4980:1:111::1             00:06:5b:05:30:19               
> UHL         1        4   1500      lo0
> 2001:4980:1:111::145           00:06:5b:05:30:19               
> UHL         2        4   1500      lo0
> 2001:4980:1:111::147           00:06:5b:38:2e:82               
> UHLW        1       14   1500     fxp0
> fe80::                         localhost.secure-computing.net  
> UGRS        0        0  16384      lo0
> fe80::%fxp0                    link#1                          
> UC          0        0   1500     fxp0
> fe80::206:5bff:fe05:3019%fxp0  00:06:5b:05:30:19               
> UHL         1        0   1500      lo0
> fe80::%fxp1                    link#2                          
> UC          0        0   1500     fxp1
> fe80::206:5bff:fe05:301a%fxp1  00:06:5b:05:30:1a               
> UHL         1        0   1500      lo0
> fe80::%lo0                     fe80::1%lo0                     
> U           0        0  16384      lo0
> fe80::1%lo0                    link#3                          
> UHL         1        0  16384      lo0
> fe80::%gif0                    link#7                          
> UC          0        0   1280     gif0
> fe80::206:5bff:fe05:3019%gif0  link#7                          
> UHL         1        0   1280      lo0
> fe80::%tun0                    link#8                          
> UC          0        0   1500     tun0
> fe80::206:5bff:fe05:3019%tun0  link#8                          
> UHL         1        0   1500      lo0
> ff01:1::                       link#1                          
> UC          0        0   1500     fxp0
> ff01:2::                       link#2                          
> UC          0        0   1500     fxp1
> ff01:3::                       localhost.secure-computing.net  
> UC          0        0  16384      lo0
> ff01:7::                       link#7                          
> UC          0        0   1280     gif0
> ff01:8::                       link#8                          
> UC          0        0   1500     tun0
> ff02::                         localhost.secure-computing.net  
> UGRS        0        0  16384      lo0
> ff02::%fxp0                    link#1                          
> UC          0        0   1500     fxp0
> ff02::%fxp1                    link#2                          
> UC          0        0   1500     fxp1
> ff02::%lo0                     localhost.secure-computing.net  
> UC          0        0  16384      lo0
> ff02::%gif0                    link#7                          
> UC          0        0   1280     gif0
> ff02::%tun0                    link#8                          
> UC          0        0   1500     tun0

This is a little odd.  If you switched to using if_bridge for bridging,
I would have expected to see bridge0 as one of your links.  Is it not
configured for IPv6?  In my setup, the physical interfaces in the bridge
are also unnumbered with respect to IPv6 as well (and the gateway
machine's IPv6 address gets assigned to the bridge0 interface).

I'm not sure what bearing this has on the question you really asked,
which was about assigning another IPv6 address to an interface.  It's
not real obvious to me what the problem is there...at least from the
routing table everything looks OK.

What about the neighbor table ("ndp -a")?  On the gateway, ndp -a should
show entries for the two IPv6 addresses you assigned.  On one of your
LAN hosts (which I'm assuming are some *nix flavor), if you ping the two
addresses of your gateway machine, you should then get entries in the
NDP table for both those addresses as well.

Bruce.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20070627/2fcf0b2c/signature.pgp