Steve Hill <st...@opendium.com> writes: > On 15/06/2021 15:56, Bjørn Mork wrote: > >>> Is my ISP behaving in a broken way, by not assigning me an address in >>> response to IA_NA, or is it standard behaviour for ISPs to only >>> respond to IA_PD requests? >> There is no standard behaviour. Both ways are fine. There usually >> isn't much need for the IA_NA address. > > Well, some more related brokenness just discovered while diagnosing > some network problems on a different internet connection: > > - PPP link comes up and assigns IPv4 through LCP.
NCP actualy. This is IPCP. There is also IPV6CP, which you should pay some attention to here. > - I send an IPv6 router solicitation to my ISP. > - ISP responds with a router advertisement, which has the "managed > address configuration" and "other configuration" flags set. > - I send DHCPv6 Solicit with IA_NA and IA_PD options. > - ISP responds with a DHCPv6 Advertise, which contains neither an IPv6 > address nor prefix. > > The ISP supports IPv6 but I'm guessing they haven't provisioned this > connection for it - the router solicitation is working but DHCPv6 > isn't giving out an address or prefix. 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). We allocate one static prefix per line/user and use RADIUS to provision it to the BNG which also serves as a DHCPv6 server. This means that only one DHCPv6 client per line will get a prefix. If there is more than one, then there is no pool or anything for the remaining. The assumption is that there is one single CPE connected and that's it. Now, with PPP you obviously have dynamic interfaces. So for this to work, the DHCPv6 server has to match it's lease table against some static user identifier. We assumed that would be the PPP username. But it turned out the BNG used a combination of username and interface-id. So new sessions from the same user with a differet interface-id would not get a prefix. This is where IPV6CP is important. The interface-id is pretty much the only thing it negotiates. It would negotiate a new one for every session, so DHCPv6 worked only the first time. Until the lease timed out and it worked again - once. I was only configuring this a limited test, so I didn't bother thinking too much about it. I just assigned static interface-ids to the handful users, configured in RADIUS. This forced IPV6CP to always negotiate the same id for the same user. 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. FWIW, the BNG I experienced the problem with was a Juniper ERX (probably E320) which is in the historical bin by now. But I wouldn't be surprised if the issue lives on in the Juniper MXes. Don't think I've ever tested. We ended up mostly dropping PPP. > The result is that the machine has a default route but no public IPv6 > address, which is similar to my first example. When you try to make > an IPv6 connection out to the internet, instead of it just outright > failing as it would without a suitable route, it tries to use the PPP > interface's link local address as the source. This means that trying > to connect to a dual-stack host is very very slow since you have to > wait for the v6 connection to time out before it falls back to v4. > > I can't see a good reason for installing a default route when DHCP > hasn't allocated an address or prefix - doing so just leaves the > machine with a broken network setup. 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. Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
