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]


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?
From 59ee72be9b6dba56b5422c0bec88842d61c9c56f Mon Sep 17 00:00:00 2001
From: Benjamin Cama <benoar@xxxxxxxx>
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 <>:

  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

 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)

[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