IPv6 testing
-
YOU SHOULD NOT EXPECT A WORKING IPv6 INSTALL AT THIS POINT.
I started working on IPv6 support last week and I've got so far as to get a Static IPv6 address and gateway assigned.
There is no doubt a lot of work left. None of the autoconfiguration options at this point work. So statesless autoconfig and dhcpv6 are not working.
This means that you can currently only use it with a native statically assigned ipv6 at this point.If you install a pfSense 2.0 BETA4 from today (oct 26th) or later you can gitsync against my repo to get some ipv6 bits. This is very much a work in progress and so far I've managed to break a whole lot of pfSense in the process.
The git repo is located here.
http://rcs.pfsense.org/projects/pfsense/repos/pfSense-smosThe existing ipv6 ticket will be updated every once in a bit where I fix something. It's partly a todo list.
http://redmine.pfsense.org/issues/177YOU SHOULD NOT EXPECT A WORKING IPv6 INSTALL AT THIS POINT.
All other are free to leave comments in this thread.
Regards,
Seth
-
I would like to see IPv6 too but I do suppose that is an implausibly huge task at the moment. My next RSP is willing to offer me 65535 globally routable IPv6 addresses via PPTP which, as it seems, I won't be able to use with pfsense natively.
My options are evidently shot save for actually having a horrendously expensive Cisco router deployed just to 1:1 NAT the IPv6 addresses into a private Class B as WAN for the pfsense box. Sadly, even Vyatta isn't quite up to the task. -
If I remember correctly there are tunnel providers available like he.net which can provide you with routable /64 and /48 subnets.
What I did was make a ipv6 tunnel to the he.net tunnelbroker upstream. This effectively gave me a native ipv6 subnet. The cisco I did this on is a Cisco 1811.
They do have commands listed to get a ipv6 tunnel to the he.net tunnelbroker going on FreeBSD so that isn't impossible, but that isn't supported with what I have yet. It is however listed on the ToDo list, just no idea where at this point. I'll see what is possible, I need to get some basics tackled first.
-
I just wanted to voice my support for IPv6 NOT being targeted for 2.0.
Large ISPs like AT&T do not provide IPv6 support. I spoke to their technical service on the phone. They do not have any plans to go to IPv6. Many will look at the cost of upgraded routing equipment and shudder.
When the IPv4 addresses run out, probably in 2011, or sometime thereafter, many ISPs will probably go to NAT routing for their customers. Some already have.
That said, I do think IPv6 has a future. There will be increasing interest in IPv6 by pfSense users. I foresee the release subsequent to 2.0 including support for it.
-
Although I'd love to see IPv6 available in pfSense 2.0, I have to agree with the developers that it would just be too much work right now. I think they have done a great job with 2.0, and as we move into the late beta stages, it would be much more efficient to just get all the bugs fixed, and get 2.0 out before any though is given to rewriting a huge percent of the existing code to support IPv6. That said, if IPv6 does not appear soon post-2.0, I would be very disappointed.
I currently use IPv6 via the IPv6 passthrough that is in 2.0 to an internal Linux VM for testing. -
Ok, with the commit I just made to my own (public) repo I can now use ipv6 on my LAN.
A quick howto for getting started, this is by no means comprehensive. And most communication will work as it should, just rough around the edges.
Install a 2.0 BETA4 from the 26th or later, this has a changed apinger binary that supports ipv6 better (at all).
Get to the shell, run option 12, playback gitsync, use the alternate http:// url provided above.
reboot. All the IPv4 connectivity should still work as before.Create a account with www.tunnelbroker.net for a free /64 account. This works best on a a static or semi permanent ipv4 WAN address.
Make sure that a icmp allow rule is existing on the WAN interface for tunnel assignment by he.net to work.on pfSense go to assign, create a new gif interface, fill in the correct remote ipv4 remote address and ipv6 local and remote addresses.
Go to assign, press +, you should now have a new OPT interface listed. Call this what you want.
Go to the newly created OPT interface, enable it using config "none".
Go to routing, create new gateway on the new OPT interface, add the remote ipv6 here, check default (this is the 1st ipv6 default gateway). After enabling this the gateway status should list it as green, as well as the dashboard.You can now create a icmp allow rule on the OPT ipv6 interface to verify that a remote ipv6 host can ping it. http://lg.he.net is helpful here.
Go to interfaces LAN and change the type from ipv4 to ipv4 + ipv6. You can now enter the routed /64 address range given to you by he.net. I just used 2001:470:prefixhere::1 for the lan address, and 64 bits for the subnetmask.
I created a new ICMP rule on the OPT ipv6 interface to allow ipv6 icmp traffic to the LAN IP address. It works!
Next up is generating a rtadvd config for enabling stateless autoconfig on the LAN. After that dhcpd v6. -
for people on dynamic ipv4 connections there is a great help page out there that can reconfigure the he.net tunnel for the new IP address.
http://planetfoo.org/blog/2010/01/08/dynamic-ip-address-checker-dns-ipv6-tunnel-updater/
-
for people on dynamic ipv4 connections there is a great help page out there that can reconfigure the he.net tunnel for the new IP address.
http://planetfoo.org/blog/2010/01/08/dynamic-ip-address-checker-dns-ipv6-tunnel-updater/
I use my own Custom Dynamic DNS Script to keep my tunnel up to date, and it has worked great for me.
You have to md5 your password and user id by yourself and put in the url, but it sits in the web interface.
http://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=%IP%&pass=INSERT YOUR PASS HERE&user_id=USER ID HERE&tunnel_id=65635
and I use the Result Match "Your tunnel endpoint has been updated to: %IP%|That IPv4 endpoint is already in use." so that it checks if the returned value is correct.Note that you would still have to make sure that the tunnel is restarted to match the local IP Address (although I'd hope that gets added to the firewall update script that runs automatically when the IP updates already)
See http://forum.pfsense.org/index.php/topic,27704.msg148522.html#msg148522
-
technically running interfaces_gif_configure(); should be enough in /etc/rc.newwanip to reconfigure the gif tunnel. Although I'm not sure that really needs triggering. From the gif point of view the tunnel hasn't changed. It's only the remote side that needs a nudge.
DHCPv6 for the lan is proving a daunting task, it's taking longer then hoped.
-
technically running interfaces_gif_configure(); should be enough in /etc/rc.newwanip to reconfigure the gif tunnel. Although I'm not sure that really needs triggering. From the gif point of view the tunnel hasn't changed. It's only the remote side that needs a nudge.
I was assuming so, I just hadn't looked at your code.
I really love what you are doing here, I think it has been in need for a while now and the pfSense-IPv6 never went anywhere.
Although I'm not a great programmer, and I don't have too much time on my hands this weekend, I'd love to do anything I can to help starting sometime next week. If you need anything or want some idiot to program something, please ask. -
The dhcp server code is very tedious and not yet inline what a proper ipv6 config should be. For example, the static mappings in dhcpv6 do not use the hardware ethernet but something else.
http://tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-isc-dhcp.html
Just hoping to get a parsing config at this point and add all other bits later.
I just noticed that we still ship isc dhcp server 3.0.7. We need atleast 4. You can manually install the newer one by invoking pkg_add -r isc-dhcp41-server and then saving the dhcp configuration twice.Edit:
Ok, stateless autoconfig now works on the LAN side, still not picking up dhcpv6 on the LAN eventhough it is configured and running.
rtadvd is now started on the LAN interface for route announcement.
Don't forget to add a IPv6 LAN subnet to any rule on the LAN to get out of the network.I configured a DNS server manually on the ubuntu VM on the LAN and I was then able to browse to ipv6.google.com
-
I would strongly recommend having the default NOT use the ethernet MAC (hardware) address.
It is not required by the IETF.
http://playground.sun.com/ipv6/specs/ipv6-address-privacy.html
It is a bad idea for privacy.
-
databeestje, awesome work! Looking forward to testing all this next month.
-
I would strongly recommend having the default NOT use the ethernet MAC (hardware) address.
Yeah we won't default to that.
-
Just a heads-up: databeestje, awesome work!
I'd love to see IPv6 support in PfSense and these certainly are steps in the right direction.
-
Large ISPs like AT&T do not provide IPv6 support. I spoke to their technical service on the phone. They do not have any plans to go to IPv6. Many will look at the cost of upgraded routing equipment and shudder.
That's a lame excuse. The real reason ISPs drag their feed with the IPv6 transition is that with the limited IPv4 address space, they can extract a massive premium for a "business account" from everyone who wants/needs a fixed IP address e.g. to access their media server from everywhere.
Similarly, there's an entire slew of businesses that invade your privacy and rob you blind by providing services that are all based on the dearth of fixed IP addresses, e.g. home surveillance cameras that beam the video stream to a cloud server from which you can view it, against a hefty annual fee, of course.
If IPv6 were widespread and the excuses for that sorry thing called DHCP would go away, and everyone had access to 2^16 fixed IP addresses, every friggin' lightswitch in one's house could have a few IP addresses, and none of these "value added" services would have a reason to exist.
Scarcity is what drives prices up, and delaying IPv6 is an artificial way of introducing scarcity into a market where there truly is none, and thus allows big companies to extract exorbitant service fees from an unsuspecting public.
Similar considerations go for VoIP and the slow adoption of ENUM, etc. etc.Ronald
-
That's a lame excuse. The real reason ISPs drag their feed with the IPv6 transition is that with the limited IPv4 address space, they can extract a massive premium for a "business account" from everyone who wants/needs a fixed IP address e.g. to access their media server from everywhere.
Similarly, there's an entire slew of businesses that invade your privacy and rob you blind by providing services that are all based on the dearth of fixed IP addresses, e.g. home surveillance cameras that beam the video stream to a cloud server from which you can view it, against a hefty annual fee, of course.
If IPv6 were widespread and the excuses for that sorry thing called DHCP would go away, and everyone had access to 2^16 fixed IP addresses, every friggin' lightswitch in one's house could have a few IP addresses, and none of these "value added" services would have a reason to exist.
Scarcity is what drives prices up, and delaying IPv6 is an artificial way of introducing scarcity into a market where there truly is none, and thus allows big companies to extract exorbitant service fees from an unsuspecting public.
Similar considerations go for VoIP and the slow adoption of ENUM, etc. etc.Ronald
All too true.
A pal of mine is on several interest groups and one of the guys he met is on ipv6 development as well. They intend to eventually have household appliances like ovens and irons hold an ipv6 address with (powerline networking) or without networking (the ipv6 address then becomes a trackable serial number). As to whether this will work out….My next RSP is offering me 65535 globally routable ipv6 addresses for US$4.20/ mth.
Getting one static ipv4 costs me about US$58/ mth largely because they pay about that much for the addresses themselves.
It actually costs me less to buy a CIR/ PIR Service Level Agreement on a residential line than to pay for a single ipv4!
They even went as far as to convert their entire routing core internally to ipv6 so that they don't need to pay for ipv4 addresses. Only encapsulating where the outside world connects. The fact is that if all the ISPs around the world do this, we definitely have enough ipv4 left over to last us a much longer time.Over a basic 24 months contract, it actually costs me less to pay for a Cisco router (even before subsidies by my rsp) to PPTP back to their core and 1:1 NAT the ipv6 to a private ipv4 subnet as my wan addresses.
I would have gone for a Vyatta solution if it actually could do this but it appears support for cross ipv6-ipv4 routing is very limited at the moment. But it at least lets me use pfsense without much trouble. -
Awesome take, rcfa. Thanks.
-
Getting one static ipv4 costs me about US$58/ mth largely because they pay about that much for the addresses themselves.
It actually costs me less to buy a CIR/ PIR Service Level Agreement on a residential line than to pay for a single ipv4!Wow. I pay $4/month for a static ipv4 (dynamic is included) and I can buy subnets for under $2/address. The same ISP is testing ipv6 right now with free opt-in.
Don't worry, I make up for it with inflated subscription fees (thanks to the upstream telco for that).
-
Wow. I pay $4/month for a static ipv4 (dynamic is included) and I can buy subnets for under $2/address. The same ISP is testing ipv6 right now with free opt-in.
Don't worry, I make up for it with inflated subscription fees (thanks to the upstream telco for that).
It's the reverse for me.
The government is pushing out a nationwide broadband infrastructure to be completed by 2012 (GPON to every household paid for by tax monies; mine is coming in June next year) and prices are dirt cheap. It costs about US$41/mth for a 100m down/ 50m up GPON line.
The infrastructure provider gives a 25m CIR on the local circuits but the ISPs/ RSPs obviously don't include this for the end users. Since I happen to personally know one of the senior guys at one of the RSPs, I can get certain dubious perks/ vas provided on the residential line. :DComparatively, a 100m/10m cable subscription now is at US$70/ mth.
