On Thu, 2014-04-10 at 22:51 +0200, Tore Anderson wrote:
> * 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...
I eventually got it working for PPP and DHCP/SLAAC, using the
dcbw/icera-ipv6 (ModemManager) and dcbw/wwan-ipv6 (NetworkManager)
branches.
NM will replace the IPv6 address set by pppd with the correct /64
address. It will then start RA on the interface and end up with the
global IPv6 address. Obviously as we've found before you'll need to
hardcode the DNS servers since firmware doesn't proxy those into the
RAs.
For net ports, NM will set the ModemManager-provided LL address (if
available) on the net port, and then proceed to run SLAAC on it. I
haven't gotten around to testing static IPv6 configurations yet.
Dan
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
