Does anyone have an example of using DHCPv6 with a HE.net tunnel?

As of 5.13, RouterOS doesn't have a fully working DHCPv6 server. It can only be used as DHCPv6-PD I think.

You are right. Any time frame on full DHCPv6? ND does not hand out DNS so Windows PC still require manual configuration without full DHCPv6.

Probably RouterOS version 6. I hope it comes before World IPv6 Launch though.

I want this to

You are right. Any time frame on full DHCPv6? ND does not hand out DNS so Windows PC still require manual configuration without full DHCPv6.

ND does hand out DNS. Windows simly does not support this feature.

You are right. Any time frame on full DHCPv6? ND does not hand out DNS so Windows PC still require manual configuration without full DHCPv6.

ND does hand out DNS. Windows simly does not support this feature.

Any news on when a Full DHCP IPv6 server will be implemented mrz?

It is in our TODO list and will be ready when it is done.

>>ND does hand out DNS. Windows simly does not support this feature.

Any guess when Windows will support DNS info over ND? World IPv6 Day is coming and I think not supporting it is a short coming.

Ask Bill Gates )

It is in our TODO list and will be ready when it is done.

This year or next?

The DHCPv6 server also has the following problems:

- routes to delegated prefixes are added to routing table with the "Dynamic Static" flags - I'd prefer to have the "Dynamic Connected" flags set (and Static unset) as the entry is not static and can disappear when the client releases the prefix. This would help with redistribution via OSPFv3.

- when the DHCPv6 pool prefix and interface prefix overlap, the DHCPv6 server should NOT hand out the prefix assigned to any interface in the system. E.g.: I have 2a01:8c00:ff44:/64 assigned to my testing bridge (and WAN iface of the client) and 2a01:8c00:ff44:/56 prefix set for DHCPv6 pool (with the length of prefixes handed out set to 64). DHCPv6 server with no worries hands out the 2a01:8c00:ff44:/64 prefix to my client, which does not work, as the client cannot have the same prefix on both WAN and LAN interfaces.

In case pool Prefix length is longer than /64 (/63, /62, ...), the client actually selects the next /64 prefix for LAN interface, which makes this configuration work - I'd prefer to have the overlapping /64 and "/PrefixLength" not handed out to clients.

And yes, RADIUS is a must

Problem is redistribute-anything Static or Connected doesn't matter.

- routes to delegated prefixes are added to routing table with the "Dynamic Static" flags - I'd prefer to have the "Dynamic Connected" flags set (and Static unset) as the entry is not static and can disappear when the client releases the prefix. This would help with redistribution via OSPFv3.

- when the DHCPv6 pool prefix and interface prefix overlap, the DHCPv6 server should NOT hand out the prefix assigned to any interface in the system. E.g.: I have 2a01:8c00:ff44:/64 assigned to my testing bridge (and WAN iface of the client) and 2a01:8c00:ff44:/56 prefix set for DHCPv6 pool (with the length of prefixes handed out set to 64). DHCPv6 server with no worries hands out the 2a01:8c00:ff44:/64 prefix to my client, which does not work, as the client cannot have the same prefix on both WAN and LAN interfaces.

It's a configuration problem not DHCP server's problem. If you don't want prefix to be distributed then do not include it in the pool.

Hi,

I expect the Mikrotik staff includes how do the process of migration from IPv4 tp IPv6 with Mikrotik and CPEs for the next launch.

- routes to delegated prefixes are added to routing table with the "Dynamic Static" flags - I'd prefer to have the "Dynamic Connected" flags set

...but it's not a connected route by definition because the router itself doesn't have an address presence within that prefix. So you can't use that flag.

True, "DS" seems like an oxymoron on the surface, but I've always just tried to think of the "S" as a catch-all category for any prefix that is not a connected route and that the router did not learn via a dynamic routing protocol (OSPF, BGP, etc.). Basically, a "DS" route is just like an "S" route except it was generated by the system instead of by a user.

Changing the flags for IPv6 routes would make things inconsistent within RouterOS. "DS" is also the designation given to IPv4 routes added dynamically by the system (e.g., RADIUS Framed-Route), and I think you'd generally want to treat the redistribution of IPv4 "DS" routes the same as plain "S" routes within OSPF or BGP (I'm hard-pressed to think of an example where you wouldn't want to do this, actually). So it's not like there wasn't precedent for this behavior already set elsewhere in the OS.

-- Nathan

You are right. Any time frame on full DHCPv6? ND does not hand out DNS so Windows PC still require manual configuration without full DHCPv6.

ND does hand out DNS. Windows simly does not support this feature.

Slightly off-topic, but since the subject came up...I have a humble request for ND-based DNS configuration (or "RDNSS-via-RA" as I'm used to calling it).

Right now, if you turn it on ("/ipv6 nd set [find] advertise-dns=yes"), it finds IPv6 addresses for DNS servers from "/ip dns" and advertises those in the RA. I want to have a different place where I can configure which IPv6 address to advertise as a DNS server. Ultimately what I want to do is turn on "/ip dns allow-remote-requests=yes" and then have the router advertise one of its own IPv6 addresses in the RA, so that the router itself is acting as the cacheing DNS server for the v6 prefixes it is advertising.

I can't do this right now because having "/ip dns set servers=" refer to itself obviously doesn't work very well.

-- Nathan