pppd: reject IPCP or IP6CP configuration requests

[michael gurevich]

Hi

I am trying to establish a ppp link for device running FreeRTOS that has either an IPV6 or an IPV4 address with host running linux.
For example if device has only IPV6 address, sending pppd command creates on host global IPV6 address and "not global" IPV4 address.

I've noticed that when I reject IPCP or IP6CP configuration requests from the PPPD client, it continues to send empty Conf-requests indefinitely.

tail /var/log/syslog

sudo pppd noauth /dev/ttyUSB2 921600 +ipv6 kdebug 0 nodetach debug crtscts
using channel 8
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB2
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xc0fd1ad> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <mru 1428> <asyncmap 0x0> <magic 0xe7a62d85> <pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <mru 1428> <asyncmap 0x0> <magic 0xe7a62d85> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xc0fd1ad> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0xc0fd1ad]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
sent [IPV6CP ConfReq id=0x1 <addr fe80::d020:7def:e89c:c53f>]
rcvd [IPV6CP ConfReq id=0x1 <addr fe80::d14b:7ff2:c13d:7ee9>]
sent [IPV6CP ConfAck id=0x1 <addr fe80::d14b:7ff2:c13d:7ee9>]
rcvd [LCP EchoRep id=0x0 magic=0xe7a62d85]
rcvd [CCP ConfReq id=0x1]
sent [CCP ConfAck id=0x1]
rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
sent [CCP ConfReq id=0x2]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
sent [IPCP ConfReq id=0x2 <addrs 0.0.0.0 0.0.0.0>]
rcvd [IPV6CP ConfAck id=0x1 <addr fe80::d020:7def:e89c:c53f>]
local LL address fe80::d020:7def:e89c:c53f
remote LL address fe80::d14b:7ff2:c13d:7ee9
Script /etc/ppp/ipv6-up started (pid 62492)
Script /etc/ppp/ipv6-up finished (pid 62492), status = 0x0
rcvd [CCP ConfAck id=0x2]
rcvd [IPCP ConfRej id=0x2 <addrs 0.0.0.0 0.0.0.0>]
sent [IPCP ConfReq id=0x3]
rcvd [IPCP ConfRej id=0x3]
sent [IPCP ConfReq id=0x4]
rcvd [IPCP ConfRej id=0x4]
sent [IPCP ConfReq id=0x5]
rcvd [IPCP ConfRej id=0x5

This behavior seems to be different from what I observe with Windows dialup clients, where a configuration request is sent three times and then times out if rejected.

I would prefer to avoid using "noip" or other arguments in the pppd command line, as I would like the server to have the flexibility to decide which IP type the client should use.

Is it a known issue? Is it possible to reject on of IPCP or IP6CP requests?

Thanks
Michael

[Marco Moock]

Am 03.09.2023 um 01:48:30 Uhr schrieb michael gurevich:

> I am trying to establish a ppp link for device running FreeRTOS that
> has either an IPV6 or an IPV4 address with host running linux. For
> example if device has only IPV6 address, sending pppd command creates
> on host global IPV6 address and "not global" IPV4 address.

IIRC IPv6CP differs from IPCP (IPv4), only an interface identifier (64
bit, not an IPv6 address), is being negotiated.
The client then creates a link-local (fe80::/64) address with that
identifier.
After that is send a router solicitation to get an router advertisement.
This can (normally it does) include a prefix (2001:db8::/64) with the A
flag (address autoconfiguration). It can now use that prefix to create
the global address with the identifier exchanged via IPv6CP.

The IPv6 router advertisement can have the M or O flag enabled, that
means the client should contact a DHCPV6 server to get addresses or
additional information like DNS or NTP servers.

[michael gurevich]

Hello Marco Mooc,

Thank you for your quick response.
Yes you are right regarding IPv6CP

My problem is a bit different, along with IPV6 link-local and IPV6 global addresses,
I got a link-local IPV4 address despite the fact the device is lacking an IPV4 address initially.
I wanted to prevent it and the IPCP request was rejected , but the request kept coming indefinitely.

[Marco Moock]

Am 03.09.2023 um 03:45:23 Uhr schrieb michael gurevich:

> On Sunday, September 3, 2023 at 12:38:42 PM UTC+3, Marco Moock wrote:
> > Am 03.09.2023 um 01:48:30 Uhr schrieb michael gurevich:
> >
> > > I am trying to establish a ppp link for device running FreeRTOS
> > > that has either an IPV6 or an IPV4 address with host running
> > > linux. For example if device has only IPV6 address, sending pppd
> > > command creates on host global IPV6 address and "not global" IPV4
> > > address.
> > IIRC IPv6CP differs from IPCP (IPv4), only an interface identifier
> > (64 bit, not an IPv6 address), is being negotiated.
> > The client then creates a link-local (fe80::/64) address with that
> > identifier.
> > After that is send a router solicitation to get an router
> > advertisement. This can (normally it does) include a prefix
> > (2001:db8::/64) with the A flag (address autoconfiguration). It can
> > now use that prefix to create the global address with the
> > identifier exchanged via IPv6CP.
> >
> > The IPv6 router advertisement can have the M or O flag enabled,
> > that means the client should contact a DHCPV6 server to get
> > addresses or additional information like DNS or NTP servers.

> My problem is a bit different, along with IPV6 link-local and IPV6
> global addresses, I got a link-local IPV4 address despite the fact
> the device is lacking an IPV4 address initially. I wanted to prevent
> it and the IPCP request was rejected , but the request kept coming
> indefinitely.

The it is a problem with IPCP, not IPv6CP.

Does it really give you 0.0.0.0 back or did you replace it here not to
show the IP?
If you don't want IPv4 addressing, why don't you simply disable IPCP
and only enable IPv6CP?

Some systems (Windows by default, some Linux distributions too), create
an APIPA link-local address from 169.254.0.0/16 if they don't get a
normal IPv4 address by DHCP, PPP etc.
If you don't want this, you have to configure the client's operating
system.

[michael gurevich]

Hi Marco,
How is it going and thanks for you time.

I've found a workaround for my problem, .
Just ignoring IPCP or IPV6CP configuration requests - pppd tries for 8 times and stopped.
Same for windows, ignoring IPCP or IPV6CP configuration requests - dialup tries for 10 times and stopped.
Now I have IPV4 or IPV6 address only for PPP.

I would expect pppd handle configuration reject correctly.
The question is - if rejecting IPCP request is wrong and why pppd keeps sending it all the time.

I can't ask from user to use pppd not asking for IPCP as I don't know exactly if I have or not the IPV4 address.
Need to send "noip" option to prevent pppd sending IPCP for example. It would be nice to avoid it.

What do you think?

Thanks,
Michael

[Marco Moock]

Am 04.09.2023 um 07:41:20 Uhr schrieb michael gurevich:

> I would expect pppd handle configuration reject correctly.
> The question is - if rejecting IPCP request is wrong and why pppd
> keeps sending it all the time.

If you don't want IPv4 connectivity, I would recommend disabling IPCP
at all to avoid that anything is being sent.
Although, the machine at the other side MIGHT print an error because it
expects IPCP for IPv4 connectivity.

> I can't ask from user to use pppd not asking for IPCP as I don't know
> exactly if I have or not the IPV4 address.

What is your goal?
Should IPv4 connectivity exist?

[michael gurevich]

My goal is
in case device get IPv4 address ( got it from network provider) - PPP IPv4 exists
in case device did not get IPv4 address - PPP IPv4 not exists, not even link-local
in case device get get IPv6 address ( got it from network provider ) - PPP IPv6 exists
in case device did not get IPv6 address - PPP IPv6 not exists, not even link-local fe80::

Sometimes the device may get or may be lacking an IPV4 or IPV6 address depending on the network.
I would like to avoid asking users to send a specific pppd command, with "noip" option for example

Rejecting IPCP/IPV6CP configuration requests - it keeps coming from pppd.
Ignoring IPCP/IPV6CP configuration requests - after 8 retries pppd stopped sending it.
From device side - I am not sending IPCP/IPV6CP configuration requests
in case the device has no IPV4/IPV6 address respectively.

Thanks,
Michael

[Marco Moock]

Am 04.09.2023 um 23:19:53 Uhr schrieb michael gurevich:

> in case device get IPv4 address ( got it from network provider) - PPP
> IPv4 exists in case device did not get IPv4 address - PPP IPv4 not
> exists, not even link-local in case device get get IPv6 address (
> got it from network provider ) - PPP IPv6 exists in case device did
> not get IPv6 address - PPP IPv6 not exists, not even link-local
> fe80::

For me that sounds a bit like a very special situation.

You want to give out clients not under your control addresses via ppp,
is that right?

You get addresses by your ISP?
By which protocol and by what machine (same like your ppp server)?

[michael gurevich]

I am currently in the process of developing a network device that functions as a PPP server.

The device is designed to be flexible, allowing connections to ISPs that support IPv4, IPv6, or both.

The device exposes a UART interface to the client host which connects with PPP.

In this setup, the device is intended to act like a network bridge, connecting the client host to various ISPs.

IPv4 and IPv6 information will be sent in PPP Configuration ACK, and IPv6 RA in IPv6 traffic after.

The device connects to the ISP, before the client connect to it.

Device Configuration:

The device has one interface for connecting to an ISP.

It also has a interface that is allocated for the PPP interface.


Behavioral Requirement:

When a user connects to this device using PPPD on the client host, I want the user to receive the same IP type (IPv4/IPv6/both) as the one provided by the ISP to the device.

This poses a challenge because the type of IP is not known before establishing the connection to the ISP.



Challenges Faced:

I can't force the client to request only a specific IP type since the device should be versatile and support whatever the ISP provides.

I can't disable IPCP or IP6CP negotiation at the server end as it must be adaptive based on the ISP.





I have tried two different approaches to resolve this issue:



Rejecting Unusable Protocol:

My first thought was to reject IPCP if the ISP provides only IPv6 and to reject IP6CP if the ISP provides only IPv4.

However, doing this seems to prompt PPPD to send endless IPCP/IP6CP empty configuration requests, which I am looking to avoid.



Ignoring Protocol Configuration Requests:

The alternative was to ignore the protocol configuration request for the unsupported IP type.

In this case, PPPD would retry sending the request about 10 times before timing out.

While this works, I would prefer to avoid retries altogether if possible.


I am interested in hearing your insights on this particular situation.

Is the endless request behavior upon rejection expected, or might this be a bug in PPPD?

Are there any best practices or recommendations for how a PPP server should behave under such dynamic conditions?

Thank you for your time and looking forward to your valuable feedback.


Best regards

[Marco Moock]

Am 05.09.2023 um 04:50:28 Uhr schrieb michael gurevich:

> The device is designed to be flexible, allowing connections to ISPs
> that support IPv4, IPv6, or both.

> I can't disable IPCP or IP6CP negotiation at the server end as it
> must be adaptive based on the ISP.

I think the only way to make this possible is to create a script that
evaluates the situation and then dynamically creates configuration
files for the PPP daemon.

e.g.:
If no IPv4 from ISP is available, pppd will be configured not to answer
to IPCP confreq.