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

Mark Smith <> Mon, 10 February 2020 20:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4622A120847 for <>; Mon, 10 Feb 2020 12:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Status: No, score=-0.497 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Ym0Vbsns4Xyh for <>; Mon, 10 Feb 2020 12:47:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 33189120018 for <>; Mon, 10 Feb 2020 12:47:00 -0800 (PST)
Received: by with SMTP id 59so7780946otp.12 for <>; Mon, 10 Feb 2020 12:47:00 -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=MnhYnHkOskCgZJwvKsWiCXLYQ4BOKM25AwPyL9gzqH4=; b=KA3I2c/iH0G6eTGLrhk965OpCapMM8d0ylUf1nYU7eWITgusoghscpOnSM9WB+DcUx ccBsGm3B8EyJzyTIcbXtSkDbtBLl2u2gIdhKQ1SAe9ewfuPP80/+cCZkgB/nqXpzXG7W YKuotL+64e7RQCCYPU8DJUdFHZXEFZunBRfn13ftv1QE6Zchhffcq7F7wmd8X9qawqYp 1GCULF3q7oZ3wipcRmDS1Twoh1mMcM50+VerbE/YXDbhc8da4f9bhDqP8KD3VfUwAgOL RY+YmKpGF9cUvc1vo8T5+OK7SZoZI9rxV+EPLEfgPiqf4JH0kXZuYaPyik4Zr61Y+b0I 6hng==
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=MnhYnHkOskCgZJwvKsWiCXLYQ4BOKM25AwPyL9gzqH4=; b=jbplDx/dVNLEDO2BeFprGpAvWoQAs6R7lUE+KeVL72rLw7rC3fKZchwlPbYC5IvSCS DVovoJoRxa0S5a/gMkmCN/2b661+JTKzGpvzeX5LczO85rogFEzn6Ra2qGcHYZuldavD KZ2IuB0yFBFpNN+/ZIBPdi+p75pqsGUhAvFn1npt12LmNpCe35LuYJejAaV+HKa9cWL3 V+yVPqF/0lUzMgf3YhqKz2YjaFPB2DcYSXrRJ2CYSLDmdgKrExl+vUNNBzq1DjtZugkD CTBabe0sjONSJ3xHkxqm42y5+W19sGnF/CCAoQBJlwpt0x/BIecxmyJ7GH2J3lwqIDZu /IZw==
X-Gm-Message-State: APjAAAXt/+Mrak0LKTSc88uKIn8Ie5h7oAUYJopftAwCkJyfbcgi3H7U 2fpo7tLSacBaCu8+3Npefb1nIWGwkWzasYyA9Sw=
X-Google-Smtp-Source: APXvYqzXT3O39TUVD8Abd8hFrJA5TCtuwhs3VR7MWWFr18o4d+/u001CXjiEqFcEVcQ+zEUv4cP/KqHBcSyqaTIxCWw=
X-Received: by 2002:a9d:65cb:: with SMTP id z11mr2346764oth.348.1581367619513; Mon, 10 Feb 2020 12:46:59 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Mark Smith <>
Date: Tue, 11 Feb 2020 07:46:46 +1100
Message-ID: <>
Subject: Re: rfc4941bis: temporary addresses as "outgoing-only"?
To: Fernando Gont <>
Cc: 6MAN <>
Content-Type: multipart/alternative; boundary="0000000000003871a0059e3ed761"
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: Mon, 10 Feb 2020 20:47:03 -0000

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.

So, for example, ad hoc file transfer applications like AirDrop couldn't
work on a temporary address only and client-only end-user device.

Peer-to-peer application communications architectures have the node
effectively act as both a client and server at the same time, providing and
receiving service concurrently.

A temporary "server"/service is useful and valid, the privacy issue for
end-user devices comes about if the server/service had a permanent unique
address or IID.

Forcing end-user devices to be clients only is actually the fundamental
constraint that NAT has imposed on IPv4. Certain applications for which
peer-to-peer communications architectures would be better are forced to
adopt a client/server communication architecture just to be able to work in
the presence of NAT.


> The caveats here are:
> 1) If a host does temporary-only, these are the only addrs you have, and
> hence they should allow incomming connections
> 2) It could be easily done for connection-oriented protocols such as
> TCP, but not so easily (if at all possible) for e.g. connectionless
> protocols.
> As noted in
> , *in theory* there are other ways in which the same effect could be
> achieved... so one could certainly argue that this policy should not be
> enforced on the addresses, but rather we should have a more appropriate
> API that could allow apps to e.g. bind() subsets of all the available
> addresses.
> Thoughts?
> Thanks!
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------