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

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

[Nicholas Humfrey]

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

But i suspect it is a bit too niche and have not had a response there.


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.

On the 'server' I am running:
   pppd file ./ppp-options ipv6 ::1,::2 /dev/ttyAMA0 115200

And on the 'client', I am running:
   pppd file ./ppp-options ipv6cp-accept-local /dev/ttyAMA0 115200

This is the contents of ppp-options on both:
   nodetach
   noauth
   persist
   local
   noip
   +ipv6

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.

But that doesn't seem to be the behaviour I am experiencing.

The client always just uses a locally chosen interface identifier 
instead. It was suggested to me to try setting the 'client' local 
interface identifier to all-zero but I have not found a way of doing 
this through configuration. Or alternatively get the 'server' to Nack 
the clients choice of interface identifier - but I'm not sure how to 
achieve that with pppd.

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'?

Thanks,

nick.

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

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]


Nicholas Humfrey <njh@aelius.com> wrote:
    > 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.

So, basically you want to have ppp running with unnumbered links, and then
maybe you do routing over that?

I am not surprised that this hasn't been tested, and that there are bugs.
Mostly, IP6CP assigns random IPv6-LL.

If your goal is routing over unnumbered links, you don't really need the
destination IPv6-LL to route to, it's enough to "dev ppp0" or whatever.

If you just want a stable identifier at each end, then put it on lo a /128
alias, and put a route to it.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Nicholas Humfrey]

On 14/02/2021 01:57, Michael Richardson wrote
> Nicholas Humfrey <njh@aelius.com> wrote:
>      > 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.
>
> So, basically you want to have ppp running with unnumbered links, and then
> maybe you do routing over that?
>
> I am not surprised that this hasn't been tested, and that there are bugs.
> Mostly, IP6CP assigns random IPv6-LL.

I guess it does surprise me that there are bugs! I had been assuming 
that I was doing something wrong but the more I look at it, the more it 
looks like a bug.


> If your goal is routing over unnumbered links, you don't really need the
> destination IPv6-LL to route to, it's enough to "dev ppp0" or whatever.

Yeah, that is perfectly fair. I did get static global IPv6 addresses and 
routing working, so the actual link-local address I guess isn't that 
important.

Just a bit frustrating not being able to achieve something that seems 
like it should be possible.


Thanks!

nick.

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

[James Carlson]

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.

> 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?

Applications aren't normally supposed to use link-locals at all.
They're quite hard to use correctly.  They're *LINK LOCAL*, so all uses
-- connect, bind, sendto -- is required to use interface identifier
binding (sin6_scope_id) as well.  The whole area is quite a mess and
best avoided unless you really, really need to do it.

The normal thing to do is to wait for ICMPv6 RA to assign local prefixes
(and thus autoconf global addresses) or use DHCPv6 if you need
finer-grained control or even an /etc/ppp/ipv6-up script to assign IPv6
global addresses as needed.

IPv6 is different from IPv4.  It's not quite the same thing at all.  In
particular, the idea of "static IP address assignment" changes quite a bit.

The sole reason I could see to do this would be to assert some control
over autoconf addresses, which sometimes use the identifier as the
default "interface token."  But there are probably better ways to do that.

> 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.

RFC 2472 is a little weird with respect to the Interface-Identifier
option.  It's possible to send an all-zero identifier, but we're really
in uncharted waters if the peer can't give us an address or rejects the
option.  This sort of makes sense given that IPv6 itself just doesn't
work at all (no ICMPv6 ND means no work gets done) without a local
address, so it's not something anyone has really explored.

> The client always just uses a locally chosen interface identifier
> instead. It was suggested to me to try setting the 'client' local
> interface identifier to all-zero but I have not found a way of doing
> this through configuration. Or alternatively get the 'server' to Nack
> the clients choice of interface identifier - but I'm not sure how to
> achieve that with pppd.

Note: RFC 2472 *REQUIRES* an implementation to accept whatever the peer
proposes as long as it doesn't conflict with the locally-chosen identifier.

     If the two Interface-Identifiers are different and the received
     Interface-Identifier is not zero, the Interface-Identifier MUST be
     acknowledged, i.e.  a Configure-Ack is sent with the requested
     Interface-Identifier, meaning that the responding peer agrees with
     the Interface-Identifier requested.

That's part of the weirdness.  We're not really allowed (by the
specification) to say "your identifier is legal [non-zero and
non-duplicate] but I don't like it so let me give you a different one."

