I've sent this info the Daisy and have just had a reply:

"Going off the below you’re UDM Pro device doesn’t seem to be allowing IPv6 traffic to traverse from it’s LAN downlink to WAN uplink. This is where you’re issue, or at least part of you issue seems to be stemming from.

As stated this is unfortunately not a managed device and you will need to progress this with Ubiquity directly."

In reply to a post by jpm:

I need you to ping an address in the /56 that isn't also in the /64 configured on your UDMP - we know that traffic is getting to your UDMP. My suspicion is that when you ping to an address beyond the UDMP you won't see those packets arriving, which diagnoses a routing issue with the Daisy-managed Cisco router.

jpm why do you think the OP is unable to ping6 out to the internet from a machine connected behind the UDM? Yet if he tries directly with the laptop into the back of the Cisco it works? Unless I’ve got it completely wrong (not the first or last time) - smack of a routing issue on the UDM no?

Also from what’s written I don’t think there is any /56 routed by Daisy it’s simply a /64. That goes back to what we are told in post #3

In reply to a post by jpm:

There might be some awful IPv6 equivalent of proxy ARP

That would be a "Neighbour Discovery Proxy" (ND Proxy) but as you've pointed out you shouldn't need that if everything is routed correctly.

I'm doing one step at a time - we need to verify the Cisco router configuration is correct before trying to get the UDMP working. From what Daisy have provided as the config lines and how the service is working it appears that it's configured wrong.

I can't see how this is going to work without routing the /56 to the UDMP but Daisy don't seem too interested as long as a device directly connected to their router has IPv6 connectivity.

Yes I understand your logic. My suspicion is that there are indeed multiple issues at play here:

1. There is a either a misunderstanding, miscommunication or misconfiguration (or a little of all of them!) of the /56 (or as it seems only a /64) subnet routing of the service from Daisy

2. There is a routing issue present on the UDM Pro which is not allowing outbound routing of IPv6 from LAN to WAN

3. Daisy are insisting that all issue are related solely related to item (2) and are under the control of the OP. They are refusing to budge and the OP has neither the experience or knowledge (no offence OP) to adequately back up his position.

Whilst I understand that /56 routing needs to be investigated and/or altered by Daisy I don’t get the feeling that they will budge until they have ‘evidence’ that the UDM Pro configuration is in the clear so to speak. Hence why I’m asking why for equivalence purposes the OP can route out - so that at least they can say to Daisy “hey look I can connect out via laptop and can also connect out via my router, but there is a problem with my /56 allocation routing.

In reply to a post by JESC77:

I've sent this info the Daisy and have just had a reply:

"Going off the below you’re UDM Pro device doesn’t seem to be allowing IPv6 traffic to traverse from it’s LAN downlink to WAN uplink. This is where you’re issue, or at least part of you issue seems to be stemming from.

They are confusing traffic direction. with the UDMP configured as before (WAN IP ...:2300::2/64 gw ...:2300::1/64, LAN IP ...:2301::1/64) get a traffic dump whist trying to ping 2a00:1450:4009:81e::2003 (google.co.uk) - it should show packets leaving the UDMP WAN port for the Cisco.

I've found this in a Cisco manual:

ipv6 route ipv6-prefix/prefix length {ipv6-address | interface-id [ipv6-address]} [administrative distance]

ipv6-address—The IPv6 address of the next hop that can be used to reach the specified network. The IPv6 address of the next hop need not be directly connected; recursion is done to find the IPv6 address of the directly connected next hop. The address must be in the form documented in RFC 2373, specified in hexadecimal using 16-bit values between colons.

interface-id—Specifies direct static routes from point-to-point and broadcast interfaces. With point-to-point interfaces, there is no need to specify the IPv6 address of the next hop. With broadcast interfaces, you should always specify the IPv6 address of the next hop, or ensure that the specified prefix is assigned to the link, specifying a link-local address as the next hop. You can optionally specify the IPv6 address of the next hop to which packets are sent.

I've emboldened the key part - with a broadcast interface such as a physical ethernet port or VLAN the prefix including the prefix length must be assigned to the interface OR you have to specify the next hop address.

