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

[Benjamin Cama <benoar@dolka.fr>]

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