Prefix stuck



  • JKnott 16 minutes ago
    As many are aware, I have had a problem with my ISP & IPv6. Weeks after I proved the problem was with the CMTS I'm connected to and identified it, my cable modem, in gateway mode, now works properly with IPv6. When I put the modem in bridge mode, connected to pfSense, IPv6 still fails. With Wireshark, I can see XID working properly and a new prefix is being assigned, as expected. However, pfSense is still sending out the old prefix to my LAN. Any idea what might be causing this? I have deselected "Do not allow PD/Address release". I'm currently running 2.4.4-p1, to be as close to what I had before I noticed the problem. This is a fresh install, as of this morning. Incidentally, I couldn't force a release before either.

    tnx jk

    Part of dhcpd.log attached, showing IPv6 portion

    dhcpd.log.txt



  • @JKnott

    This bit might be interesting.

    Apr 7 14:30:45 firewall dhcp6c[20640]: extracted an existing DUID from /var/db/dhcp6c_duid: 00:01:00:01:23:eb:5e:12:00:16:17:a7:f2:d3
    Apr 7 14:30:45 firewall dhcp6c[20640]: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
    Apr 7 14:30:45 firewall dhcp6c[20640]: failed initialize control message authentication


  • LAYER 8 Netgate

    Apr 7 14:30:45 firewall dhcp6c[20640]: extracted an existing DUID from /var/db/dhcp6c_duid: 00:01:00:01:23:eb:5e:12:00:16:17:a7:f2:d3
    Apr 7 14:30:45 firewall dhcp6c[20640]: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
    Apr 7 14:30:45 firewall dhcp6c[20640]: failed initialize control message authentication

    Normal.

    Apr 7 14:30:47 firewall dhcp6c[21443]: create a prefix 2607:fea8:4ca0:807::/64 pltime=3600, vltime=3600
    Apr 7 14:30:47 firewall dhcp6c[21443]: invalid prefix length 64 + 8 + 64
    Apr 7 14:30:47 firewall dhcp6c[21443]: invalid prefix length 64 + 8 + 64

    They are giving you a /64 not a /56.



  • This time I get a /56:

    Apr 7 15:40:46 firewall dhcp6c[40220]: create a prefix 2607:fea8:4c80:600::/56 pltime=3600, vltime=3600
    Apr 7 15:40:46 firewall dhcp6c[40220]: add an address 2607:fea8:4c80:600:w❌y❌z/64 on bge0
    Apr 7 15:40:46 firewall dhcp6c[40220]: add an address 2607:fea8:4c80:604:a🅱c:d/64 on em0

    However, I discovered that prefix is not assigned to the interfaces on the computers, but it is on the firewall. This led me to a setting I'd forgotten about. On the Router Advertisements page, there are "Subnets" boxes, which I had been using because I also have Unique Local Addresses assigned and had the old GUA prefix specified. Once I updated that, IPv6 now works.

    BTW, a subnet will automatically be used according to the interface, if not specified. Will that still work, if I leave one box empty and one with the ULA prefix?


  • LAYER 8 Netgate

    I use that to assign ULA to certain interfaces. They also get a PD. 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.

    Similar to this:

    https://redmine.pfsense.org/issues/8665

    I do not reboot very often so I can get around it by removing the ULA IP aliases, Saving WAN which triggers PD and assignment again, and adding ULA aliases back in.

    If the ULA address is listed in Status > Interfaces that interface will be broken for GUA access.



  • @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.


  • LAYER 8 Netgate

    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.


  • LAYER 8 Netgate

    I know but which one is the PD? Not talking capability here but logic in pfSense.



  • @Derelict

    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.


  • LAYER 8 Netgate

    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.



  • @Derelict

    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.


  • LAYER 8 Netgate

    What are you talking about? An empty box is ignored when you submit.



  • @Derelict

    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?


  • LAYER 8 Netgate

    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.


  • Rebel Alliance Developer Netgate

    @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?


  • LAYER 8 Netgate

    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.


Log in to reply