IPv6 Prefix ID per IPv6 enabled interface

netravnen · Wed Jul 26, 2023 11:53 pm

@MikroTik, Does RouterOS v7 support specifying a static "IPv6 Prefix ID" on per-interface basis?

Just rebooting my MikroTik router is a frustration. Due to every IPv6 enabled Local Area Network Interface changing the assigned /64 Subnet.

To clarify, my provider assigns a reasonbly static /48 v6 prefix via DHCPv6. Which rarely changes.

On the Local Area Network side. It feels like /64's are assigned randomly...?

Whenever I create a new L2 domain (subint). The next in line /64 is then assigned to the new L2 domain.

*And* whenever I upgrade to latest stable in the v7 release branch. (Or for other reasons reboot the router). I observe the L2 domains ("segments") very often get a new /64 compared to the prior one before reboot.

From other router platforms (e.g. pfSense). I have observed they implement a "IPv6 Prefix ID" to ensure the sub-delegated /64 on the Local Area Network side from the SP-delegated /48 block uses the same "ID" (the 4th group in the v6 prefix, 2000:db8:0456:<4th>:<host-bits>). Even if the delegated /48 prefix from SP changes.

My question is: Does RouterOS v7 (as of 7.10.2) have any configuration knob to ensure the same "ID" is used to sub-delegate /64's from SP-delegated /48? (I.e. the 4th group does not change)

Example,
Int, before, after
Interface 1, 2000:db8:0:0::/64, 2000:db8:0:0::/64
Interface 2, 2000:db8:0:1::/64, 2000:db8:0:1::/64
Interface 3, 2000:db8:0:4::/64, 2000:db8:0:2::/64
Interface 4, 2000:db8:0:3::/64, 2000:db8:0:4::/64
Interface 5, 2000:db8:0:2::/64, 2000:db8:0:3::/64

Kentzo · Thu Jul 27, 2023 1:18 am

Are you talking about DHCPv6 server handing out Prefix Delegation downstream or from-pool address assignments for SLAAC? The former has static bindings, also the clients can hint what they want. As for the latter, it does appear to be sequential in no particular order and there doesn't seem to be a way to specify custom subnet identifier.

netravnen · Sat Jul 29, 2023 12:24 am

Hi,

My main issue/trouble with how the Prefix ID assignment is done. Is that I reboot the router (software upgrade). I cannot count on the Prefix (i.e. the /64 sub-delegated [by the ROS router] out of SP delegated /48) being stable. Meaning I experience a changing /64 Prefix. Which is quite annying. When the Local Area Network side IPv6 DNS server needs to be hardcoded by it's IPv6 address. -> Resulting in me needing to go around a handful of lxc container, 4 MikroTik devices, to update the previous IPv6 DNS address. It is not the providers fault. As the delegated IPv6 /48 stays stable for many months at a time.

(The issue is mostly prevalent for interfaces having been created since last reboot. That is most expected to be Prefix renumbered with a new /64 after reboot)

Cutout of the IPv6 configuration. Estimated to contain the most vital parts.

[admin@router] > /ipv6/export 
# RouterOS 7.10.2

/ipv6 dhcp-server option sets
add name=ip6-dns options=dns-server-1

/ipv6 address
add address=::4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1
add address=::4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3996
add address=::4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3994
add address=::4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3993
add address=::4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3992

/ipv6 dhcp-server
add address-pool=delegation dhcp-option=ip6-dns interface=bridge1 lease-time=1h name=server1 rapid-commit=no
add address-pool=delegation dhcp-option=ip6-dns interface=bridge1.3996 lease-time=1h name=server2 rapid-commit=no

/ipv6 nd
set [ find default=yes ] dns=****:****:****:4004::53 hop-limit=32 interface=bridge1 managed-address-configuration=yes mtu=1500 ra-interval=20s-1m ra-lifetime=50m \
    ra-preference=high reachable-time=33m20s retransmit-interval=4m
add dns=****:****:****:4004::53 hop-limit=32 interface=bridge1.3996 managed-address-configuration=yes mtu=1500 ra-interval=20s-1m ra-lifetime=50m ra-preference=high \
    reachable-time=33m20s retransmit-interval=4m
