Re: rfc4941bis: temporary addresses as "outgoing-only"?

Mark Smith <> Tue, 11 February 2020 05:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FC1C120052 for <>; Mon, 10 Feb 2020 21:19:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5Qj7A6zmZQqY for <>; Mon, 10 Feb 2020 21:19:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82DC7120041 for <>; Mon, 10 Feb 2020 21:19:20 -0800 (PST)
Received: by with SMTP id i1so11641021oie.8 for <>; Mon, 10 Feb 2020 21:19:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IpkR/a+8e4yvvAeRZ8QC9Ku60FBZ1MU5xfoPrsyEZUY=; b=il+nIrLh2291AhH+NDJdLYYPItEvhqEsPYps7lPqhraQwRIkJUSbJ1td2GTnbwHPgS /najdi0getpQRY+rhezmegHPAb29Vf28ZOvNbftMWXkoDypygDpqLqwEMnpivM8s/f+o Mz5cNAp2kR5GmqYKPYeOQA44Is2JMglZRPY7a8KW58WZX2k8DbJtWrzQ/vYBaYAy6nAC G2Mf1IQWXVA+XI6ZT1QBhR9kiDIr3Q9CuPlYeNXHeP0gRHbNK8H4hts6cmwSY1HqVN+I ZV3pVM7gu4hE2DSH3eBwSkjSLvjtkCXIRtSpkzKLrHeZsIMTxVLf9piZADyFQdIsetrP mV5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IpkR/a+8e4yvvAeRZ8QC9Ku60FBZ1MU5xfoPrsyEZUY=; b=kW+3C/6rS/sn6b/EVEwpMX1LEb4IxbEy+TEaCxDph0yEV62gEqDGTQ460f8UohxFMq ag7aR5t8jGqTU/kbmpgGURC21UZHP0wM5/GTmJTPwmx4kns+LR02W8fO6f0nsu73BCR8 u3RiJ+8n554MuXpsHkumZsVtevO1t0ZW5IDatdqiJIB/es4NhbDVdbQCaecovUlYn/m2 LNaPdiLh709q4z7QnUyzoPLrZaNt494nXTPjx9ViemcD0Rc1zwjUdi9ZLU0exNLjAvTa QrL5uYP03n+cMLFuut3CEZuHAbEV1fSHit8x5rd8klpNPhixPjo/77Rev5we2ob9UYZh bfFA==
X-Gm-Message-State: APjAAAUgkCHGufANhawTC4k/jmNc9cob6J7lcp42SL5DvkHm1ZZpbqcG 969cTdbLMFj7vJuGfJVlzhgpPuBiKXujoIKvG84=
X-Google-Smtp-Source: APXvYqzm/8bDCiUEziYHtliIB1M5/eA8s7R1OBByebkjsI29frSzw0OdnmIBW/JpeRck41jb5Irxg6snqhkmDvdh39c=
X-Received: by 2002:aca:f44a:: with SMTP id s71mr1810564oih.7.1581398359809; Mon, 10 Feb 2020 21:19:19 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Tue, 11 Feb 2020 16:18:53 +1100
Message-ID: <>
Subject: Re: rfc4941bis: temporary addresses as "outgoing-only"?
To: Fernando Gont <>
Cc: Brian E Carpenter <>, 6MAN <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Feb 2020 05:19:22 -0000

On Tue, 11 Feb 2020 at 15:32, Fernando Gont <> wrote:
> On 10/2/20 19:17, Brian E Carpenter wrote:
> > On 11-Feb-20 09:46, Mark Smith wrote:
> >>
> >>
> >> On Tue, 11 Feb 2020, 03:13 Fernando Gont, < <>> wrote:
> >>
> >>      Folks,
> >>
> >>      Since we are at it, I wonder if rfc4941bis should say anything about the
> >>      use of temporary addresses for incoming connections. (see
> >>
> >>      (e.g., "an implementation MAY....")
> >>
> >>      Particularly for connection-oriented protocols, hosts that prevent
> >>      incoming connections on temporary addresses reduce exposure even when
> >>      their temporary addresses become "exposed" by outgoing sessions.
> >>
> >>      i.e., if the model is that temporary addresses are employed for outgoing
> >>      connections, unless a host uses temporary-only, there's no reason to
> >>      receive incoming connections on temporary addresses. (e.g., browsing the
> >>      web or sending email should not be an invitation for folks to e.g.
> >>      port-scan you).
> >>
> >>
> >> This would prevent peer-to-peer connections between end-user devices, as it means devices become clients only, and they therefore cannot provide a temporary server/service.
> >
> > If a node has a stable address as well as a temporary address, that isn't the case.
> That's what I had in mind.

So if we want to support adhoc peer-to-peer file transfers between
e.g. smartphones via NFC/Bluetooth/Adhoc Wifi, then stable addresses
are required, even if the file transfer takes say 30 seconds, well
within the valid lifetime of the RFC4291bis temporary addresses?

I think it is a very dangerous path to codify client only IPv6 hosts
(as distinct from temporary address only IPv6 hosts). I think it is
counter to the fundamental goals of the ARPANET and the Internet:


'Historical/Philosophical Context

     By "intercomputer networking"  we mean the attachment of
     multiple, usually general-purpose computer systems--in the sense
     of Operating Systems of potentially different manufacture (i.e.,
     "Heterogeneous Operating Systems")--to some communications
     network, or communications networks somehow interconnected, for
     the purpose of achieving resource sharing amongst the
     participating operating systems, usually called Hosts.  (By
     "resource sharing" we mean the  potential ability for programs on
     each of the Hosts to interoperate with programs on the other
     Hosts and for data housed on each of the Hosts to be made
     available to the other Hosts in a more general and flexible
     fashion than merely enabling users on each of the Hosts to be
     able to login to the other Hosts as if they were local; that is,
     we expect to do more than mere "remote access" to intercomputer
     networked Hosts.)'

Client only IPv6 hosts would not be able to be more than '"remote
access" to intercomputer networked Hosts.', despite having CPU, memory
and network bandwidth resources 10s and 100s of 1000s of times greater
than the hosts had in the 1970s and 1980s.


> > However, I think it is rather out of scope for 6man to regulate this point. What might be good, but is also probably out of scope,
> > is a socket option to allow/disallow incoming connections to temp addresses, and a socket error code if they are disallowed and an upper layer tries to bind a socket to a temp address.
> The thing here is that, unless the address has been generated upon
> request of an app (something not possible at the time of this writing),
> apps share addresses and thus no app has authority over any address...
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492