Prefix stuck
-
@Derelict said in Prefix stuck:
But it's broken since you have to put an IP alias for the ULA on the interface and if it is listed first on the interface, everything breaks.
Is that a problem with pfSense or FreeBSD? Does anyone have plans to fix it? I've also seen that problem.
-
Likely pfSense. pinging @jimp
There was a discussion about it before. I looked at the code and couldn't track what it is doing. It jumps all over the place.
It is hard to say exactly what the behavior there should be. One of the main problems is there is no good way to get the PD out of dhcp6c I think. It is responsible for assigning the /64s to the interfaces themselves. pfSense gets it from the interface. But what if you have multiple GUA prefixes on an interface? What should happen? Which is the PD? What if the PD is ULA from an inside DHCP6 server?
It gets pretty complicated pretty fast.
Bypassing ULA addresses on an interface when looking for a PD to set up DHCP6/RA seems like a reasonable course of action to help people who wish to implement RFC7368 homenets.
Or maybe bypassing prefixes that are listed as additional prefixes in DHCP6/RA.
-
@Derelict said in Prefix stuck:
But what if you have multiple GUA prefixes on an interface?
That is entirely supported by IPv6, so there's no problem with having them. A lot of people seem to be stuck with IPv4 thinking, where you'd normally have only one "network" on an interface. IPv6 was designed to have multiple prefixes of multiple types. The only exception is there's just one link local address.
-
I know but which one is the PD? Not talking capability here but logic in pfSense.
-
I'm not sure what you're getting at. One thing that IPv6 supports is multiple networks with their own default route. Each router can have a priority assigned to it's default route. If you have multiple ISP connections, then you might need multiple prefixes. As a router, pfSense can manage more than one Internet connection, though there has to be some mechanism to have a priority default route. Regardless, there's a difference between multiple Internet connections and GUA and ULA prefixes, in that there'd normally be only one Internet connection. Traffic to the ULA is just a matter of routing rules.
-
But pfSense has to do a lot of work for a prefix delegation. It has to enable DHCP6 dynamically, SLAAC, RA, etc. There is not a good way to get that information from dhcp6c so it has to get it from the interface itself. If there are multiple ULA and GUA prefixes there, which one is the PD?
Ultimately it would be great to update an Alias, OpenVPN and IPsec Mobile tunnel networks, etc, just like Track Interface.
We all get what you are saying. We're talking about the work that has to be done for a PD and how to determine what the PD is, etc.
I am warming to the idea of building a list of manually-configured prefixes (RA, Virtual IPs, etc) and skipping those when determining which prefixes are dynamically-assigned.
-
Getting back to my question about the subnet boxes on the Router Advertisements tab. What happens if there are two boxes, one left blank and one configured with the ULA prefix. Will the GUA prefix be determined by the actual prefix, as is the case when there's only one box and it's left blank? That would have avoided the problem with pfSense, after the ISP's problem was fixed.
-
What are you talking about? An empty box is ignored when you submit.
-
From the Router Advertisements tab:
"Subnets are specified in CIDR format. Select the CIDR mask that pertains to each entry. /128 specifies a single IPv6 host; /64 specifies a normal IPv6 network; etc. If no subnets are specified here, the Router Advertisement (RA) Daemon will advertise to the subnet to which the router's interface is assigned."
If you have one empty box, as is default, the RA uses the assigned prefix. Putting a prefix in that box means that it will always be used, regardless if it's the correct one. That was the cause of my problem. Now, if you want to use ULA, then you need to specify a prefix for it. If you use just the one box, the ULA prefix won't be advertised, so you need two boxes, one for ULA and one for GUA. What happens if you put the ULA prefix in one, but leave the other blank? Will it then use the assigned prefix for the GUA?
-
Not my experience at all. It has more to do with the order on the interfaces as specified above.
The GUA prefix from the PD/Track Interface should be automatic. If the ULA is specified first on the interface itself this breaks.
An empty box in the RA form is ignored and meaningless.
-
@Derelict said in Prefix stuck:
It is hard to say exactly what the behavior there should be. One of the main problems is there is no good way to get the PD out of dhcp6c I think. It is responsible for assigning the /64s to the interfaces themselves. pfSense gets it from the interface. But what if you have multiple GUA prefixes on an interface? What should happen? Which is the PD? What if the PD is ULA from an inside DHCP6 server?
It gets pretty complicated pretty fast.
This is it. We are severely limited by what
dhcp6c
can do here. It doesn't supply the prefixes to pfSense in a way that can be effectively used for scripting. It puts the addresses on interfaces directly and that's about it.A while back someone had volunteered to submit changes for dhcp6c to allow it to pass the delegation off to a script and let it handle the necessary changes, but I don't think that ever materialized. That's also what is holding us back from using delegated prefixes for things like NPt, VPNs, etc.
-
I know that ipv6 supports multiple GUA addresses at a device, but I assumed that when the prefixes were not the same it was probably due to multiple routers, each responding to RA's. I thought that one router would only be handing out one prefix. So if you had 2 prefixes you could have 2 routers on your interface for path and router redundancy.
So if you wanted to use ULAs and GUA's wouldn't it be better to have one set of routers handing out and routing ULA address, and a different router handing out GUA addresses?
Would that work? It would seem to make more sense than expecting multiple prefixes coming in through one DHCPv6?
-
Having multiple GUAs on a host puts a lot of the burden on that host for choosing the desired source address for a particular connection.
The pfSense routing role could be handled right now using existing policy routing rules based on the source IPv6 address. This source, out this WAN, that source, out the other WAN.
But the decision moved to the host as to which source address is used for a particular connection.