add dns=****:****:****:4004::53 hop-limit=32 interface=bridge1.3994 managed-address-configuration=yes mtu=1500 ra-interval=20s-1m ra-lifetime=50m ra-preference=high \
    reachable-time=33m20s retransmit-interval=4m
add dns=****:****:****:4004::53 hop-limit=32 interface=bridge1.3993 managed-address-configuration=yes mtu=1500 ra-interval=20s-1m ra-lifetime=50m ra-preference=high \
    reachable-time=33m20s retransmit-interval=4m
add dns=****:****:****:4004::53 hop-limit=32 interface=bridge1.3992 managed-address-configuration=yes mtu=1500 ra-interval=20s-1m ra-lifetime=50m ra-preference=high \
    reachable-time=33m20s retransmit-interval=4m

/ipv6 nd prefix default
set preferred-lifetime=30m valid-lifetime=1d

~= Yes. /64's beeing handed out from a delegation pool. With the /48 v6 delegated prefix being fetched from upstream SP-DHCPv6 server using DHCPv6-PD.

Kentzo · Sat Jul 29, 2023 2:46 am

RouterOS doesn't seem to allow you to pick subnet ID.

I'm using a DHCPv6 Client's script to update static DNS records and firewall's address lists. Hopefully you can adopt it for you needs.

DarkNate · Sat Jul 29, 2023 4:52 am

First you're doing bridge VLAN filtering incorrectly, only a single bridge should exist to ensure hardware offloading and bridge fastforrward/fastpath works:
https://help.mikrotik.com/docs/display/ ... +switching
https://help.mikrotik.com/docs/display/ ... plebridges

Second MikroTik supports static /64, assuming your PD is static, I'm using static /64s from the PD pool as we speak, nothing changes on reboot. You're clearly doing it wrong.

Kentzo · Sat Jul 29, 2023 5:26 am

I do not know about prefix delegation by RouterOs’s DHCPv6 Server, but from-pool address assignments do get shuffled and optimized whenever DHCPv6 client renews.

Consider adding 3 addresses, then remove the 2nd one and finally renew. You will see RouterOS changing subnetID of the 3rd address to be immediately after the 1st

DarkNate · Sat Jul 29, 2023 5:47 am

but from-pool address assignments do get shuffled and optimized whenever DHCPv6 client renews.

Consider adding 3 addresses, then remove the 2nd one and finally renew. You will see RouterOS changing subnetID of the 3rd address to be immediately after the 1st

Nope, even when the router REBOOTS, which I don't think you understand it means DHCPv6 client renews, whenever the PD is static from upstream, irrelevant if it's Cisco, Juniper, Huawei or MikroTik, the subnet-ID aka a specific ::1/64 on VLAN1, ::2/64 on VLAN2, ::3/64 on VLAN3 NEVER changes. You're doing it wrong if it does.

biomesh · Sat Jul 29, 2023 6:08 am

@DarkNate this can happen. Lets say you get a /60 from your isp from a dhcp client and put it in a pool of /64s. You assign 3 /64 prefixes from a pool to different vlan interfaces. Even if you reboot, the pool assignments are not stored on disk and not saved to disk. These are resident in memory, so a reboot could shuffle the assignments around.

If you know a way to resolve this (which Mikrotik support has not been able to address in the past) then please share.

In my previous communication with support I suggested the addition of a preferred prefix option that could be used/updated for use on reboots.

Kentzo · Sat Jul 29, 2023 6:20 am

You're doing it wrong if it does.

I suggest you try following the steps above to see for yourself that RouterOS will re-shuffle to fill the gap (due to removed 2nd subnet).

In the example below I set the script property of the DHCPv6 Client to a meaningless expression to trigger reassignment:

> :put [/ipv6/pool/print detail where name=global]
Flags: D - dynamic 
0 D id=98 name="global" prefix=2001:db8:0:6540::/60 prefix-length=64 expires-after=1h32m 
 
