Addendum: Now the set default gateway command is there but not available in winbox, only in command line mode…
@nsayer: What ROS version are you using? /ipv6 route print looks different in 5.19…
[admin@MikroTik] /ipv6 route> /ipv6 route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
# DST-ADDRESS GATEWAY DISTANCE
0 A S ::/0 RDS-PPPoE 1
...
5 ADC 2a02:2f02:1022:f0cb::/64 ether1 0
[admin@MikroTik] /ipv6 route>
Here rule 0 is the default route and i do not get any dynamic route to the provider, only to ether1 which is my internal network the prefix pool is delegated to.
You have an interface called ether1-gateway which is your ISP connection.
Another one called bridge1 as your internal interface.
If this is correct, your route number 3 is wrong!
If 2601:9:4980:52::/64 is your delegated prefix, than there must be only 1 route to that prefix, via bridge1.
There are no addresses 2601:9:4980:52::/64 via ether1-gateway route, all are delegated to you and must be IPs of bridge1 or via bridge1.
add-default-route actually adds a route for the prefix received via dhcpv6-pd, not a default route. I can reproduce this and it looks like you can too.
/ipv6 address attribute from-pool does not seem to be effective.
I was able to get home IPv6 up and running, albeit in a hacky configuration, by:
disabling add-default-route, but manually adding a default route pointing to v6 LL address of the CMTS
manually addressing my internal interface with the prefix handed out by dhcpv6-pd
Can anyone else reproduce this behavior? If so, we should confirm as a bug and submit to mikrotik support.
I agree that route 3 is wrong. It is, however, what showed up when I turned “add-default-route” on in the dhcpv6 client.
If 2601:9:4980:52::/64 is your delegated prefix, than there must be only 1 route to that prefix, via bridge1.
There are no addresses 2601:9:4980:52::/64 via ether1-gateway route, all are delegated to you and must be IPs of bridge1 or via bridge1.
Do you use a pool for prefix delegation?
Yes. That’s what results in the creation of route #2.
AFAIK you also need to enable RA in IPV6/ND (Neighbour discovery) and enable advertisement of MAC and DNS (if you need it - mikrotik’s dns server supports IPv6 resolution) on your internal interface.
I’m currently testing the PPPoE Server with RouterOS 5.19 and giving out /64 IPv6 prefixes to PPPoE Clients. This works fine with RouterOS Clients (in my case I’m manually configuring one IPv6 address out of the prefix on the PPPoE Clients LAN side). If I have a non-RouterOS client as many customers do (for example a D-Link DIR-600 or Linksys E900) which support IPv6, than I’m running into some troubles
On both tested routers (D-Link DIR-600 and Linksys E900) they see the prefix on the WAN port if I’m giving it out via the PPPoE Secret (Remote IPv6 prefix). On the D-Link I can configure the LAN IPv6 address but it still doesn’t work as the Router believes that the prefix is on the WAN (PPPoE out so to speak) interface.
If I’m using the RouterOS DHCP PD feature as explained in the Wiki it works like a charme with both Routers (the D-Link and the Linksys), BUT:
How can I be sure that a certain IPv6 PPPoE client always receives the same prefix?? DUID would help, but with the standard DHCP PD the client could change the end device and receive a different prefix. I could make some frewall rules which drop all not “officially” configured prefixes, but this would be some additional work as there is no automatic “add to address list” feature like with IPv4 PPPoE addresses. I also don’t wanna configure a single profile for every single secret with a single pool for every single user G
Are there currently any BCPs for MikroTik+PPPoE+static IPv4 address+static IPv6 prefix??
Hi,
Why do you need one of the IP6 assigned to the PPoE LAN side?
As long as you don’t need router access on that interface/IP combination it has no use.
All IPv6 enabled interfaces have a LL address assigned automatically for data transport purposes, and only forwarding has to be done for “inside” addresses.
IPv4 needed that interface address mainly for NAT purposes which is not available in IPv6.
On the other hand, RA is intended to assign addresses to one single broadcast domain (speak 1 LAN) and uses a single /64 prefix and assigns individual addresses to interfaces (in fact the addresses are locally generated, and the RA server has no exact idea how, it just advertizes the prefix, the router and optionally the DNS). It is not intended for PD nor is it capable to do such thing.
So, to do PD on a subsequent router, you have to assign a address range to it (at least /64), using e.g. DHCP, or by hand, so it can create a pool from which to delegate individual addresses (not prefix ranges) to its LAN.
Well, that’s what I actually meant.
I want to assign one /64 prefix to the customer’s/end user’s LAN. The customer’s/end user’s WAN port just has a LL (PPPoE) address. The only problem is that I don’t know how to do that with a MikroTik (RouterOS) as PPPoE Server as long as the client isn’t RouterOS, too (what can be the case of course). Well, in fact I know how it could work (Wiki’s DHCP PD over PPP), but I want the customer/end user to have the same prefix all the time, what can’t be guranteed with this solution afaik. The sweetest solution would be the “Remote IPv6 prefix” option in the PPP secrets. That works great with RouterOS clients, but not with others (D-Link and Linksys at least). So I’m wondering if this feature is not 100% conform to some standards or how it can be implemented to be compatible with other vendor’s end devices.
Why don’t you simply assign static IPs/64 from your pool? Do you really want/need an DHCP server?
And regarding the DHCP server… There is something called “bindings” which i think is ment to do exactly this: assign a ip/prefix to an DUID.
This DUID afaik is an unique machine identifier of the client. How exactly it is formed i don’t know.
Never played with it so some digging is needed.
