Project

General

Profile

Actions

Feature #177

closed

IPv6 support

Added by Chris Buechler over 14 years ago. Updated over 11 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
11/22/2009
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:

Description

(moved from cvstrac)

IPv6 support needs to be added at some point (post-2.0)

Actions #1

Updated by Chris Buechler about 14 years ago

  • Target version set to 2.1
Actions #2

Updated by Seth Mos over 13 years ago

I've started ipv6 work on pfSense-smos clone and I've started running into the 1st few issues which I'm documenting here and hoping for some code fixes.

Apinger needs to handle icmpv6 and the use of ipv6 addresses for the source and destination address. It appears to accept the destination address without much issue. But the later added srcip functionality logs a message. I am not sure if apinger ever supported the ipv6 type.
Oct 22 16:58:15 apinger: Bad srcip address 2001:470:1f15:daa::2 for target 2001:470:1f15:daa::1
Oct 22 16:58:15 apinger: Bad srcip address 2001:470:1f15:674::2 for target 2001:470:1f15:674::1

The pfSense module which is a binary blob is proving to be causing a few issues here and there as I can't code and setting up a builder just to get the basic functionality is a bit daunting.
A quick look at the C code revealed that adding a case for AF_INET6 should be enough to get the correct subnet information.

I've added a few lines of code that use the old style exec() calls to gather the required information. These are documented and will need to be replaced.
we can have seperate default gateways for IPv4 and IPv6, this should work as expected.
I can not ping the gateway yet, disabling pf gets my replies. Might be related to the global ipv6 disable toggle.
Only static ipv6 is configurable on the interfaces.php at this point and the addresses are succesfully assigned.

I've skipped processing the fe80:: link local addresses at this point.
sysctl net.inet6.ip6.auto_linklocal=0
Disables the link-local addresses for now. Not going there.

Added sysctl to enable ipv6 forwarding.
net.inet6.ip6.forwarding=1 Allow forwarding of IPv6 traffic 1

I've added inet6 icmp rules as it appears the default outbound firewall rules are not good enough. What works fine for ipv4 doesn't for ipv6. http://lists.freebsd.org/pipermail/freebsd-doc/2007-May/012450.html

I've added a barebones rule so that icmp works.
pass quick inet6 proto ipv6-icmp from any to any icmp6-type {neighbradv,neighbrsol,routeradv}
PING6 2001:470:1f15:674::2 --> 2a00:1450:8001::63
16 bytes from 2a00:1450:8001::63, icmp_seq=0 hlim=56 time=11.714 ms

Having a look at userspace now to see if apinger can be fixed.

dhcpv6 and autoconfig not looked at yet.

/usr/sbin/rtadvd is already in the image, needs a config to enable LAN routing for route advertisements.

Actions #3

Updated by Seth Mos over 13 years ago

patch checked in to git that should fix apinger for ipv6. It's now showing both my ipv4 wans up as well as the ipv6 gateways.

For the firewall rules I have added a drop down on the firewall rules edit page which allows selection of ipv4 or ipv6.
This sets the inet or inet6 tag on the firewall rule. With a quick check on a online ipv6 port scan website I've been able to verify the operation of ipv6 icmp and tcp firewall rules to the ipv6 wan address.
I have defined the "ipprotocol" variable on the firewall rule array that defines if it should apply to ipv6 or ipv4 traffic. No existing tag defaults to inet which should have no impact on firewalling. Would this cause issues with all rules?

This is also used to determine if we need to use the ipv6 addresses in the firewall rules over the ipv4 addresses.

The firewall rules page now displays if it applies to ipv4 or ipv6.

Actions #4

Updated by Seth Mos over 13 years ago

gen_subnet() needs to become ipv6 aware
trying to delete a ipv6 state from the traffic states results in an error.
filterdns needs to understand the /128 subnetmask of ipv6 hostnames. It throws a invalid subnet error.

Actions #5

Updated by Seth Mos over 13 years ago

Created a forum topic and added a quick howto to get a /64 routed onto the LAN via a he.net tunnelbroker.
http://forum.pfsense.org/index.php/topic,26469.msg153037.html#msg153037

Actions #6

Updated by Seth Mos over 12 years ago

  • Status changed from New to Feedback

Most of the basic system now works with IPv6.

Large things that don't work.
- PPTP Client. not checked into. Is that even possible.
- PPPoE Server. Sends IPv6-CP packets, not confirmed if DHCPv6 server works.
- WAN. default router advertisements still not picked up, needs FreeBSD patch. See Ticket #1568.
- WAN. Stateless autoconfig not supported, not sure why you would want it, upstream needs to know how to route. Appliance? Same deal?
- WAN. rc.newwanipv6 needs work. Might need to converge with rc.newwanip to avoid race and stepping on each other causing recursive configure.
- WAN. DynDNS class needs to incorporate support for dynamic DNS with a Quad A.
- WAN. proxy NDP requests? What does that do and what for.
- Captive Portal. Needs a ipfw6 otherwise won't work.
- Traffic Shaper. Too scared to touch.
- Load Balancer. Bill? You here?
- uPNP. Needs IGD-2.0 Spec from miniupnpd from devel.
CARP. need to be able to bind router advertisements to CARP link-local.

Actions #7

Updated by Chris Buechler over 12 years ago

I can't envision any scenario where you'd need proxy NDP, though maybe something will come up in the future. On the remaining items, I opened individual tickets for those.

Actions #8

Updated by Chris Buechler over 11 years ago

  • Status changed from Feedback to Resolved

we have as feature-complete IPv6 as pretty much anything, and better in ways than many commercial and open source alternatives. Still other individual feature requests on specific items open, closing this one since this is done.

Actions

Also available in: Atom PDF