Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

Tom Herbert <> Tue, 25 January 2022 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E62103A0A0D for <>; Tue, 25 Jan 2022 13:23:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DIxdK2oe6oXH for <>; Tue, 25 Jan 2022 13:22:55 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 826BE3A0A10 for <>; Tue, 25 Jan 2022 13:22:55 -0800 (PST)
Received: by with SMTP id m4so33727301ejb.9 for <>; Tue, 25 Jan 2022 13:22:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Hbu7sCjnxauhD2WQ8eoZE1PpNT+q3NuKImxtjmyQzmo=; b=d4uE7pso8fMeWyLfS3cOXQjuO1rNxyZWBprzfd+wEhxJyTmgEF/wpdHdX3cfWS+1Qd UHiQR5m4gjd3cvne221P0ym9kfMziTy0tP0JiqEISQvrccY4gW9HPvKR7VqFLlh5CLIR TLyk9/RhBhiMcuH7iXXOCsFRXDox5vi7dC4VmW3w2F/HyOOgKrwj0K+LbzS3w59uY/IK TPx2vBBhilCzA+eAinNEaegBq4XtBwU7D0BzRhOxDtNQv8Xdv5127QLVN9sm8zt4p0H9 DkDPWjCkD9ydTiIPwhuedJnYo5UP3WcWwyFOg49HBKNKqJ/PINleE2/1vP48Pm/oGyG5 S9qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Hbu7sCjnxauhD2WQ8eoZE1PpNT+q3NuKImxtjmyQzmo=; b=hdGQ6hqxz4Riv0CHQBGODlUmiEJ38jDyWqlWTkmhrjLAHNN4i76Odse2mSK8AFqJDl zQCc47g3b9tA6NbrHPndVIwfdc646E0t8OiPBO8jWF1x13QfmXuy7yKEyxqqfLLLsMNe jT+McjtwIhYoXsQdRenfTsmJxTTKudrAdAacPTBl8VhuZ61wA22x+C0GfAAMcYXb5fDc toJafsHDf58AbuTPDit0rMcyTQwnMbXHVzU0KBl7F/FrmnZZaZZtW8QzJJTJkVaeuogk /W5TsxrX47r67VrnrdXZRUDJiaqO3Om8yL/fGHrKmgpPfx8RS3ckUbl8z145nLiz0Rtd yMfQ==
X-Gm-Message-State: AOAM533ds8BImAYtlC/Nw/KW/W2KncSUWOWs2hS8+d1v7vV//PsENGs0 U28Sp/qB48LIupjSlBu3OZ9Xpp/ZpZOfX5Cg6qHQSw==
X-Google-Smtp-Source: ABdhPJzKzzf17R3/OxJzsOJ3oywAQeCmjlR+UnNDyoM7rhZLyXLsuzgJFxwHZSmsHqkWYsnok6BoiOCAbyd0B28Oh94=
X-Received: by 2002:a17:906:c40f:: with SMTP id u15mr14197281ejz.366.1643145772665; Tue, 25 Jan 2022 13:22:52 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 25 Jan 2022 13:22:41 -0800
Message-ID: <>
To: Geoff Huston <>
Cc: Dirk Trossen <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Int-area] Continuing the addressing discussion: what is an address anyway?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Jan 2022 21:23:01 -0000

On Tue, Jan 25, 2022 at 11:30 AM Geoff Huston <> wrote:
> > On 26 Jan 2022, at 5:17 am, Tom Herbert <> wrote:
> >
> > On Tue, Jan 25, 2022 at 3:38 AM Geoff Huston <> wrote:
> >>
> >>
> >>
> >>> On 25 Jan 2022, at 6:19 pm, Dirk Trossen <> wrote:
> >>>
> >>> All,
> >>>
> >>> Thanks for the great discussion, following our side meeting at IETF 112, so far.
> >>>
> >>> I wanted to turn the discussion to a key question which not only arose in the side meeting already but also in the discussions since, namely “what is an address anyway?”.
> >>>
> >>
> >> In this world of NATs it seems that we treat addresses as no more than temporary ephemeral session tokens and we've passed all the heavy lifting of service identification over to the name system. These days you and I could be accessing the same service yet we could b e using entirely different addresses to do so. Or I could be accessing the same service at different times, and again be using different addresses each time. I find it somewhat ironic that we see increasing moves to pull in IP addresses as part of the set of personal information in some regulatory regimes, yet what the larger network sees of end clients is a temporary NAT binding to a public address that may be shared by hundreds if not thousands of others.
> >>
> >> And IPv6’s use of privacy addressing achieves a similar outcome in a different way. And QUIC’s use of the session token inside the encrypted envelope even makes the binding of an address to a single session fluid, as the same QUIC session can be address agile on the client side.
> >>
> >> So perhaps an address these days is just an ephemeral transport token and really has little more in the way of semantic intent.
> >
> > Geoff,
> >
> > That might be true for QUIC, but not for TCP. Each TCP endpoint
> > requires stable addresses for the lifetime of the connection since the
> > addresses are part of the four-tuple identifying the connection.
> Tom,
> I think you may have missed my initial characterisation of IP addresses in your response: "we treat addresses as no more than temporary ephemeral _session_ tokens” i.e. the NAT model relies on session level stability of the NAT association.
> My comment about QUIC is that the QUIC protocol does not even require that session-level stability of address association, and QUIC sessions essentially require stability of association only on a time basis approaching the RTT interval.
Yes, but TCP doesn't have those properties so we are bound by that at
the least common denominator on the Internet until TCP is obsoleted.

> If you wish to construe various judgemental observations (Like "NAT is evil”, “NBATs break stuff”, etc,) feel free, but they are your constructions, not mine. The issue for me is not judgments of “good” or “bad”, but simply to explore, without overtones of judgement, exactly what an IP address represents in today’s Internet.
I'm not sure how I was making a judgment, NAT devices do factually and
transparently break transport layer connections when NAT state is
evicted, packets are rerouted, or network devices crash. Any
discussion about what addresses are in the current Internet has to
include this consideration. My point is that there are host
requirements relating to addresses that the network must be aware of
if it is applying more semantics than just for routing (this probably
degenerates to the age-old problem that IP addresses convey both
identity and location).


> Geoff