> /ipv6/address
> add from-pool=global interface=vlan-iot eui-64=yes
> add from-pool=global interface=vlan-work eui-64=yes
> add from-pool=global interface=vlan-tv eui-64=yes
> print detail where from-pool=global
12  G address=2001:db8:0:6542:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-iot actual-interface=vlan-iot eui-64=yes advertise=yes no-dad=no 
13  G address=2001:db8:0:6543:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-work actual-interface=vlan-work eui-64=yes advertise=yes no-dad=no 
14  G address=2001:db8:0:6544:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-tv actual-interface=vlan-tv eui-64=yes advertise=yes no-dad=no
> remove 13
> print detail from-pool=global
12  G address=2001:db8:0:6542:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-iot actual-interface=vlan-iot eui-64=yes advertise=yes no-dad=no 
13  G address=2001:db8:0:6544:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-tv actual-interface=vlan-tv eui-64=yes advertise=yes no-dad=no 
> /ipv6/dhcp-client/set numbers=0 script=":put hello"
> print detail from-pool=global
12  G address=2001:db8:0:6542:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-iot actual-interface=vlan-iot eui-64=yes advertise=yes no-dad=no 
13  G address=2001:db8:0:6543:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-tv actual-interface=vlan-tv eui-64=yes advertise=yes no-dad=no

Note how subnet ID changed from 2 and 4 to 2 and 3.

With respect to the VLAN filtering, are you talking about the loopback interface? I don't have that switch to verify, but there are posts on this forum that suggest that a port-less loopback interface does not interfere with the offloading. Ability to have a loopback interface is crucial e.g. when you use a link-local backbone network. If this indeed the case that this bridge interface breaks offloading, Mikrotik appears to suggest to have an EoIP tunnel instead.

mkx · Sat Jul 29, 2023 7:57 am

When setting ipv6 address (from pool), one can set N*16 least significant bits of address where 128-N*16 has to be equal to or more than size of prefix in pool. In case of @nravnen: pool prefix size is 48, meaning that it's possible to set up to 5x16 bits. If one sets less (@nravnen example shows 4x16 bits), the ROS chooses the missing bits in some pseudo-random fashion (number of bits chosen by ROS of course depends on prefix size used in address, which should most of time be 64). The problem for most users is that ISPs tend to hand out prefixes larger than 48 bits (e.g. 56 or 60), but ROS insists on Nx16 bits grouping (I was complaining about it years ago, arguing that this is a bug, but MT replied that fine-grain handling of prefix+suffix handling would be feature request).

So in case of @nravnen, it should be possible to set IPv6 address like this:

/ipv6 address
add address=::1:4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1
add address=::3996:4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3996
add address=::3994:4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3994
add address=::3993:4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3993
add address=::3992:4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3992

Which would take much of freedom away from ROS.

Kentzo · Sat Jul 29, 2023 8:02 am

@mkx Have you been able to make it work? I could not specify bits within prefix length. Following my example above:

> /ipv6/address
> add address=0:0:0:000e::1 interface=vlan-iot advertise=no from-pool=global 
> print detail where from-pool=global
12 IG ;;; address pool error: bad preferred prefix! (1)
      address=::e:0:0:0:1/64 from-pool=global interface=vlan-iot actual-interface=vlan-iot eui-64=no advertise=no no-dad=no

Do I misinterpret your idea? It's very late here

mkx · Sat Jul 29, 2023 8:07 am

Address has to start with:: as ROS will only replace leading zeroes with bits from prefix.

So:
prefix: aaaa:bbbb:cccc::/48
address: ::xxxx:yyyy:wwww:zzzz:tttt/64

gives final address of:aaaa:bbbb:cccc:xxxx:yyyy:wwww:zzzz:tttt/64

and address: ::1/64 gives final address aaaa:bbbb:cccc:RRRR:0:0:0:1/64 where RRRR is pseudo randomly set by ROS.

Kentzo · Sat Jul 29, 2023 8:16 am

Address has to start with:: as ROS will only replace leading zeroes with bits from prefix.

My example appears to satisfy this condition. That RouterOS properly interpreted can be seen in the output. However, it found presence of bits set within pool's prefix-length problematic.

address: ::xxxx:yyyy:wwww:zzzz:tttt/64

You appear to suggest that one may influence target prefix length via the address property, but that's not true. It will be ignored and pool's prefix length will be taken instead.

