Steve Hill via networkmanager-list <networkmanager-list@gnome.org> writes: > On 16/06/2021 10:12, Beniamino Galvani wrote: > >> You are right, RFC 3633 forbids it. However, if I understand correctly >> this approach is the one mentioned in [1], which refers to an expired >> IETF draft [2] saying: > > RFC 3633 has been obsoleted by RFC 8415, and this MUST NOT does not > appear to be mentioned in 8415.
Yes, looks like that was dropped. Probably because it was violated all the time and this works well in practice :-) Still doesn't make much sense IMHO. As seen from the delegating router: Why delegate a prefix for the other end of the link when you can just assign it directly to your end? > RFC 8415 references RFC 7084, which says (Emphasis mine): > > WAA-7: If the IPv6 CE router does not acquire a global IPv6 > address(es) from either SLAAC or DHCPv6, then it MUST create > a global IPv6 address(es) from its delegated prefix(es) and > configure those on one of its internal virtual network > interfaces, ***unless configured to require a global IPv6 > address on the WAN interface***. > > I think this sort of implies that generating a global IPv6 address for > the WAN interface from the delegated prefixes is ok? I believe the intended meaning of the emphasized text is that the CE address configuraion should fail in this case. > Its not terribly clear, but in any case the MUST NOT wording seems to > have gone away. It feels sensible to me to optionally auto-generate a > /128 address for the WAN interface from the delegations if it doesn't > have an address assigned from elsewhere. Yes, in practice you'd often do this to force a specific source address selection for that outgoing interface. But this is another local policy decision which should not be made default. Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
