Re: Configuring pppd to accept link-local IPv6 interface id from remote peer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 14/02/2021 16:23, James Carlson wrote:
On 2021-02-13 20:03, Nicholas Humfrey wrote:

I originally asked this question on the "Unix and Linux" StackExchange:
Do you have a debug trace?  I don't see one in that posting or here, so
it's hard to know exactly what we're commenting on.

Debug trace is in a Gist, linked to in the StackExchange question. I have just updated the Gist to include both the 'client', 'server' and the pppd options file:

I have two pppd (v2.4.7) instances running, talking to each over over a
serial port link. But I can't work out how to get the 'client' pppd to
accept the link-local IPv6 interface identifier provided by the 'server'
pppd. I am trying to use static addresses so I know the link-local IP
address of the remote peer.
Perhaps a silly question, but why?  Link locals are used only for the
IPv6 router discovery, neighbor discovery, and routing protocol
communication.  Why would anyone care what numbers are assigned as long
as the two ends are distinct?

A very reasonable question! I am partly doing this as a learning exercise. But I think it is also useful for debugging and diagnostics. If they can be any two unique identifiers (to that link), it seems useful to be able to make them more easily human readable.

The PPP protocol describes a number of different ways to assign interface identifiers and pppd supports a number of them. Why does the functionality exist (even if a bit broken)?

The pppd man page says:
     With this option, pppd will accept the peer's idea of our local IPv6
     identifier, even if the local IPv6 interface identifier was
specified in an option.
This means that we'll accept the peer's IPV6CP Configure-Nak message
suggesting a different address rather than sticking to our guns.  It
doesn't mean we won't start out with a legitimate identifier.

So I guess it is only useable when using a PPP implementation other than Linux pppd?

As there is no way to configure the 'server' to Nack the clients chosen identifier?

I have now managed to get it working by hacking ipv6cp.c to keep the
local identifier as all-zero, by disabling a couple of calls to
eui64_magic_nz. But I am not sure what the proper solution is.

Does there need to be an IPv6 equivalent to 'noipdefault' to use in
conjunction with 'ipv6cp-accept-local'?
Yes, I agree there could probably be an option ("noipv6default",
perhaps) to do this, if only for testing reasons.  But given the lack of
a compelling application for it, it's hard to see why.

I like the idea of it being explicit - and not change the existing/expected behaviour of the existing 'ipv6' option.


[Index of Archives]     [Linux Audio Users]     [Linux for Hams]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Fedora Users]

  Powered by Linux