For hosts with wired and wireless nics, utm does not allow multiple ip addresses to be set. For ipv4, where the unique mac addresses can be used to identify the wired and wireless nics, utm only allows one ipv4. If a laptop is connected to the network using the wired nic, then using the wireless nic, there will be an address collision. The only workaround is to allocate two hosts, one for wired and one for wireless. This is a duplication of effort and also wastes licences. It should be possible to assign as many addresses to a host as there are nics. This bug affects both ipv4 and ipv6, although with the DUID bug, there is no way to uniquely identify multiple nics.
Well the workaround for ipv4 is to create separate host definitions for each interface. As already discussed, this won't work with ipv6 because the duid is not unique among multiple interfaces on the same host.
Licensing is per ip so what you're claiming being an issue is exactly how the licensing was designed and should work.
I have ipv4 and ipv6 addresses set up for most of my computers, all of the ones that are not servers. It's a given that dual stack networking is going to be the norm for years. For laptops which have wired and wireless nics, I have both addresses set up. As I pointed out in the other thread, this is problematic for ipv6 due to the DUID issue. Irrespective of whether licensing is based on hosts or ip addresses, having to configure multiple "hosts" due to limitations of configuration is unfortunate. In my opinion, it's preferable for all of the addresses pertaining to one host to be configured and managed as a group. A separate case would be for virtual machines, which I consider separate, even if they are using one physical nic.
Hi, ISTM the licensing part would discourage many customers from implementing IPv6. Maybe the license counter could not count both IPv4 and IPv6 where the MAC is the same? Barry
The problem with DHCPv6 is that there is no such thing like a MAC address in the standard and protocol. For that reason it's also not possible to do static mappings using a MAC address with DHCPv6.
Bimmerdriver, I've myself made a request to product management one day ago to get multiple IPs per host definition being implemented. As far as concerns DHCPv6, we probably wait for next feature release of ISC DHCP ESV and then integrate that into UTM with the new IPv6 features. IPv6 may become more common now and appear as "new" for many users, but it's already more than ten years old and lacks some features that IPv4 got in the meantime. So it's not necessarily more advanced than IPv4 in every aspect as most people would expect. It's time for the protocol to catch up feature-wise. But you cannot declare such lacks as bugs.
The problem with DHCPv6 is that there is no such thing like a MAC address in the standard and protocol. For that reason it's also not possible to do static mappings using a MAC address with DHCPv6.
True, there is not a mechanism to use the MAC address, but dhcpv6 has the IAID, which is unique. If utm used the IAID instead of the DUID, it would be possible to use it to set unique addresses for wired and wireless interfaces.
Bimmerdriver, I've myself made a request to product management one day ago to get multiple IPs per host definition being implemented. As far as concerns DHCPv6, we probably wait for next feature release of ISC DHCP ESV and then integrate that into UTM with the new IPv6 features. IPv6 may become more common now and appear as "new" for many users, but it's already more than ten years old and lacks some features that IPv4 got in the meantime. So it's not necessarily more advanced than IPv4 in every aspect as most people would expect. It's time for the protocol to catch up feature-wise. But you cannot declare such lacks as bugs.
Thanks for the reply. Agreed, it's time for ipv6 to become more mainstream. I think one of the reasons it's taken so long is because some changes that seem gratuitous were introduced, making it less seamless to support. I think a mechanism is already in dhcpv6 to accomplish what is required, unfortunately it works differently than dhcp and requires more effort to utilize. That's what I meant when I called it a "bug". Using an identifier that is not unique to identify something that is unique doesn't work. Anyway, I think you get the point. Thanks again.