and address: ::1/64 gives final address aaaa:bbbb:cccc:RRRR:0:0:0:1/64 where RRRR is pseudo randomly set by ROS.

And that's the problem because the user has no influence over the RRRR subnet ID. Moreover, RouterOS can change it.

DarkNate · Sat Jul 29, 2023 9:45 am

You're both (or all?) configuring it wrong.

ISP gives me /48 STATIC PD.
DHCPv6 clients injects static /48 into the pool.

I manually configure the /64, by ensuring I manually specify the router's IP on each of the VLANs.

So it's like this:
/ipv6/address
add from-pool=global address=::1/64 interface=vlan-iot eui-64=no advertise=yes
add from-pool=global address=:0:1::1/64 interface=vlan-work eui-64=no advertise=yes
add from-pool=global address=:0:2::1/64 interface=vlan-tv eui-64=no advertise=yes

Now the ::x/64 assigned to any VLAN, will NEVER change even if you reboot the router, as long as the DHCPv6-client receives the same PD from the ISP, forever. Why tf do you need scripting/hacks for such basic functionality that RouterOS v6/v7 already supports?

MikroTik will autopopulate the network prefix/site prefix segment of the address, whereas subnet ID X will remain static. Since IPv6 subnetting is hierarchical, the ::1, 2 etc will never change.

We identify the VLAN based on the subnet ID X.

I'm using this method from last 6 years and rebooted my MikroTik at least 9000 times, never changed.

biomesh · Sat Jul 29, 2023 2:33 pm

My comment was for dynamic allocations from an ISP. @DarkNate I can see that your config will work for a static allocation, but not for a dynamic one. I am using Comcast, so not a small ISP by any means.

Znevna · Sat Jul 29, 2023 2:50 pm

Was this ever fixed? viewtopic.php?p=888620#p888620
Regarding this topic, we have an old topic about pretty much the same issue viewtopic.php?t=153437
Considering the age of this "missing feature", we should see it in about 7 years implemented (some stuff takes less than 10 years though).
It's so easy done in OpenWrt for example: viewtopic.php?p=966400#p966400

Emil66 · Sat Jul 29, 2023 3:30 pm

add from-pool=global address=::1/64 interface=vlan-iot eui-64=no advertise=yes
add from-pool=global address=::2/64 interface=vlan-work eui-64=no advertise=yes
add from-pool=global address=::3/64 interface=vlan-tv eui-64=no advertise=yes

If RouterOS did at all what you claim, that would produce a bad configuration, because all addresses you set on different interfaces would end up in the same subnet. You set the interface identifier (the last 64 bits) to 1, 2 and 3 respectively. But the the bits in the place of the subnet id are 0 for all three, so combined with the /48 prefix id, you'd get the same subnet on all three interfaces, if RouterOS actually took the subnet id from that address specification. In reality, it won't even let you set those bits in that address to anything but 0. The subnet id is chosen by RouterOS and not guaranteed to stay the same. Just disable an interface and reenable it: new subnet. The problem is exactly like the top comment describes it. What happens for you is that RouterOS chooses the subnet ids in the same way every time since the interfaces never change on your system. So it appears as if RouterOS remembers the subnet ids, but it actually doesn't. It's just "luck" that they always end up the same due to your rather static network setup.

DarkNate · Sat Jul 29, 2023 3:50 pm

If RouterOS did at all what you claim, that would produce a bad configuration

Ah that's typo lol, I edited the comment.

DarkNate · Sat Jul 29, 2023 3:51 pm

My comment was for dynamic allocations from an ISP. @DarkNate I can see that your config will work for a static allocation, but not for a dynamic one. I am using Comcast, so not a small ISP by any means.

What are you asking lol, if the PD is dynamic, then it will always change. How's this a RouterOS problem? Ask Comcast to read this:
https://www.ripe.net/publications/docs/ ... persistent

Znevna · Sat Jul 29, 2023 4:00 pm

You fail to understand the problem described in these topics.

Emil66 · Sat Jul 29, 2023 4:18 pm

Ah that's typo lol, I edited the comment.

