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

Stewart Bryant <> Tue, 25 January 2022 18:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A89C3A0DB4 for <>; Tue, 25 Jan 2022 10:47:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 9kJxrVEX52qr for <>; Tue, 25 Jan 2022 10:47:18 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 233273A0DB5 for <>; Tue, 25 Jan 2022 10:47:18 -0800 (PST)
Received: by with SMTP id me13so32728011ejb.12 for <>; Tue, 25 Jan 2022 10:47:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=q07FOcRV0a7yPJMFzWLpioeiGPBZCZisAfmfnAnKoiU=; b=mqlXLgOHwebpdJYBfZJL+bHhdAXPW5VCrKBnvTxepV/x9ZHeKfuxT2I//rmQP7Bous wjuWeWkxoJegQAguAYHrcf8t67X5uzBiVgVyS0I75E/hoB4kIEO8IStwreO/KUkLrekf SDIVq/rh/7D/4uoLbq7Ujaw/NpN5n/LF9JHTEVrlQiOBZFkpAsqjioyNrqGur+Jwdxhq fvsX3lr7Hj5hXegr4FM5h8NvP1Hcx5pRuX95bmMF2piip9MX4giCW9ML8fmxlAA1+kIn CmiXXwKPYu+SsdgoP0zVzPly6Y3cR/+OOs0E6G0N4v4btqX2TZYsNKznQlV91y4SldON ngRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=q07FOcRV0a7yPJMFzWLpioeiGPBZCZisAfmfnAnKoiU=; b=Z1aHazhZtnr1JcenkY4NTXbit0deMawHxqUgAfUYKNv8GIM14jt+0h7fhxmIf/nnNu 6F6684AtVh74sYBqbFIojGbIUDpmzLqRCCM1hp2C6U9X+os41LxLUMnEWOWHdLU9ZHft S8EidQ3eQk6VVwJUDLOtAuCxQK+hgXSexiHCYP3uLYoauv5QE350WiAvyTe/GUvurZJb U1XgEjj+IhnoRNO54h9GIif0J5JYAw3cKXbC/4D+VxT0dfA/Z+q4irU5zVSSia+mZdDx vgQM6/WzPNxl0HJsNtjt845+1+7BzmTQ4sY47PT6cZjoqFJdurRmrd0X9E6PMLhHQCsh ylFQ==
X-Gm-Message-State: AOAM531ErQjyDPGWFaGttPwgXgUPvtDPfqzJZJesuQO3WadPlseuGNwt s7kGWZ7WqRUmBGEI230K1ow=
X-Google-Smtp-Source: ABdhPJzsPHl/c3yxnl61pud1QJnMLIahGsbhgcgFAsvSSS69toeTeUzI94sM9DzzfEEjaInc6e3/nw==
X-Received: by 2002:a17:906:950d:: with SMTP id u13mr17185025ejx.153.1643136435618; Tue, 25 Jan 2022 10:47:15 -0800 (PST)
Received: from ([]) by with ESMTPSA id s7sm6495932ejo.53.2022. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Jan 2022 10:47:15 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Stewart Bryant <>
In-Reply-To: <>
Date: Tue, 25 Jan 2022 18:47:14 +0000
Cc: Geoff Huston <>,, Dirk Trossen <>
Message-Id: <>
References: <>
To: Tom Herbert <>
X-Mailer: iPhone Mail (19B81)
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 18:47:24 -0000

There is both a topological view of an address and a protocol view.

The topological view is some place in the network, be that a node or an interface.

The protocol view is that it is an instruction, for example to deliver the packet to the place identified by the address field lookup. In IP this was originally an interface somewhere in the network. In MPLS we generalised and abstracted this to make the label an instruction what sometimes said deliver the packet closer to some network object, but sometimes was an instruction to do something else.

In SRv6 they designed a hybrid of this with the prefix having the original IP meaning, and the suffix providing some other instruction together with some parameter such as send the packet to this VPN.

Thus in my mind the address field in a packet is an opaque instruction that is looked up in some large table and causes the forwarder to take some set of actions that are referenced by the table.


> On 25 Jan 2022, at 18:18, 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. While
> the addresses at each end point of a connection may differ, they must
> be consistent for the lifetime of the connection at both endpoints.
> That's where NAT breaks things, if NAT state is evicted or lost TCP
> connections routed through NAT are no longer viable, hence that's why
> it's correct to say that NAT breaks the end to end model. TCP
> properties also makes it difficult to change the addresses of TCP
> connections on the fly for privacy, but giving each connection it's
> own unique IP address is potentially feasible since there are no
> necessary protocol requirements for consistent addressing between
> different connections.
> Tom
>> Geoff
>> _______________________________________________
>> Int-area mailing list
> _______________________________________________
> Int-area mailing list