> 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.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

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

[Kurt Van Dijck]

On 14 February 2021 02:03:28 GMT+01:00, Nicholas Humfrey <njh@aelius.com> wrote:
>Hi,
>pppd. I am trying to use static addresses so I know the link-local IP 
>address of the remote peer.
>
>On the 'server' I am running:
>   pppd file ./ppp-options ipv6 ::1,::2 /dev/ttyAMA0 115200

::1 is not a link-local ip.
::1 is 'localhost', i would advise not to use it elsewhere
Sent from a small mobile device

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

[James Carlson]

On 2021-02-14 12:07, Kurt Van Dijck wrote:
> 
> 
> On 14 February 2021 02:03:28 GMT+01:00, Nicholas Humfrey <njh@aelius.com> wrote:
>> Hi,
>> pppd. I am trying to use static addresses so I know the link-local IP 
>> address of the remote peer.
>>
>> On the 'server' I am running:
>>   pppd file ./ppp-options ipv6 ::1,::2 /dev/ttyAMA0 115200
> 
> ::1 is not a link-local ip.
> ::1 is 'localhost', i would advise not to use it elsewhere
> Sent from a small mobile device
> 

That's not quite true.  The "ipv6" option takes IPV6CP "interface
identifiers," which are (essentially) the lower 64 bits of an IPv6 address.

The user interface uses IPv6 address parsing, so they look like actual
addresses, but the upper 64 bits must all be zero, and they're not
actually used as addresses anywhere.

So, "::1" means "IPV6CP Interface-Identifier 0000000000000001".

Unlike IPCP (IPv4), there is absolutely no way to negotiate IPv6
addresses with PPP.  That's just not how IPv6 works.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

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

[Benjamin Cama]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

Hello James, Nicholas & others,

Please allow me to join the conversation:

Le dimanche 14 février 2021 à 11:23 -0500, James Carlson a écrit :
> RFC 2472 is a little weird with respect to the Interface-Identifier
> option.  It's possible to send an all-zero identifier, but we're really
> in uncharted waters if the peer can't give us an address or rejects the
> option.

Could I suggest that then IPv6CP just fails?

> This sort of makes sense given that IPv6 itself just doesn't
> work at all (no ICMPv6 ND means no work gets done) without a local
> address, so it's not something anyone has really explored.

Well, I actually sent last year a patch (attached again to this
message) to Paul and Cc'ed here about sending a zero identifier to do
exactly (to my understanding) what Nicholas is intending to do: let the
“server”-side choose the interface identifier.

It is a very small change that is basically activated on the “client”-
side with:

  ipv6 ::,

thus sending a zero identifier for our side. It worked quite well for
my work case (virtual serial links), where having short addresses when
autoconfiguring helps a lot, too. I couldn't resist also citing the
“stability to global scope addresses” argument from the RFC, which is
indeed relevant to me, at least.

What do you think about it?
Regards,
--
Benjamin

[-- Attachment #2: 0001-pppd-Allow-for-a-zero-interface-identifier-in-ConfRe.patch --]
[-- Type: text/x-patch, Size: 1618 bytes --]

From 59ee72be9b6dba56b5422c0bec88842d61c9c56f Mon Sep 17 00:00:00 2001
From: Benjamin Cama <benoar@dolka.fr>
Date: Wed, 17 Jun 2020 14:30:01 +0200
Subject: [PATCH] pppd: Allow for a zero interface identifier in ConfReq

RFC 5072 allows a peer to send a zero interface identifier in an IPv6CP
Configure-Request, signifying it wants the other side to choose one for
it. Allow this by passing "::" to the classic "ipv6" option.
---
Quoting section 4.1 of RFC 5072 <https://tools.ietf.org/html/rfc5072#section-4.1>:

  If neither a unique number nor a random number can be generated, it is
  recommended that a zero value be used for the interface identifier
  transmitted in the Configure-Request. In this case, the PPP peer may
  provide a valid non-zero interface identifier in its response as
  described below.

It can be useful to have non-random identifiers, to help having short
and stable ids, furthermote assigned from one place only. It helps
providing “stability to global scope addresses”, as put by the RFC
authors.

 pppd/ipv6cp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/pppd/ipv6cp.c b/pppd/ipv6cp.c
index bda91e9..1e4fd2b 100644
--- a/pppd/ipv6cp.c
+++ b/pppd/ipv6cp.c
@@ -346,8 +346,7 @@ setifaceid(argv)
     struct in6_addr addr;
     static int prio_local, prio_remote;
 
-#define VALIDID(a) ( (((a).s6_addr32[0] == 0) && ((a).s6_addr32[1] == 0)) && \
-			(((a).s6_addr32[2] != 0) || ((a).s6_addr32[3] != 0)) )
+#define VALIDID(a) ( ((a).s6_addr32[0] == 0) && ((a).s6_addr32[1] == 0) )
     
     arg = *argv;
     if ((comma = strchr(arg, ',')) == NULL)
