Steve Hill <st...@opendium.com> writes: > On 15/06/2021 18:19, Bjørn Mork wrote: > >> Yes, that is buggy. I wonder... I did hit a similar issue many many >> years ago while testing IPv6 over PPPoE (which we didn't end up doing in >> the end). > > I'm not entirely sure how the default route is assigned - on ethernet > it would be assigned on receipt of the router advertisement, but is > that still the case with PPP, or is the default route negotiated by > IPv6CP?
The only defined options are Interface-Identifier and IPv6-Compression-Protocol, ref https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-28 The interface-id is required to form a valid link-local address since there is no EUI-48 or EUI-64 Address and routing is otherwise identical to any other Ipv6 interface. I.e. SLAAC, DHCPv6, and/or static. >> Maybe you are hitting something similar with your ISP? The typical >> symptom would be that DHCPv6 worked once again after the lease expires. >> If this is the issue, then you can probably assign a static interface-id >> on your end to work around it. > > I've got 2 internet connections on the same ISP. > > One of them was set up years ago and the ISP was trialling IPv6 at the > time, so I requested an IPv6 prefix. This one is working ok (the > DHCPv6 advertise contains my prefix). I have no idea whether the ISP > ever rolled out IPv6 to everyone by default, but this works for me > since I enrolled on the trial years ago. > > The other connection is new. The ISP sends router advertisements and > we get a default route, but the DHCPv6 advertise doesn't contain a > prefix or IP. I think it's a reasonable assumption that the ISP never > enabled IPv6 for everyone by default and the result is that when you > send a DHCPv6 solicit you don't get a prefix on this connection. Yes, that sounds likely. They shouldn't be sending RAs either then. But clients blindly trying IPv6 over PPP is probably not a common problem. I believe most clients disable IPV6CP by default. >> I think it would be too risky to try to be smart here. >> How can the system know whthere there will be an address available >> later? Should it cache all the routing? What if the system has an >> address which isn't routable on the interface with the default route? >> Etc. >> Installing the routes you receive is the only sane thing to do, >> IMHO. > > But it results in a configuration that causes real-world brokenness > (long timeouts waiting for connections that can never happen). Whether you want to trust an RA or not is a local policy decision. Forcing a new default policy is sure to break existing configurations. If the default route from a specific router or interface doesn't work for you, then ignore it. > The correct thing would probably be for the kernel to treat all global > addresses as unroutable if the machine only has link-local addresses, > irrespective of the existence of a default route. Is there a reason > why you would ever want to generate traffic with a link-local source > address and a global destination address? You can reach any directly connected system by their global address using a link-local source. There is no way to know that a global address is more than one hop away without trying. Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
