Is a dynamic alias or variable for IPv6 Prefix scheduled?
-
Yes, but: Blocking outgoing trraffic would just not work this way because the firewall does not know the temporary addresses. Actually if the firewall is not enabled to know the self assigned IPv6 addresses of hosts then the privacy extensions will not work (or there will be no safe way of blocking outgoing traffic).
Using a DHCPv6 would work of course but that would be a pity.
Well, if you need to control outgoing traffic for individual hosts, I think DHCP-assigned addresses are the best solution. With SLAAC, you don't really know how the host constructs the host ID. E.g. Windows doesn't use the MAC address, but a random ID, which can change if the host is re-installed.
-
think DHCP-assigned addresses are the best solution.
Further up the thread, I mentioned filtering on MAC addresses. That can be done on Linux, with IPTables and with at least some Cisco gear. This could easily solve the problem, as then you wouldn't have to worry about what local IP address was. According to what I found with a Google search, pfSense is supposed to be able to filter on MAC, but I don't see any way when setting up a rule.
-
Further up the thread, I mentioned filtering on MAC addresses. That can be done on Linux, with IPTables and with at least some Cisco gear. This could easily solve the problem, as then you wouldn't have to worry about what local IP address was. According to what I found with a Google search, pfSense is supposed to be able to filter on MAC, but I don't see any way when setting up a rule.
Filtering on L2 is not straightforward with ipfw/pf in FreeBSD (AFAIK the only way to do it is to tag the packet on the interface and then filter based on the tag). Also, it doesn't help when filtering ingress traffic for a host on the WAN interface, or when the packet is coming from another internal subnet.
But what is the problem with using DHCP? You can also run in "assisted" mode to run hosts using SLAAC and DHCP in the same subnet.
Another good solution would be SLAAC with RFC 7217 identifiers, but it's unfortunately not widely supported yet.
-
With SLAAC, you don't really know how the host constructs the host ID. E.g. Windows doesn't use the MAC address, but a random ID, which can change if the host is re-installed.
I envisioned a self learning feature in the firewall for this reason based on the MAC address.
Does Windows really not use the MAC address in Ethernet frames?? I wasn't aware of this. Does Microsoft give any reason for this behavior? How should network infrastructure be able to identify a host then? This seems very strange to me, but hey, I'm not a network engineer. :-)
-
Does Windows really not use the MAC address in Ethernet frames??
You can't have Ethernet without MAC addresses. It's how a NIC decides whether a frame is addressed to it. On the other hand, SLAAC IPv6 addresses can be based on the MAC or a random number. Either or both can be used, depending on configuration. I prefer to use both, so that outgoing connections have a random address, but the DNS points to the MAC based addresses, for incoming connections.
-
Does Windows really not use the MAC address in Ethernet frames?? I wasn't aware of this. Does Microsoft give any reason for this behavior?
By default Windows builds SLAAC addresses using random interface IDs for privacy and security reasons (so the device's MAC addresses don't leak out to the Internet). These IDs remain static for the lifetime of the OS installation (they are stored in the Windows registry). You can disable this though, in which case it uses the EUI-64 like most other operating systems.
Note that Windows can create temporary privacy addresses in addition to that.
How should network infrastructure be able to identify a host then?
You can in principle use the SLAAC addresses produced by Windows just like those produced with EUI-64, since they remain static as long as the OS isn't re-installed.
Generally, you can never rely on any v6 device using EUI-64 to build the SLAAC addresses, since the RFCs allow other types of ID as well.
Another issue are the temporary privacy addresses that most OSs generate. Very difficult to manage for things like logging, audit, filtering etc.. That is one reason why admins often prefer to assign addresses via DHCP, because it effectively disables the use of privacy addresses.
-
Ah ok: A random ID is used for the creation of an IPv6 address, Ethernet is however still required to use MAC addresses in Windows.
This would have no impact on the suggested self learning of IPv6 host part of addresses by the firewall based on the MAC address.
-
Ethernet is however still required to use MAC addresses in Windows
It's required, Windows or not, for Ethernet to function. In addition to NICs recognizing frames for them, switches also use MAC addresses to learn how to forward traffic.
BTW, MAC addresses go back before there even was a Windows. In Novell Netware, your IPX address was based on a 16 bit network address and the 48 bit MAC address There was even one network called ARCNET, which used 8 bit manually configured (switches or jumpers) MACs. With it, it was quite possible to get duplicate MACs on a network, which could cause a bit of "fun".
-
Not sure if this was resolved in a separate thread, so apologies for bringing up an older thread that may already be solved.
I'm trying to setup a dynamic alias for specific client machines - so the 64-bit client ID / MAC address is known (ie. a1b2:c3d4:e5f6:7890). The 64-bit prefix is variable from the ISP, so I'm trying to "wildcard it".
In the alias, I put the IP as: [0000-ffff]:[0000-ffff]:[0000-ffff]:[0000-ffff]:a1b2:c3d4:e5f6:7890
When I click Save, it fails saying: "Please match the requested format".If this has already been solved another way, I'd appreciate the link to the solution.
-
@Double:
I'm trying to "wildcard it".
In the alias, I put the IP as: [0000-ffff]:[0000-ffff]:[0000-ffff]:[0000-ffff]:a1b2:c3d4:e5f6:7890
When I click Save, it fails saying: "Please match the requested format".Eeeeeeeeeeeh??? Huh?!?!
-
I think this problem would be solved already if pfSense would not be restricted to CIDR. If a full subnet mask would be used, the top 64 bit could just be left 0 and the lower 64 bits (or at least the EUI-48 part could be 1 so that the IP+subnet mask would ignore the IPv6 prefix and only match the host-specific part. That's how firewall rules for dynamic IPv6 subnets can be easily implemented in ip6tables on Linux.
I have idea however if the CIDR restriction is a pf issue and whether a full subnet mask can be easily implemented.
Stefan