ipv6 routing config for ISP DHCP delegated prefix

RouterOS General
1

I have just moved to a new service - the old setup was vDSL using PPPoE, now I have fibre but they use DHCP.
So I get the IPv6/DHCP-client prefix as usual, so far so good
I set up an IPv6 address for the bridge using a ::/64, also no problem, can ping this from the internal network
But cannot ping it from WAN anywhere.
Also cannot ping an external IPv6 address from either the router or the LAN

IPv4 works fine after I set up the correct gateway.
IPv6 should just work via its link local fe80::xx:xx:xx:xx address that appears in the dynamically created routing table entry.

BUT not working.
running ROS 7.12 on an RB4011

/ipv6 address
add address=::1 from-pool=pool_snap interface=bridge
/ipv6 dhcp-client
add add-default-route=yes interface=SNAP-10 pool-name=pool_snap request=prefix use-peer-dns=no
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=33434-33534 protocol=udp
add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=input comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="drop DNS from WAN" connection-state=new dst-port=53 in-interface-list=WAN protocol=tcp
add action=drop chain=forward comment="drop DNS from WAN" connection-state=new dst-port=53 in-interface-list=WAN protocol=udp
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=icmpv6
add action=jump chain=forward dst-address=2406:xxxx:xxxx:xxxx::123/128 jump-target=http-s
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=forward comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN log-prefix=fwdDrop
add action=accept chain=http-s dst-port=22 protocol=tcp
add action=accept chain=http-s dst-port=80 protocol=tcp
add action=accept chain=http-s dst-port=443 protocol=tcp
/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=SNAP-10 passthrough=yes protocol=tcp tcp-flags=syn
/ipv6 nd
set [ find default=yes ] disabled=yes
add hop-limit=64 interface=bridge other-configuration=yes ra-interval=3s-1m
/ipv6 route
add disabled=no distance=1 dst-address=::/0 gateway=SNAP-10 routing-table=main scope=30 suppress-hw-offload=no target-scope=10 vrf-interface=SNAP-10
add disabled=no distance=1 dst-address=2000::/3 gateway=SNAP-10 routing-table=main scope=30 suppress-hw-offload=no target-scope=10 vrf-interface=SNAP-10
/ipv6 settings
set accept-router-advertisements=yes

Any suggestions appreciated

2

See this:
http://forum.mikrotik.com/t/ipv6-nd-64-and-pd-48-problems/174041/1

3

Thanks for the link, I had already seen this and I think tried the various ND setups - no difference.
I am getting almost zero help from my ISP.
It appears that my router isn’t forwarding correctly to the WAN, from either itself or from LAN
How do I test this - pings don’t work, what else?
I have tried torch on the ISP.10 interface and block IP4 so only IPv6 should show. However I don’t see much, and what I do see seems to have source and destination reversed?? Very little experience with this.
When I look at IPv6 Connections tab I see TCP attempts but only Syn sent messages appear and then it times out.
Either my packets are not actually getting to the ISP or the return packet isn’t getting to firewall - how do I find out which it is?
latest export attached
I have now spent two weeks trying to solve this, so frustrating - the ISP PPPoE connection on their VDSL service works a charm, change to a DHCP supplied prefix delegation and the default routes set up by RouterOS and it fails!
TIA for any help in debugging this.

4

OOps here is config
RB4011_clean.rsc (14.2 KB)

5

SOLVED - well kinda
Reading through many posts and forums I found someone who said that as part of their DHCP-Client setup, that they also asked for an address (as well as prefix)
So I tried it and got given an address outside my ::/56 and it was assigned to my ISP.10 interface
The routing table naturally gained an entry DAC 2406: … ::1/128 with gateway of ISP.10
But now my IPv6 is working
Would love someone to explain why this solved my issue, and why isn’t this in any posted solutions on the MT forum.
I have yet to determine if this is a random address or permanent, and is there a way to achieve this outcome by manually assigning an address to the ISP.10 interface.
Wasted a week of life and hours on hold with my ISP to stumble upon it.
Hope this helps others

6

A bit of guessing here: if ISP assigns a prefix to CPE device, it somehow needs to know also where to route packets belonging to that prefix. In principle DHCPv6 server and ISP router are independent devices, hence ISP’s router doesn’t know where to route traffic. But it seems that most ISP solutions include feeding information from DHCPv6 server towards router. IPv6 specifies use of ULAs (Unique Local Address, based on MAC address) and these can be used for routing. And without further information, DHCPv6 server does know ULA of device asking for a prefix and it can pass this ULA (together with delegated prefix) to router.
Non-typical case is what you see: some ISP implementations seemingly insist on using GUAs (Global Unicast Address) for routing and in this case one indeed has to configure DHCPv6 client to request both prefix and address. Note that basic use of this GUA is for routing (of the delegated prefix) and any other use is actually an “abuse”. Also it has to be requested in same DHCPv6 handshake together with request for prefix in order to maintain routing table (on ISP router). Assigned GUA can change with time but this shouldn’t be a problem (if one doesn’t abuse it).

For completeness sake: the paragraph above (hopefully) describes how correct routing is established on ISP side. But for successfull bi-directional traffic flows, upstream routing on CPE has to be set up as well. Since DHCPv6 doesn’t include routing information, IPv6 specifies RAs (Routing Advertisements) with which routers announce their presence, their prefix (with length) and networks, accessible through them. This way CPE can learn upstream router’s IPv6 address (most often it’s ULA, in rare cases it’s GUA). And most often it’s different than DHCPv6 server’s IPv6 address. In case when upstream link is a point-to-point type of link (e.g. PPPoE), RAs are not strictly necessary to find out upstream routers, simply using interface works fine. As mentioned elsewhere, MT implements a hack (add-default-route property of DHCPv6 client), but use of this hack should be avoided if possible.

One can indeed ask questions about Mikrotik’s IPv6 defaults (MT was pretty late to come up with decent IPv6 implementation and is still far from being great), but as seen in numerous threads of this forum not every ISP does stuff the same way, hence it’s hard to prepare robust config defaults and/or documentation.

7

Thanks @mkx
That actually made lots of sense to me, and I think explains why the PPPoE I had in my last house from the same ISP worked just fine, but now in the new house where they use DHCPv6 it failed.
I fully believe that this ISP cuts corners where it can, hence the implementation they have chosen.
It would still be a real asset to the MT documentation for this to be explained and variations of router setup demonstrated.
The amount of time and frustration trying to get this going was disproportionate to what was trying to be done - get IPv6 working on a router that was already set up with dual stack IP.
Once again, appreciate your insight and explanation.
Regards
Rob