* Dan Williams
> I'm slowly working on getting all the IPv6 pieces together and had a
> question about PPP & IPv6 that you might know. I'm using the
> Icera-based Nokia 21M that you sent me long ago, and (due to some
> ModemManager bugs) it's using plain PPP.
Hi Dan, I'm glad to hear that! :-)
> 1) What should the prefix be for the IPV6CP assigned address? pppd
> hardcodes it as '10' which seems entirely bogus to me:
>
> memset(&ifr6, 0, sizeof(ifr6));
> IN6_LLADDR_FROM_EUI64(ifr6.ifr6_addr, our_eui64);
> ifr6.ifr6_ifindex = ifr.ifr_ifindex;
> ifr6.ifr6_prefixlen = 10;
>
> if (ioctl(sock6_fd, SIOCSIFADDR, &ifr6) < 0) {
>
> Should it be 64? Should it 128?
Hmm. Good question. The standards aren't very explicit. RFC 4862 section
5.3 talks about "appropriate" prefix lengths, implying it's not
necessarily /64, while I would on the other hand interpret RFC 4291
section 2.5.6 as saying it should be /64 - based on the understanding
that the prefix bits is everything that is not the Interface ID bits
(the latter of which is clearly defined to be 64).
In the end I don't think it makes any practical difference. So if pppd
configures a /10 I wouldn't bother with adding code to replace it, if I
were you. If instead you'll add that address from within NM, I think I'd
use /64 over /10.
> 2) Should anything bother to set the peer address on the PPP interface?
> For example, I get:
>
> local LL address fe80::0000:0024:5c9b:0001
> remote LL address fe80::9d89:1690:be7b:438d
>
> with IPv4 we would do "ip addr add <local>/32 peer <remote> dev ppp0",
> should that same pattern be followed with IPv6?
I don't think so. That "local" LL address come with an implied on-link
route to fe80::/64 (which is already sufficient to reach the "remote"
address, so there's not much need for the "peer" in the first place).
ip-address(8) says «If a peer address is specified, the local address
cannot have a prefix length. The network prefix is associated with the
peer rather than with the local address».
If I do "ip address add fe80::1/64 peer fe80::2 dev ppp0" I do *not* get
a on-link prefix route to fe80::/64 The command was accepted, but the
"/64" part was apparently ignored. I'm pretty sure this end result is
not how it's supposed to be (but it'll probably work regardless).
> 3) Running RA on the PPP interface gives me yet another gateway:
>
> NetworkManager[21653]: --------- NMIP6Config 0x18d6db0 (WWAN-RA)
> NetworkManager[21653]: gw: fe80::24:5c9b:40
> NetworkManager[21653]: mss: 0
> NetworkManager[21653]: n-dflt: 0
>
> What should be done with that, if anything? Should that replace the
> peer address on ppp0? Or should we just use it to set the default
> route, but leave the peer address the same?
Doesn't really matter, do whatever is simplest to implement. The
next-hop has no meaning on PPP interfaces, as there is no link-layer
addresses, and thus no need for link-layer address resolution (like IPv4
ARP and IPv6 ND), and that's the only reason for specifying a next-hop
in the first place. In other words:
default dev ppp0
default dev ppp0 via fe80::24:5c9b:40
default dev ppp0 via fe80::<nonexistent>
All of the above will do exactly the same thing. So, *shrug*, whatever...
Tore
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