-- 
2.26.0

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

[James Carlson]

On 2021-02-14 16:24, Benjamin Cama wrote:
> Le dimanche 14 février 2021 à 11:23 -0500, James Carlson a écrit :
>> RFC 2472 is a little weird with respect to the Interface-Identifier
>> option.  It's possible to send an all-zero identifier, but we're really
>> in uncharted waters if the peer can't give us an address or rejects the
>> option.
> 
> Could I suggest that then IPv6CP just fails?

The RFC says that it's out of scope.  Sure; I think failure would be fine.

> Well, I actually sent last year a patch (attached again to this
> message) to Paul and Cc'ed here about sending a zero identifier to do
> exactly (to my understanding) what Nicholas is intending to do: let the
> “server”-side choose the interface identifier.
> 
> It is a very small change that is basically activated on the “client”-
> side with:
> 
>   ipv6 ::,
> 
> thus sending a zero identifier for our side. It worked quite well for
> my work case (virtual serial links), where having short addresses when
> autoconfiguring helps a lot, too. I couldn't resist also citing the
> “stability to global scope addresses” argument from the RFC, which is
> indeed relevant to me, at least.

I assume that's a reference to autoconf behavior.  It's actually not
required that autoconf uses the same lower 64 bits to form those
addresses, though it it often does.  And even where it does, it's
certainly possible to use other mechanisms to do the "right thing."  In
Linux I believe you can set the client portion for stateless autoconf
with something like:

  ip token set ::123/64 dev ppp0

I'd do that in an ipv6-up script.

But, yeah, that's the only possible reason I can see to care about it,
and it seems like a pretty weak one to me.  (Usually you'll want more
than just a static address, and DHCPv6 gives you DNS and other really
handy bits as well.)

> What do you think about it?

That's a much more elegant configuration option than my suggestion.  I
like it.

