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.
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.
Statistics: Posted by mkx — Mon Mar 18, 2024 11:38 pm