archive mirror
 help / color / mirror / Atom feed
From: Benjamin Cama <>
Subject: Re: Configuring pppd to accept link-local IPv6 interface id from remote peer
Date: Sun, 14 Feb 2021 21:24:12 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

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

  parent reply	other threads:[~2021-02-14 21:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-14  1:03 Configuring pppd to accept link-local IPv6 interface id from remote peer 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 [this message]
2021-02-14 22:46 ` James Carlson
2021-02-14 23:15 ` Benjamin Cama
2021-02-16  0:10 ` Nicholas Humfrey
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:

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

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).