DHCP6 open question

rcfa

DHCP6 never worked for me here. Not sure if OSX' "automatic" means DCHP or SLAC…

Still there was this post:
http://forum.pfsense.org/index.php/topic,50481.msg268967.html#msg268967

Copied from (with some modifications): DHCPv6 - Understanding of address configuration in automatic mode and installation of DHCPv6 Server

An IPv6 host performs stateless address autoconfiguration automatically and uses a configuration protocol such as DHCPv6 based on the following flags in the Router Advertisement message sent by a neighboring router:

Managed Address Configuration Flag:
Also known as the M flag. When set to 1, this flag instructs the host to use a configuration protocol to obtain stateful addresses.

Other Stateful Configuration Flag:
Also known as the O flag. When set to 1, this flag instructs the host to use a configuration protocol to obtain other configuration settings.

Combining the values of the M and O flags can yield the following:

Both M and O Flags are Set to 0: (pfSense: Unmanaged)
This combination corresponds to a network without a DHCPv6 infrastructure. Hosts use router advertisements for non-link-local addresses and other methods (such as manual configuration) to configure other settings.

Both M and O Flags are Set to 1: (pfSense: -)
DHCPv6 is used for both addresses and other configuration settings. This combination is known as DHCPv6 stateful, in which DHCPv6 is assigning stateful addresses to IPv6 hosts.

The M Flag is Set to 0 and the O Flag is Set to 1: (pfSense: Assisted)
DHCPv6 is not used to assign addresses, only to assign other configuration settings. Neighboring routers are configured to advertise non-link-local address prefixes from which IPv6 hosts derive stateless addresses. This combination is known as DHCPv6 stateless: DHCPv6 is not assigning stateful addresses to IPv6 hosts, but stateless configuration settings.

The M Flag is Set to 1 and the O Flag is Set to 0: (pfSense: Managed)
In this combination, DHCPv6 is used for address configuration but not for other settings. Because IPv6 hosts typically need to be configured with other settings, such as the IPv6 addresses of Domain Name System (DNS) servers, this is an unlikely combination.

–

Maybe someone from the developers involved in the IPv6 code could comment why pfSense uses the M and O flags mutually exclusive. Before looking at the code I thought that the Managed case would have both M and O flags set.

To this I've not seen an answer anywhere. It would seem that if this is correct, pfSense does the wrong thing.
Otherwise, since I'm in the process of learning about all that, I'd like to know in what respect the above is wrong.

Thanks!

bardelot

Apparently that information was wrong and pfSense is handling the M and O flags absolutely fine. So to clear up the confusion that I created here's what the RFC says about the M flag and it's relation to the O flag.

M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].

                     If the M flag is set, the O flag is redundant and
                     can be ignored because DHCPv6 will return all
                     available configuration information.

http://tools.ietf.org/html/rfc4861#section-4.2

rcfa

Just to add to this:
BEWARE OF SNORT.

The issue is, at least some builds in the past or maybe even now, don't properly show in the GUI as running, when in fact they are. Now my IPv6 works, and DHCPv6 seems to work, too, since I have Snort set not to block anything.
I had it set to block rule offenders, but since it "wasn't running" wasn't considering it a potential source of the problem. Turns out it was doing something, even though the GUI made me believe it was off…

Sorry I can't be more precise in this matter, but given that the Snort package seems to be in flux, it may not apply anymore anyway, but it's something to keep in mind. Don't necessarily trust anything that claims not to be active...

databeestje

I'm pretty sure that nobody has touched the snort package to work with IPv6 yet. So that probably means that if you use snort you kill your IPv6.

You would at a minimum require the local interfaces to be setup in snort to prevent it from blocking it's own interfaces.

rcfa

@databeestje:

I'm pretty sure that nobody has touched the snort package to work with IPv6 yet. So that probably means that if you use snort you kill your IPv6.

You would at a minimum require the local interfaces to be setup in snort to prevent it from blocking it's own interfaces.

Well, I added the IPv6/IPv4 addresses of the tunnel endpoints to the whitelist as well as the, and the various "autogenerated IPs" checkboxes on the whitelist page, so I figured that would do the trick, assuming these auto-generated addresses would take care of both IPv4 and IPv6 addresses, maybe not.
Also, some of the interfaces added to snort only have an IPv6 address, like the tunnel interface, so I also assumed that being able to do that would mean that snort understands IPv6. Similar, I'd have assumed that adding the LAN interface which has both IPv4 and IPv6 addresses, would lead snort to "get it" that these are local addresses.
So how does Snort figure out what is a "Home net" and what's an "External net"???

Oh well…

The real issue that tricked me, however, was that snort was indeed running, while the status indicated that it wasn't...

In any case, for now, snort is disabled, and IPv6 is back. It was already back with snort enabled and blocking disabled, but I don't need snort just to fill my log files with triggered rules, so if I can't use it to auto-block unwanted traffic, it's kind of pointless, particularly given its resource use.