So, with Cisco terminology italicised, instead of the directly attached static route which will never work, and if they don't like recursive static routes for whatever reasons they should use a fully specified static route e.g. ipv6 route 2001:xxx:xxx:2310::/60 Vlan100 2001:xxx:xxx:2300::2 to route 16 of the subnets to the UDMP (to route all would likely be ipv6 route 2001:xxx:xxx:2300::/56 Vlan100 2001:xxx:xxx:2300::2 but I don't know how Cisco cope with overlapping network ranges).

Wireshark capture of UDMP WAN interface, ping from my laptop 2001:b98:xxx:2301::4fb to 2a00:1450:4009:81e::2003.

66 0.151460 2001:b98:xxx:2301::4fb 2a00:1450:4009:81e::2003 ICMPv6 70 Echo (ping) request id=0xed8b, seq=100, hop limit=63 (no response found!)
67 0.162784 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:4fb ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::4fb from c4:f7:d5:20:ac:f4
435 1.153909 2001:b98:xxx:2301::4fb 2a00:1450:4009:81e::2003 ICMPv6 70 Echo (ping) request id=0xed8b, seq=101, hop limit=63 (no response found!)
445 1.186887 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:4fb ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::4fb from c4:f7:d5:20:ac:f4
792 2.159113 2001:b98:xxx:2301::4fb 2a00:1450:4009:81e::2003 ICMPv6 70 Echo (ping) request id=0xed8b, seq=102, hop limit=63 (no response found!)
804 2.211257 fe80::c6f7:d5ff:fe20:acf4 ff02::1:ff00:4fb ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2301::4fb from c4:f7:d5:20:ac:f4
1137 3.162289 2001:b98:xxx:2301::4fb 2a00:1450:4009:81e::2003 ICMPv6 70 Echo (ping) request id=0xed8b, seq=103, hop limit=63 (no response found!)
1163 3.240378 fe80::f692:bfff:fe78:b3d 2001:b98:xxx:2300::1 ICMPv6 86 Neighbor Solicitation for 2001:b98:xxx:2300::1 from f4:92:bf:78:0b:3d
1164 3.242451 2001:b98:xxx:2300::1 fe80::f692:bfff:fe78:b3d ICMPv6 78 Neighbor Advertisement 2001:b98:xxx:2300::1 (rtr, sol)

So it looks like my ping is hitting the cisco but is going no further?

To me it looks like it's going out but the reply can't get back to you as the Cisco router is looking for that IPv6 address on an interface where it doesn't exist.

In reply to a post by jpm:

To me it looks like it's going out but the reply can't get back to you as the Cisco router is looking for that IPv6 address on an interface where it doesn't exist.

But I can ping the UDM from outside.

In reply to a post by JESC77:

I've had had extensive support from Ubiquiti and Daisy, Ubiquiti say that my ISP must support prefix delegation and Daisy are unable to provide it.

https://help.ui.com/hc/en-us/articles/115005868927-U...
I find it hard to believe that the UDMP has this limitation when the help article above says:

"Depending on the configuration of the ISP, the UDM/USG can either use DHCPv6-PD (Prefix Delegation) or Static IPv6 addresses to provide IPv6 connectivity to the clients on the LAN. In both setups, the information regarding the connection type and its values is provided by the ISP."

Has anyone managed to get this to work?

I do have an Edgerouter 12P and a Mikotik Hex S I can use but are no expert at setting those up.

Thanks for any help!

Just circling back to your opening post here, and highlighting what you were told above by Ubiquiti. This is rather concerning that they insist you must use PD. There are other reports online (though admittedly now about 6 months old, perhaps fixed in most recent firmware...??) that complain about the 'flakiness' of parts of the IPv6 implementation in the UDM Pro's. Like this blog post.

From some other articles I've now read, most folks that have gotten IPv6 working with a UDMP have done so using Prefix Delegation, not using static routing as you must do with Daisy.

Therefore there may be some merit in attempting to get IPv6 working using the second port on the Cisco to another of the routers that you have available above. I believe Daisy have said they mapped your IPv6 allocation to use both of the Cisco user ports?

In this way you should be able to keep the rest of your existing network running on the first Cisco port via your UDM and create a test IPv6 network using the second Cisco port and test using either the EdgeRouter or the MikroTik.

Edit:
Links to further articles complaining about broken IPv6 routing on the UDM Pro. Where there's smoke and all that...

https://www.reddit.com/r/UNIFI/comments/hbf49z/love_...

https://www.sysadmins.lv/blog-en/ubiquiti-udm-pro-an...

Edited by Pheasant (Sat 31-Jul-21 14:09:08)