As discussed with bug #121940, here's an initial attempt for implementing Ipv6 6to4 support for baselayout. Based on http://gentoo-wiki.com/HOWTO_IPv6#IPv6_tunneling_with_6to4, tested with baselayout 1.11.14. I created a module named "ipvsix" for quickly connecting to IPv6 backbone via 6to4. Works with DHCP-obtained IPv4 addresses just fine. Required configuration in /etc/conf.d/net is ipvsix_tun6to4=( "eth0" ) // Or whatever is the "host" interface config_tun6to4=( "null" ) What the modules does: Creates a tunnel by the specified name (in example, tun6to4, can be anything). Connects to the anycast address of 192.88.99.1 and sets up default routing via the tunnel interface. I see no problems with running radvd servers if your IPv4 address is static, since your 6to4-derived IPv6 prefix is based on your IPv4 address. (I doubt that there are that many people running routers on dynamic addresses). If desired, the 6to4 module could be expanded to configure the prefix to /etc/radvd.conf, too.1 Local IPv6 address (the interface identifier part) will be ::1, as that is the standard notation for router. Ie. the full address will be 2002:IPv4:addr::1. You can then divide 2002:IPv4:addr::/64's to your hosts if you are running router. The module is named "ipvsix" because for some reason I could not get module names with numbers in them to work, ie. module named 6to4 resulted in errors like this: /etc/conf.d/net: line 365: syntax error near unexpected token `"eth0"' /etc/conf.d/net: line 365: `6to4_tun6to4=( "eth0" )' Roy, can you specify what exactly is the "extra configuration required by all the clients" you mentioned in the other bug? TODO: Possibility to change the 6to4 endpoint from 192.88.99.1 (Not needed, I suppose - then you can just use static tunnels anyway) Error checks? Possibility to use only ifconfig and not requiring iproute - in that case the tunnel name must be sit0(?)
Created attachment 79143 [details] 6to4 script. Place in rcscripts/net.modules.d/ipvsix
What does your module do that this config does not? config_eth0=( "192.168.0.2/24" "2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:feb/64" ) routes_eth0=( "default via 192.168.0.1" ) iptunnel_sit1="mode sit remote xxx.xxx.xxx.xxx ttl 64" config_sit1=( "2001:xxxx:xxxx::xxxx:xxxx/128" ) routes_sit1=( "2000::/3" ) Note, you cannot start module names with a number as you have discovered. This is bash limitation due to the way we handle our module function wrapping.
(In reply to comment #0) > Roy, can you specify what exactly is the "extra configuration required by all > the clients" you mentioned in the other bug? Maybe I mis-understood. The config above applies to a 6to4 gateyway. So everyone talks ipv6 and the 6to4 gateway sends all traffic over its ipv4 interface. So your module appears to do something similar, but configures itself using an ipv4 address already configured - my approach just has the ipv6 address on $iface based on my ipv6 prefix and MAC address. Works just as well.
(In reply to comment #2) > What does your module do that this config does not? The primary reason is that it works with DHCP-assigned IPv4 addresses. Especially useful if you are connecting from someplace like a hotel or somehow else visiting another network. Also, there is all the stuff related to converting IPv4 addresses to hexadecimal. > config_eth0=( > "192.168.0.2/24" > "2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:feb/64" > ) > routes_eth0=( "default via 192.168.0.1" ) > > iptunnel_sit1="mode sit remote xxx.xxx.xxx.xxx ttl 64" > config_sit1=( "2001:xxxx:xxxx::xxxx:xxxx/128" ) Ie. you cannot set up config_sit1 as "2002:eth0_ipv4_addr:from_dhcp::/16" like with 6to4. > routes_sit1=( "2000::/3" ) ...altough I do note that this routes-bit should probably be taken out of my module. See http://en.wikipedia.org/wiki/6to4 for description of 6to4 - it's somewhat a different beast from static tunnels (and much better for automation). You basically get IPv6 connectivity and your personal ::/48 prefix basically turning the thing on. No need to set up agreements with a tunnelbroker or anything like that. Just connect to your local 192.88.99.1 and go. Also, 6to4 creates asymmetric tunneling automatically and optimizes the path that the packets traverse in IPv4 cloud. Your own packets go out of your of your closest 6to4 GW; The other endpoint, when replying, sends his packets via HIS 6to4 GW and the packets come back perhaps completely different route. (This is achieved by configuring the interface with netmask /16 in all 6to4 gws).
(In reply to comment #3) > Maybe I mis-understood. The config above applies to a 6to4 gateyway. So > everyone talks ipv6 and the 6to4 gateway sends all traffic over its ipv4 > interface. > > So your module appears to do something similar, but configures itself using an > ipv4 address already configured - my approach just has the ipv6 address on > $iface based on my ipv6 prefix and MAC address. Works just as well. Ah, so you mean 6to4 gw that is directly connected to a native IPv6 backbone. Mine is for connecting the isolated islands of IPv6 in the middle of IPv4 clouds to those...
(In reply to comment #5) > Ah, so you mean 6to4 gw that is directly connected to a native IPv6 backbone. No :) My ADSL router and ISP only support IPv4. The above code creates an IPv6 tunnel to my broker on my home server (read IPv6 gateway) and radvd advertises the presence of my server as an IPv6 gateway so IPv6 clients get configured automatically. > > Mine is for connecting the isolated islands of IPv6 in the middle of IPv4 > clouds to those... Mine is for stateless IPv6 configuration. The computer I'm currently at has had nothing configured for IPv6 except for enabling the protocol in the kernel. It Just Works (tm) :) Am I right in thinking that your module requires a global IPv4 address? (ie, not a private one)
(In reply to comment #6) > > Ah, so you mean 6to4 gw that is directly connected to a native IPv6 backbone. > My ADSL router and ISP only support IPv4. The above code creates an IPv6 > tunnel > to my broker on my home server (read IPv6 gateway) and radvd advertises the > presence of my server as an IPv6 gateway so IPv6 clients get configured > automatically. Yes. Thats standard stateless autoconfiguration for IPv6. > > Mine is for connecting the isolated islands of IPv6 in the middle of IPv4 > > clouds to those... > Mine is for stateless IPv6 configuration. The computer I'm currently at has had > nothing configured for IPv6 except for enabling the protocol in the kernel. It > Just Works (tm) :) So does this - it's built into the basic IPv6 support. > Am I right in thinking that your module requires a global IPv4 address? (ie, > not a private one) Yes - that's how 6to4 works. The IPv6 address is based on the IPv4 address. The entire prefix of 2002::/16 is allocated for 6to4 addresses (as opposed to native addresses). Anyway, like I said, the 6to4 does not require tunnelbrokers or anything like that - it's completely automatic. And radvd is completely unrelated to this - radvd is for distributing the ::/64 for the individual hosts (router advertisement messages). 6to4 is a mechanism for the router to automatically acquire a ::/48 prefix (to be distributed to any hosts). (If not running a router, it can also be used to connect single hosts). 6to4 is the preferred way for connecting to IPv6 backbone over IPv4 because it requires no configuration of any kind - ie. no contracts with tunnelbrokers, no need to know their IP addresses (its always 192.88.99.1), your IPv6 prefix comes from your IPv4 address - etc. So, 6to4 allows for MORE autoconfiguration :). Read the wiki on 6to4.
OK, I understand now. I'll code something that fits in a little better though as you point out it depends on iproute2 and there's a few other quirks I don't like. However, whatever I do will appear in the baselayout-1.12 branch. Your module can stay here for baselayout-1.11 users though :)
http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/configuring-ipv6to4-tunnels.html shows a method of using just the sit-interface and standard tools.
Created attachment 79209 [details] ip6to4 module for baselayout-1.12 Right, this bad boy works with both iproute2 and ifconfig (although only on interface sit0) and appears to work 100%. Want to test it for me? link_6to4="eth0" config_6to4=( "ip6to4" )
(In reply to comment #10) > Want to test it for me? > > link_6to4="eth0" > config_6to4=( "ip6to4" ) I don't have baselayout 1.12 anywhere, but I suppose I could test it.. Just looking at the code, it seems to work. I like the way you insert the route metric to 65535 - therefore not overriding any possible native IPv6 connections. for addr in "${addrs[@]}" ; do ... done seems to indicate that the script can also handle situations where there are multiple IPv4 addresses for a given interface. I'll try upgrading to baselayout 1.12 on my test system and see how it works out.
(In reply to comment #11) > I don't have baselayout 1.12 anywhere, but I suppose I could test it.. It can be made to work in 1.11 if you supply the necessary functions and remove the new calls in depend() > > Just looking at the code, it seems to work. I like the way you insert the > route metric to 65535 - therefore not overriding any possible native IPv6 > connections. That needs to be changed to the highest value that metrics support :) But it will do for now. > seems to indicate that the script can also handle situations where there are > multiple IPv4 addresses for a given interface. Yes it does. Fex, using iproute2 you can have this 192.168.0.1 1.2.3.4 5.6.7.8 10.1.1.1 Which is perfectly valid, but we can only work on 1.2.3.4 and 5.6.7.8 - we don't know which ones so we use both. I'm not sure, but it seems like the logical thing todo. Maybe we should only apply the first non private address? > > I'll try upgrading to baselayout 1.12 on my test system and see how it works > out. > There are a few issues with it (hence it's not being stable) but it should work fine for the most part.
(In reply to comment #12) > Yes it does. Fex, using iproute2 you can have this > > 192.168.0.1 > 1.2.3.4 > 5.6.7.8 > 10.1.1.1 > > Which is perfectly valid, but we can only work on 1.2.3.4 and 5.6.7.8 - we > don't know which ones so we use both. I'm not sure, but it seems like the > logical thing todo. Maybe we should only apply the first non private address? Multiple addresses are always a bit special case, but I agree that it should be applied for all public addresses. Using both is the logical option - after all, if the box can be reached via 1.2.3.4 and 5.6.7.8 I see no reason why it shouldn't be reached via 2002:102:304::1 and 2002:506:708::1 as well.
(In reply to comment #12) > (In reply to comment #11) > > I don't have baselayout 1.12 anywhere, but I suppose I could test it.. > > It can be made to work in 1.11 if you supply the necessary functions and remove > the new calls in depend() With few changes (providing provides and check_installed), works in 1.11 too except for the line # Now apply our config config=( "${config[@]}" "${new[@]}" ) Ie. applying the 6to4 addresses to the newly created tunnel interface. Routing is set up correctly and the derived IPv6 address appears to be calculated correctly, too.
(In reply to comment #14) > With few changes (providing provides and check_installed), works in 1.11 too > except for the line > > # Now apply our config > config=( "${config[@]}" "${new[@]}" ) > > Ie. applying the 6to4 addresses to the newly created tunnel interface. > Routing is set up correctly and the derived IPv6 address appears to be > calculated correctly, too. Ah, silly me. I was using ifconfig, not iproute2. I think you should add check that if using ifconfig and the interface name != sit0, bail out with error..
Created attachment 79222 [details] new module for baselayout-1.12 This one detects for ifconfig/sit0 and errors accordingly. We also use the highest route metric we can as this will always be our least desired route really. If you're happy with this then I'll wang it into baselayout-1.12.0_pre16
(In reply to comment #16) > If you're happy with this then I'll wang it into baselayout-1.12.0_pre16 Tested with 1.12.0_pre15-r1 now (installed it one one of my boxes) and works fine with iproute2 (tested with multiple IPv4 addresses, too). However, something funny still about sit0. Apparently baselayout 1.12 uses iproute2 even when the module is disabled (I tried to test ifconfig by setting modules=( "!iproute2" ) and did not help - only emerge -C did that). Anyway, I noticed that 1) I can use sit0 as the device name even with iproute2 - this works ok, however, when bringing down the interface, there appears a foxtail conf.d # /etc/init.d/net.sit0 stop * Stopping sit0 * Bringing down sit0 * Destroying tunnel sit0 ... ioctl: Operation not permitted [ !! ] * Shutting down sit0 ... [ ok ] Seems to work ok, I just don't know what's the ioctl-error about. 2) When using ifconfig (ie, saying emerge -C iproute2 since nothing else worked), it does not seem to work properly. /etc/init.d/net.sit0 start * Starting sit0 * Bringing up sit0 * ip6to4 /lib/rcscripts/net.modules.d/ip6to4: line 41: iproute2_get_address: command not found * sit0 is not configured with an IPv4 address [ !! ] It seems that there is a module-specific function..the check local -a addrs=( $(iproute2_get_address "${!host}") ) should only be done when iproute2 is in there.
(In reply to comment #17) > * sit0 is not configured with an IPv4 address [ !! Oh, and this should probably refer to ${host}, not to ${iface}.
Created attachment 79228 [details] ip6to4 module for baselayout-1.12 Fixed issues. The iproute_get_interfaces thing was temporary to test something. I've also address the right interface name being reported.
Created attachment 79229 [details] tunnel module which doesn't destroy sit0 a baselayout-1.12 iptunnel module which doesn't destroy sit0 as my understanding says it should never be destroyed ....
(In reply to comment #19) > Created an attachment (id=79228) [edit] > ip6to4 module for baselayout-1.12 > > Fixed issues. The iproute_get_interfaces thing was temporary to test something. > I've also address the right interface name being reported. Works for me now, expect for that ioctl error, ie. /etc/init.d/net.sit0 stop * Stopping sit0 * Bringing down sit0 * Destroying tunnel sit0 ... ioctl: Operation not permitted [ !! ] * Shutting down sit0 ... [ ok ] Sit0 is still shut down properly (ie. addresses and routing is removed). Could this be due to the fact that some generic component attempts to delete the interface completely? This cannot be done - sit0 is always present (even when down) as long as IPv6 is compiled into the kernel. It cannot be removed. However, everything else is ok.
(In reply to comment #20) > Created an attachment (id=79229) [edit] > tunnel module which doesn't destroy sit0 > > a baselayout-1.12 iptunnel module which doesn't destroy sit0 as my > understanding says it should never be destroyed .... Damn, I have good intuition :)
Ok, one complementary thing that comes into mind that you could add, would be to check if someone attempts to use loopback interface (address range 127.0.0.0/8) for 6to4. This is probably not really necessary (I doubt anyone would even attempt that), but since all it takes is the line [[ ${ip} == "127."* ]] && continue to the same spot where you check for private address spaces I suppose it could go there. But other than that, I'm fine with this. Thanks!
Happy with these now?
Yeah.(In reply to comment #24) > Happy with these now? Quite happy, indeed.
Drat. Forgot the final test case - how does this behave when used in conjuction with ifplugd and changing networks. If my eth0 interface goes down, the tunnel should go down with it. When the eth0 is back up (regardless of reason) the tunnel should come back up. Is this mechanism already implemented in other parts of baselayout? Anyway, here's a really basic case: wlan0 Link encap:Ethernet HWaddr 00:50:8B:D0:60:72 inet addr:192.194.75.140 sit0 Link encap:IPv6-in-IPv4 inet6 addr: 2002:c0c2:4b8c::1/16 Scope:Global /etc/init.d/net.wlan0 stop * Stopping wlan0 * Bringing down wlan0 * Shutting down wlan0 ... [ ok ] sit0 Link encap:IPv6-in-IPv4 inet6 addr: 2002:c0c2:4b8c::1/16 Scope:Global is still up! ' /etc/init.d/net.wlan0 start * Starting wlan0 * Configuring wireless network for wlan0 * Bringing up wlan0 * dhcp * Running udhcpc ... [ ok ] * wlan0 received address 192.194.75.141/29 Different address => sit0 should also be reconfigured. Can the tunnel interface be made to depend on the host interface, so that it goes down if the host if goes down?
(In reply to comment #26) > Drat. Forgot the final test case - how does this behave when used in conjuction > with ifplugd and changing networks. > > If my eth0 interface goes down, the tunnel should go down with it. When the > eth0 is back up (regardless of reason) the tunnel should come back up. > > Is this mechanism already implemented in other parts of baselayout? > Put this in conf.d/net depend_sit0() { need net.eth0 } Of course sit0 could be 6to4 and net.eth0 could be net.lan ifplugd will then take down the tunnel correctly and should bring the tunnel back up again if the tunnel was up when it took down the link. netplug also works like this. The caveat is that you'll probably have to stop using the ifplugd init script as it's been incorporated into baselayout :) Anyway, this is now in our svn repo and will be in baselayout-1.12.0_pre16
(In reply to comment #27) > Put this in conf.d/net > > depend_sit0() { > need net.eth0 > } > Anyway, this is now in our svn repo and will be in baselayout-1.12.0_pre16 Great. Hopefully this point also gets documented :)
Fixed in baselayout-1.12.0_pre16