(I don't like the idea that people seem to care about IPv6 link-local
addresses.  Not at all.  But I like the change, especially if it means
the question doesn't need to be answered again.)

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

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

[Benjamin Cama]

Le dimanche 14 février 2021 à 17:46 -0500, James Carlson a écrit :
> On 2021-02-14 16:24, Benjamin Cama wrote:
> > Well, I actually sent last year a patch (attached again to this
> > message) to Paul and Cc'ed here about sending a zero identifier to do
> > exactly (to my understanding) what Nicholas is intending to do: let the
> > “server”-side choose the interface identifier.
> > 
> > It is a very small change that is basically activated on the “client”-
> > side with:
> > 
> >   ipv6 ::,
> > 
> > thus sending a zero identifier for our side. It worked quite well for
> > my work case (virtual serial links), where having short addresses when
> > autoconfiguring helps a lot, too. I couldn't resist also citing the
> > “stability to global scope addresses” argument from the RFC, which is
> > indeed relevant to me, at least.
> 
> I assume that's a reference to autoconf behavior.  It's actually not
> required that autoconf uses the same lower 64 bits to form those
> addresses, though it it often does.

Well, it was the default for a very long time, and is still used for
“permanent addresses” that are still always configured anyway.

> And even where it does, it's
> certainly possible to use other mechanisms to do the "right thing."  In
> Linux I believe you can set the client portion for stateless autoconf
> with something like:
> 
>   ip token set ::123/64 dev ppp0
> 
> I'd do that in an ipv6-up script.

Well, I was not aware of the tokenized interface identifier support in
iproute2, even if this was kind of envisioned in the RFC (although the
manual here only cites a draft as formal reference…). Thanks for
letting me know!

> But, yeah, that's the only possible reason I can see to care about it,
> and it seems like a pretty weak one to me.  (Usually you'll want more
> than just a static address, and DHCPv6 gives you DNS and other really
> handy bits as well.)

I agree this is not the most useful feature I witnessed. To be more
precise on my use-case, this is about knowing in advance, from the
server-side, what will the client address be *when they are not
provisionned* for a particular id, but just use autoconf for the prefix
*and the iid part*, if one could call this mechanism “iid
autoconfiguration”. In this case, I also get resolvers through RA, and
even client registration in the DNS —if this was what you thought
about— can be then done on the server-side, as iid and thus global
address is deterministic (*if acknowledged* at IPv6CP level, which is a
small caveat I did not take into account, I admit; thus my suggestion
above about failing, then: maybe this would need a patch for that,
too?).

> > What do you think about it?
> 
> That's a much more elegant configuration option than my suggestion.  I
> like it.

To be fair, I did not check *all the cases* where the state machine
could stumble on zero iid. I *think* this is ok as zero is check here
and there, but I would prefer someone most knowledgeable double-check
it.

> (I don't like the idea that people seem to care about IPv6 link-local
> addresses.  Not at all.  But I like the change, especially if it means
> the question doesn't need to be answered again.)

Well, people are afraid of it when they see beginners misuse it (which
is very often the case). But stable global addressing and non-globally
addressed link with stable link-local addresses (e.g. inter-router
links, etc) can be very useful too for advanced use.

Thanks for your comments.
--
Benjamin

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

[Nicholas Humfrey]

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.

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

[Benjamin Cama]

Hi Nicholas,

[Cc'ing the list if I may, as it may be useful]

Le mardi 16 février 2021 à 00:56 +0000, Nicholas Humfrey a écrit :
>  > It is a very small change that is basically activated on the “client”-
>  > side with:
>  >
>  >   ipv6 ::,
>  >
>  > thus sending a zero identifier for our side.
> 
> 
> I just tried applying your patch to Git master (5191399) and 
> successfully compiled it.

Thanks for testing!

> However when running this on my 'client':
> ./pppd/pppd file ~/ppp-options ipv6 ::, ipv6cp-accept-local /dev/ttyAMA0 
> 115200
> 
> Then it seemed to fail to negotiate the link-local address. Here is the 
> output:
> https://gist.github.com/njh/437713988b108880a8fe23ed10168c0c

It seems it keeps sending ConfReq for the zero identifier… strange.
Here is the output with the patched version from last june when I wrote
it, latest git at the time (some time after 2.4.8), which works:

   using channel 19
   Using interface ppp0
   Connect: ppp0 <--> /dev/pts/18
   rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xfc846b9d> <pcomp> <accomp>]
   sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x29314916> <pcomp> <accomp>]
   sent [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xfc846b9d> <pcomp> <accomp>]
   rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x29314916> <pcomp> <accomp>]
   sent [LCP EchoReq id=0x0 magic=0x29314916]
   sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
   sent [IPV6CP ConfReq id=0x1 <addr fe80::0000:0000:0000:0000>]
   rcvd [LCP EchoReq id=0x0 magic=0xfc846b9d]
   sent [LCP EchoRep id=0x0 magic=0x29314916]
   rcvd [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
   sent [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
   rcvd [IPV6CP ConfReq id=0x1 <addr fe80::0000:0000:0000:0001>]
   sent [IPV6CP ConfAck id=0x1 <addr fe80::0000:0000:0000:0001>]
   rcvd [LCP EchoRep id=0x0 magic=0xfc846b9d]
   rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
   Deflate (15) compression enabled
   rcvd [IPV6CP ConfNak id=0x1 <addr fe80::0000:0000:0000:0002>]
   sent [IPV6CP ConfReq id=0x2 <addr fe80::0000:0000:0000:0002>]
   rcvd [IPV6CP ConfAck id=0x2 <addr fe80::0000:0000:0000:0002>]
   local  LL address fe80::0000:0000:0000:0002
   remote LL address fe80::0000:0000:0000:0001
   Script /etc/ppp/ipv6-up started (pid 11628)
   Script /etc/ppp/ipv6-up finished (pid 11628), status = 0x0
   ^CTerminating on signal 2
   Script /etc/ppp/ipv6-down started (pid 11655)
   sent [LCP TermReq id=0x2 "User request"]
   Script /etc/ppp/ipv6-down finished (pid 11655), status = 0x0
   Child process sudo /home/benoar/Dev/ppp/pppd/pppd notty noauth noip +ipv6 ipv6 ::1,::2 (pid 11617) terminated with signal 2
   Modem hangup
   Connection terminated.
   Connect time 0.1 minutes.
   Sent 120 bytes, received 120 bytes.

   It correctly gets nacked when sending zero iid, and then acks the given
   identifier. BTW, I use a quick “self-test” for development testing:

   sudo ./pppd/pppd pty "sudo $(pwd)/pppd/pppd notty noauth noip +ipv6 ipv6 ::1,::2" noauth nodetach noip +ipv6 ipv6 ::, debug

   But with latest git and my patch, I indeed get the same trace as you.

   > In my hack, rather than changing the definition of what a valid 
> Interface Identifier is, I instead looked for the calls to eui64_magic() 
> and commented them out.

The VALIDID macro was sparsely used and fitted my use-case well, so I
went with that.

> Looking at the git master branch, it looks like Pali Rohár is actively 
> working in this space:
> 
> https://github.com/paulusmack/ppp/commits/master

Well, I'll give a look to find what's wrong.

Thanks for your feedback!
Regards,
--
benjamin

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

[Nicholas Humfrey]

On 16/02/2021 10:04, Benjamin Cama wrote:
> Hi Nicholas,
>
> [Cc'ing the list if I may, as it may be useful]

Whoops. I had meant to CC the list.


> It seems it keeps sending ConfReq for the zero identifier… strange.
> Here is the output with the patched version from last june when I wrote
> it, latest git at the time (some time after 2.4.8), which works

Hm! I will try testing against an older version in git...


Now that I know that it isn't just that I haven't found the right 
option, I decided to raise a Github issue here:

https://github.com/paulusmack/ppp/issues/256


nick.

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

[Nicholas Humfrey]

>> Looking at the git master branch, it looks like Pali Rohár is actively
>> working in this space:
>>
>> https://github.com/paulusmack/ppp/commits/master
> Well, I'll give a look to find what's wrong.


Just a quick follow up to say that it is all working fine after I 
upgraded to version 2.4.9 of pppd.

I had initially been using version 2.4.7, that came with Raspberry Pi OS 
(buster).
I had also been testing using git master of the ppp repo on the 'client'.

But I hadn't tried upgrading the 'server' (the peer configured with the 
interface identifiers).
After upgrading to 2.4.9 on the 'server' it works perfectly - even with 
an older version of pppd on the 'client'.
I haven't tracked down the commit that fixed it but I guess it was 
something to do with failing to Nack the random interface identifier 
sent by the peer.

Thank you for your help and thoughts on the issue.


nick.


|pppd file ./ppp-options ipv6cp-accept-local /dev/ttyAMA0 115200 using 
channel 368 Using interface ppp0 Connect: ppp0 <--> /dev/ttyAMA0 sent 
[LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x7f793cbe>] rcvd [LCP ConfReq 
id=0xb <asyncmap 0x0> <magic 0xecde7250>] sent [LCP ConfAck id=0xb 
<asyncmap 0x0> <magic 0xecde7250>] rcvd [LCP ConfReq id=0xb <asyncmap 
0x0> <magic 0xecde7250>] sent [LCP ConfAck id=0xb <asyncmap 0x0> <magic 
0xecde7250>] rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x7f793cbe>] 
sent [LCP EchoReq id=0x0 magic=0x7f793cbe] sent [IPV6CP ConfReq id=0x1 
<addr fe80::0dfd:3c3b:e130:91ce>] rcvd [LCP EchoReq id=0x0 
magic=0xecde7250] sent [LCP EchoRep id=0x0 magic=0x7f793cbe] rcvd [LCP 
EchoRep id=0x0 magic=0xecde7250] rcvd [IPV6CP ConfReq id=0xb <addr 
fe80::0000:0000:0000:0001>] sent [IPV6CP ConfAck id=0xb <addr 
fe80::0000:0000:0000:0001>] rcvd [IPV6CP ConfNak id=0x1 <addr 
fe80::0000:0000:0000:0002>] sent [IPV6CP ConfReq id=0x2 <addr 
fe80::0000:0000:0000:0002>] rcvd [IPV6CP ConfAck id=0x2 <addr 
fe80::0000:0000:0000:0002>] local LL address fe80::0000:0000:0000:0002 
remote LL address fe80::0000:0000:0000:0001 Script /etc/ppp/ipv6-up 
started (pid 7049) Script /etc/ppp/ipv6-up finished (pid 7049), status = 
0x0 |