Gert Doering <[email protected]> writes:
> There has been quite a bit of discussion in the ISP camp regarding WAN
> IPv6 addresses. It's not actually straightforward what to do as an ISP,
> so multiple variants exist
>
> - RA for WAN, DHCPv6-PD for LAN
> disadvantage: on PPPoE-type deployments, you need two prefixes per
> client, one /64 for the WAN-RA, one /56 for DHCP
> (but this works quite nicely in cable deployments where you have a
> "large shared WAN segment" anyway)
You may get away with a shared /64 for all PPPoE links terminated on the
same BNG, since you effectively control all the interface identifiers
through IPV6CP.
> - DHCPv6-IA for WAN, DHCPv6-PD for LAN
> disadvantage: extra pool management for WAN needed, basically similar
> to RA for WAN
Note that this scheme has a great advantage (for the ISP) when compared
to RA, especially if the link is shared: The ISP selects the address
when using DHCPv6-NA. This way it can be recorded and used for e.g. CPE
management purposes.
Also note that the RA is still required for (default) routing. But it
doesn't need to announce any prefix.
> - "require use of an IPv6 address out of the delegated /56 for WAN"
> disadvantage: this sort of forces a certain way to segment the /56 onto
> the client, so I have not actually seen this in the wild
Not to mention that this is explicitly forbidden by RFC 3633:
12.1. Requesting router behavior
..
the requesting router MUST
NOT assign any delegated prefixes or subnets from the delegated
prefix(es) to the link through which it received the DHCP message
from the delegating router.
> - run the WAN over link-local only
> advantage: only single prefix per customer, easier management for the ISP
> (in point-to-point deployment scenarios, like PPPoE)
> disadvantage: well, it complicates source address selection on the
> CPE, as locally sourced packets leaving via WAN need to use a global
> address elsewhere - you named it, already.
From an end user perspective, this source address selection can actually
be seen as an advantage. I want to use addresses from my delegated
prefix for all traffic, including CPE locally sourced traffic. The only
way to achieve that, if you want to follow RFC 3633 (see above), is by
*not* assigning any global address to the WAN link.
Note that even if you ignore the RFC 3633 restriction and add a /128
from your delegated prefix to thw WAN link, you cannot guarantee that it
will be used for every destination if there are other global addresses
on the WAN interface. DHCPv6-NA assigned addresses will also be /128
and you end up with rule 8 - longest match against destination wins.
Which is going to be pretty arbitrary if both addresses come out of the
same ISP block...
So I prefer the link local only WAN interface. That way I can add a
/128 from my delegated prefix on the loopback interface and make the CPE
use it for locally source globally scoped traffic.
Those who claim that applications should always explictly bind to their
wanted source address do have a point, though. Source address selection
is otherwise going to be pretty confusing. At least for me :-)
Bjørn
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