add from-pool=global address=::1/64 interface=vlan-iot eui-64=no advertise=yes
add from-pool=global address=:0:1::1/64 interface=vlan-work eui-64=no advertise=yes
add from-pool=global address=:0:2::1/64 interface=vlan-tv eui-64=no advertise=yes

That's worse.

What are you asking lol, if the PD is dynamic, then it will always change. How's this a RouterOS problem?

The delegated prefix usually doesn't change, so the addresses could stay the same if RouterOS allowed one to set the subnet id. You claim it does, but it clearly does not, as anyone can try for themselves. The fundamental problem with this deficiency is that the firewall is ill-equipped to deal with the potentially changing subnet id.

Kentzo · Sat Jul 29, 2023 4:33 pm

@DarkNate,

gggg:gggg:gggg:ssss:iiii:iiii:iiii:iiii

Interface ID (:iiii:iiii:iiii:iiii) which is the tail 64 bits, won’t change and will remain as you specified via the address property.

But subnet ID (:ssss:) which is the middle 4-16 bits between global ID (gggg:gggg:gggg: delegated prefix by the ISP) and interface ID (:iiii:iiii:iiii:iiii what you set via address=) will.

Recognize, that between global ID (gggg:gggg:gggg:) and interface ID (:iiii:iiii:iiii:iiii) there is subnet ID (:ssss:) which is picked, maintained and shuffled by RouterOS. Shuffling does not appear to be random, but it is annoying nevertheless.

mkx · Sat Jul 29, 2023 8:18 pm

Address has to start with:: as ROS will only replace leading zeroes with bits from prefix.
My example appears to satisfy this condition.

No, it doesn't:

/ipv6/address
> add address=0:0:0:000e::1 interface=vlan-iot advertise=no from-pool=global

So it doesn't start with double colon ... instead double colon is in the middle.

While address written in such assignment does look like IPv6 address (and one might expect parser to treat it as such), the parser does some magic combining it with prefix (from pool) and it doesn't seem to be very inteligent at it.
So your example should be written as this: ::e:0:0:0:1 (as usually, only one sequence of 0's can be replaced by :: and in this kind of assignment it has to be most dignificant part of address because that's the part which is replaced by prefix). And if prefix in pool is not /48 (or shorter), parser will end up with invalid address.

Kentzo · Sat Jul 29, 2023 8:27 pm

While address written in such assignment does look like IPv6 address (and one might expect parser to treat it as such), the parser does some magic combining it with prefix (from pool) and it doesn't seem to be very inteligent at it.

Perhaps it was like this previously, but at least since 7.9.2 it doesn't seem to be this way:

> :put (0:0:0:000e::1 = ::e:0:0:0:1)
true
> :put [:typeof 0:0:0:000e::1]
ip6

I get the same error if I write it as you suggested:

> add address=::e:0:0:0:1 interface=vlan-iot advertise=no from-pool=global 
> print detail
12 IG ;;; address pool error: bad preferred prefix! (1)
      address=::e:0:0:0:1/64 from-pool=global interface=vlan-iot actual-interface=vlan-iot eui-64=no advertise=no no-dad=no

RouterOS refused to carry the bits I set (e) into pool's prefix length (64 from delegated 60, see my example above). The net result is that subnet ID is not settable.

I'm not sure what you wanted to show here.

mkx · Sat Jul 29, 2023 8:31 pm

address: ::xxxx:yyyy:wwww:zzzz:tttt/64
You appear to suggest that one may influence target prefix length via the address property, but that's not true. It will be ignored and pool's prefix length will be taken instead.

