Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-04.txt

Mark Smith <> Tue, 28 November 2023 06:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3674C14CF1A; Mon, 27 Nov 2023 22:16:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.603
X-Spam-Status: No, score=-1.603 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tOz2KwqA1DFV; Mon, 27 Nov 2023 22:16:40 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 21042C14CF05; Mon, 27 Nov 2023 22:16:40 -0800 (PST)
Received: by with SMTP id 2adb3069b0e04-50aabfa1b75so7181263e87.3; Mon, 27 Nov 2023 22:16:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701152198; x=1701756998;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JHNO+asEv1XHLL4ao0EljZwAmEYITkjpzBNbjlMyX2k=; b=RbmQ4zcdAXl7ohP6AXby+yiB7SIWVQ9bh04gZE1xoHOBQACzGFOp7ljA8BJYnp7XYe EEmVPYStK5bdq94+pzG0UMja3hFjGH9W9EPLEQ3rfdFjx5Y8cC6ponm9E2NGeqZ6HceA 07naOhfYPIEAnuwwx5DJo+k3pITUqTbxubhK7Gru/rkrHjCnBkSxVUVlA7RY4MC412rI cY4M30jnvCTZdKkRAVQFozr9oIPA6m6KY/t2tzjZ5lX9oYKz05FC7UH6PuyCrMfudGNW 9ERS5OJ36uO+ZYt/F+Lg7rnKCglpCPzGkLEresszFFKG5R5bJSg2k/VWV4Sb+HYO95fx 3AhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701152198; x=1701756998; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JHNO+asEv1XHLL4ao0EljZwAmEYITkjpzBNbjlMyX2k=; b=uNatwX/3tFf4lG7EzsC2mPzCvq69DDY8xXhkrK6H9Uex4E4h/g614tuMdynjOi8mxb nUCG952w3v/1990MSEe6xf9Uw7cTigjyOSiZDhSx3Sj0hiUEhtqLFEA6xr5xuCdmNM3/ OLmALJ7AB4SsVJ3x4dmVajYOIAjcwB6imCeD408rm4YOOTdMZH9oqkthE7PkjnDPXOy9 Doc6aBwqt/Vv8nQ6L6hMdQlf6W7Nk3pds1bGCe9uzPbwFQraTJlQxxtSuPEFeMM7KwH3 mJMJzfAVsxNo9gie316D23rZKTzcF0M8N1dmNBqTsNJyp2rf/cE9A6nYKvyV7tWoNWF2 9rzA==
X-Gm-Message-State: AOJu0Yw5eeF/QQTXz2DrWvQ+Ym7VPlXwYBJmIsRiZvgrxwnwrvqQMl/V 3w+7QRv/+k7k29Zc3KHW7RxABO6yvrgBeI66fJP4XxBFafY=
X-Google-Smtp-Source: AGHT+IH0/WXxz0fHlJYgLmo8uJbMoOqqtPvesZdMm5Ns/QnGPjJd5s9yoaNHrGNdKacpEFKcu1agJV4bjrOqxRrhjoU=
X-Received: by 2002:a05:6512:206:b0:50b:a687:cdee with SMTP id a6-20020a056512020600b0050ba687cdeemr7568864lfo.25.1701152197871; Mon, 27 Nov 2023 22:16:37 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Mark Smith <>
Date: Tue, 28 Nov 2023 17:16:11 +1100
Message-ID: <>
To: Brian E Carpenter <>
Cc: Nick Buraglio <>, 6man WG <>, Tim Chown <>, 6man Chairs <>
Content-Type: multipart/alternative; boundary="000000000000768b65060b305c55"
Archived-At: <>
Subject: Re: [IPv6] I-D Action: draft-ietf-6man-rfc6724-update-04.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Nov 2023 06:16:44 -0000


On Tue, 28 Nov 2023, 15:34 Brian E Carpenter, <>

> On 28-Nov-23 12:57, Mark Smith wrote:
> > I don't entirely understand why ULAs ended up with a global scope,
> Because:
> a) the site-local virtual experiment showed that "site scope" was a badly
> defined concept;
> b) they aren't link-local;
> c) therefore "global" scope was the only option.

I realise it may have just been an oversight at the time, however creating
something like a "local-network" scope for ULAs, greater than link-local
yet smaller than global would have aligned ULAs as scope equivalent to
site-locals and then preferred over GUAs.

RFC3484/RFC6724 use multicast scopes to provide more granular unicast
scopes, so in that case the "Organization-Local" scope would probably be
best for ULAs.

> In practice all "global" means is "not link-local" or alternatively
> "routeable" or "forwardable".
> The mess was somewhat clarified by RFC 8190 (part of BCP 153) defining
> "globally reachable":

I remember that discussion.

One realisation I had was that there is also a "globally unique" (or likely
globally unique) property of a prefix or an address.

Site-locals weren't a globally unique or globally reachable prefix. Not
being globally unique is where the issues with site-locals come up, which
is also where we have issues with RFC1918s. (I.e. RFC 1627 isn't really
about global reachability or routeability, but rather the lack of global
uniqueness of network 10.)

ULAs have (likely) global uniqueness even though they don't have global

Link-Local Addresses don't have global uniqueness or reachability, and of
course their reachability is limited to a link.

The scope IDs/interface IDs that need to be used with LLAs to distinguish
them/disambiguate them is really the equivalent of the site-local site IDs
that were attempted to be used to resolve the lack of uniqueness problem
that site-local had.

"Unique Link-Local Addresses", with a dynamically generated and managed
random portion between /10 and /64 could avoid the need for a scope
ID/interface ID with a LLA prefix to disambiguate it. Just needs to be a
way to have the first device on a link generate and announce it in a PIO
via an RA with a Router Lifetime of value of zero, and a mechanism to have
any of the other hosts take over announcing that Unique Link-Local prefix
if the current announcing one disappears (somewhat like the OSPF Designated
and Backup Designated router mechanism).

(Apple look to have done something like that with the Apple TV and a ULA
Prefix. I don't have a packet capture, and it isn't stated, however I'm
guessing that the RAs being emitted by the Apple TV have a zero router
lifetime so it isn't considered a default router.

New Apple TV 4K acting as router and giving out IPv6 (ULA) addresses



>      Brian