Radvd with multiple prefixes
-
Hello,
i tried to add multiple prefixes to my RA config, but /var/etc/radvd.conf only contains one. And with wireshark I can see only one advised, too. Am i'm doing something wrong or is there a bug?
-
I think in general the assumption is that you have a single prefix per network segment. How do you expect this to work anyway? E.g., which of the prefixes would a connecting client configure itself for?
-
It's the same if you tried to serve two different DHCP address ranges on the same broadcast domain. There would be no way to disambiguate which range is to be used for a client requesting an address (except for static mappings).
-
IPv6 is DESIGNED to have multiple addresses bound to an interface. It has a somewhat complex logic to choose the best address depending on which destination is to be reached. Don't try to apply ipv4 thinking to ipv6 - it does not work ;). I myself want exactly that. I want two networks. One is private where I can reach ANY device within my network (yes, it is routed - ULAs route just fine) and I want a public network. So anytime I connect to a local device the local ULA address is choosen and when connecting to an internet device the global address is choosen.
-
Please describe in detail how would the router advertisement and SLAAC work with two distinct /64 prefixes on the same physical wire (just making it simple, what I really mean is on the same logical broadcast domain). I believe you run into trouble very quickly trying to explain how it would work reliably and in a predictable way.
-
For the future record, it is common and expected to support multiple prefixes in IPv6 deployments. In particular, nodes are assumed to have any combination of link-local, unique-local, and global IP addresses, and one or more of each.
It's well-documented in the RFCs and in some implementation notes:
RFC 4193 - Unique Local IPv6 Unicast Addresses
http://tools.ietf.org/html/rfc4193RFC 7157 - IPv6 Multihoming without Network Address Translation
http://tools.ietf.org/html/rfc7157RFC 4864 - Local Network Protection for IPv6
http://tools.ietf.org/html/rfc4864RFC 6724 - Default Address Selection for Internet Protocol Version 6 (IPv6)
http://tools.ietf.org/html/rfc6724RAs for multiple subnets can and should be supported.
-
@kpa:
Please describe in detail how would the router advertisement and SLAAC work with two distinct /64 prefixes on the same physical wire (just making it simple, what I really mean is on the same logical broadcast domain). I believe you run into trouble very quickly trying to explain how it would work reliably and in a predictable way.
In layman's terms:
-The router always a link-local address fe80::
-When the ISP delegates a IPv6 public prefix and the internal interface is mapped to use it, that prefix gets advertised to the internal broadcast domain.
-The clients learn when to use the link-local and when to use the global address when they need to reach something on the local link or on the rest of the Internet.
^^^
The above is what we already do today in pfSense, and everyone gets that just fine. Note we have two addresses on the interface, and all works well!What many of us want is the ability to define a Unique Local Address (ULA).
Think of the ULA just like the link-local address. It has a special prefix (fc00::/7), and the IPv6 stack of all clients know that ULA addresses are not global addresses.
So, the exact same method is used as above, but pfSense would allow for an interface to have both a tracked interface, and a static ULA address. Then it would have:
-link local (auto-created)
-ULA (Static, user created)
-Tracked Prefix (from WAN)The perfect solution to me would be to send the Tracked prefix using RAs, and the ULA using DHCPv6. However, if pfSense sent both ULA and tracked ranges, the clients would understand.
The reason ULA is important is that it allows us to create an internal network (or mesh VPN) with addresses that never change.
Another use of ULA is so I can have a VPN setup to all of my clients that can be overlaid on their internal network even if they don't have IPv6 from their ISP. This would allow my to connect over IPv6 to all of them directly without having to deal with all of the NATing I have to do today, since all of them use 192.168.1.0 today for their internal networks.There are a LOT of really useful things you can do with ULA!
-
Yes this is something that should work. Bug ticket open:
https://redmine.pfsense.org/issues/4468 -
Since 2.2.1 it is broken for me, workaroundable though.
I get my prefix through DHCP-PD. Therefore I am forced to track the WAN interface, which disables RA/DHCP configuration. It is workaroundable by injecting raw config sequences in the advanced dhcp area for the wan interface, which basically does enforce DHCP-PD and disregards if track interface is on.
Injecting raw config in a high level UI, as pfsense webui is, is always bad. Whoever though that DHCP-PD sould not be done when no track interface is enabled did not thing through all the use cases.
-
Since 2.2.1 it is broken for me, workaroundable though.
The issue discussed in this thread is fixed in 2.2.2 (and never worked prior to 2.2.2). The issue you describe is completely different.
Whoever though that DHCP-PD sould not be done when no track interface is enabled did not thing through all the use cases.
There have been maybe a handful of people that were affected. The previous behavior would cause dhcp6c to make constant requests if it didn't get PD which caused problems for more people than had problems by this change in behavior. Sometimes making things appropriate for the majority breaks a small minority. We try to avoid that as much as possible, but it's not always possible to fix things for the majority without breaking for the minority.
-
Did I understand this correctly: dhcp6c constantly tries to get a PD because I told it I want a PD? Well it should! If I don't want it to do it why would I tell it, that it should fetch a PD? Those that have issues with that should simply untick the checkbox, why make it overly complex and intransparent when a PD is fetched and when not? Simple solution as it has been: Checkbox checked: fetch PD, not checked: dont fetch PD. Now it depends if an interface has track interface enabled or I circumvent it by talking directly to the deamon in its config language. For the sake of simplicity and transparency please revert it. And please, dont say who is a majority and a minority, you probably have no full analysis of that, its not a very scientific argument and just makes bad feelings - despite, this argument is highly dynamic and can change easily over time, but you probably dont track that.