I'm not saying that I could affect prefix length, I'm saying I could affect the RRRR part of address.
When I did experimenting a few years ago and on v6 (whichever version was the latest at the time), it did work the way I explained. And I experimented with lots of prefixes (lab tests, so I wasn't depending on what ISP was giving out).

The outcome was: if pool had prefix with length of /48 and was set to use /64 prefixes, then I could set 5x16 bits on address and it would result with valid IPv6 address on interface. If pool prefix was longer (e.g. /56), then I could only set 4x16 bits on address and ROS would pseudo-randomly pick the rest of bits (8 bits when prefix was /56 or 4 bits when prefix was /60). The only way I could affect those bits was if I set address manually (without using prefix mechanizm). Again: resulting address was a /64 address and properly advertised through ND as such.

biomesh · Sat Jul 29, 2023 8:48 pm

My comment was for dynamic allocations from an ISP. @DarkNate I can see that your config will work for a static allocation, but not for a dynamic one. I am using Comcast, so not a small ISP by any means.
What are you asking lol, if the PD is dynamic, then it will always change. How's this a RouterOS problem? Ask Comcast to read this:
https://www.ripe.net/publications/docs/ ... persistent

They do not always change. My prefix allocations are pretty constant.

I am not talking about address assignment but prefix assignment from an ipv6 pool.

I get a /60 so the last digit of the /60 will always be 0-F. I am looking for a way (with my current setup) to have my ipv6 dhcp servers assign a /64 with the same last digit no matter what the /60 is. The same functionality should also be in the address assignment.

I am sure I could script this, but looking for a way to allow for some level of persistence.

Kentzo · Sat Jul 29, 2023 8:58 pm

The outcome was: if pool had prefix with length of /48 and was set to use /64 prefixes, then I could set 5x16 bits on address and it would result with valid IPv6 address on interface

Doesn't seem to work anymore:

> /ipv6/pool/add name=test prefix=2001:db8::/48 prefix-length=64
> /ipv6/address/add address=::e:0:0:0:1 interface=vlan-iot advertise=no from-pool=test
> print detail where from-pool=test
;;; address pool error: bad preferred prefix! (1)
Flags: X - disabled, I - invalid, D - dynamic; G - global, L - link-local 
12 IG ;;; address pool error: bad preferred prefix! (1)
      address=::e:0:0:0:1/64 from-pool=test interface=vlan-iot actual-interface=vlan-iot eui-64=no advertise=no no-dad=no

mkx · Sat Jul 29, 2023 9:49 pm

That's too bad.

Kentzo · Sat Jul 29, 2023 9:56 pm

With respect to writing address:

> /ipv6/address
> add address=0:0:0:0:1:: from-pool=test interface=vlan-iot
> add address=::2:0:0:0 from-pool=test interface=vlan-iot
> /print detail
12  G address=2001:db8:0:0:1::/64 from-pool=test interface=vlan-iot actual-interface=vlan-iot eui-64=no advertise=yes no-dad=no 
13  G address=2001:db8:0:1:2::/64 from-pool=test interface=vlan-iot actual-interface=vlan-iot eui-64=no advertise=yes no-dad=no

As you can see, the parser properly recognized both variants.

mkx · Sat Jul 29, 2023 10:14 pm

Your experinents show that parser now works differently than it worked in v6. Is it better or not is yet to be seen.

Kentzo · Sat Jul 29, 2023 10:29 pm

Your experinents show that parser now works differently than it worked in v6. Is it better or not is yet to be seen.

It does not appear to me as a parser issue though. In fact current behavior of RouterOS seems logical: pool's address-prefix and prefix-length of allocations specified under /ipv6/pool covers Global ID and Subnet ID parts of the IPv6 address, while /ipv6/address covers the Interface ID part. It seems to be designed this way because the same pool can be used by both /ipv6/address and /ipv6/dhcp-server and they wanted to keep the implementation simple.

What I'd want is to remove prefix-length from /ipv6/pool and instead allow both /ipv6/address and /ipv6/dhcp-server to control it alongside Subnet ID. Although that'd require sophisticated conflict tracking.

magchiel · Sat Aug 26, 2023 3:11 am

What I'd want is to remove prefix-length from /ipv6/pool and instead allow both /ipv6/address and /ipv6/dhcp-server to control it alongside Subnet ID. Although that'd require sophisticated conflict tracking.

Exactly. The

i+1

type of increment in the subnet everytime you assign an address, to me seems more like a temporary placeholder in the code, pending a full implementation. Shouldn't implementing DAD be sufficient for the conflict tracking resolution between whatever is assigned by /ipv6/address and /ipv6/dhcp-server?

IPv6 Prefix ID per IPv6 enabled interface

IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Re: IPv6 Prefix ID per IPv6 enabled interface

Who is online