linux-ppp.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicholas Humfrey <njh@aelius.com>
To: linux-ppp@vger.kernel.org
Subject: Re: Configuring pppd to accept link-local IPv6 interface id from remote peer
Date: Tue, 16 Feb 2021 00:10:54 +0000	[thread overview]
Message-ID: <c0eb49d2-c33e-1ffc-db2d-1dd2e5e0a1ff@aelius.com> (raw)
In-Reply-To: <d529e496-ac5f-9498-0e3d-1fa1ec2c4750@aelius.com>


On 14/02/2021 16:23, James Carlson wrote:
> On 2021-02-13 20:03, Nicholas Humfrey wrote:
>> Hi,
>>
>> I originally asked this question on the "Unix and Linux" StackExchange:
>> https://unix.stackexchange.com/questions/634033/configuring-pppd-to-accept-link-local-ipv6-address-from-remote-peer
> 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:

https://gist.github.com/njh/ab3282f43c72dcf6932b3693eb7dfca4


>> 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:
>>    ipv6cp-accept-local
>>      With this option, pppd will accept the peer's idea of our local IPv6
>> interface
>>      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.


nick.


  parent reply	other threads:[~2021-02-16  0:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-14  1:03 Nicholas Humfrey
2021-02-14  1:57 ` Michael Richardson
2021-02-14 13:42 ` Nicholas Humfrey
2021-02-14 16:23 ` James Carlson
2021-02-14 17:07 ` Kurt Van Dijck
2021-02-14 17:50 ` James Carlson
2021-02-14 21:24 ` Benjamin Cama
2021-02-14 22:46 ` James Carlson
2021-02-14 23:15 ` Benjamin Cama
2021-02-16  0:10 ` Nicholas Humfrey [this message]
2021-02-16 10:04 ` Benjamin Cama
2021-02-18  0:18 ` Nicholas Humfrey
2021-02-20  1:13 ` Nicholas Humfrey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c0eb49d2-c33e-1ffc-db2d-1dd2e5e0a1ff@aelius.com \
    --to=njh@aelius.com \
    --cc=linux-ppp@vger.kernel.org \
    --subject='Re: Configuring pppd to accept link-local IPv6 interface id from remote peer' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).