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

Fernando Gont <> Tue, 11 February 2020 04:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D536912008A for <>; Mon, 10 Feb 2020 20:32:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pCpVHpDmMn5X for <>; Mon, 10 Feb 2020 20:32:15 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8012B120072 for <>; Mon, 10 Feb 2020 20:32:15 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 09F2486C3E; Tue, 11 Feb 2020 05:32:11 +0100 (CET)
Subject: Re: rfc4941bis: temporary addresses as "outgoing-only"?
To: Brian E Carpenter <>, Mark Smith <>
Cc: 6MAN <>
References: <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Tue, 11 Feb 2020 00:44:14 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 04:32:18 -0000

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.

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

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492