IETF Logo Mail Archive

Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

Lorenzo Colitti <lorenzo@google.com> Thu, 11 April 2024 03:30 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A42C14F6B1 for <ipv6@ietfa.amsl.com>; Wed, 10 Apr 2024 20:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KazX5uEVGeQU for <ipv6@ietfa.amsl.com>; Wed, 10 Apr 2024 20:30:26 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 0DE33C14F60F for <ipv6@ietf.org>; Wed, 10 Apr 2024 20:30:26 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2d700beb60bso118943251fa.1 for <ipv6@ietf.org>; Wed, 10 Apr 2024 20:30:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712806223; x=1713411023; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sDd2y7a8PQvTN2h5ZpS8iMOxfknTWA6r717OasSZqys=; b=GDme+z82elKh+oBekYzGWc2D4wdrXAfYvmhwOKtt6NznNUq+U6l03Fe8zgMyBgqAFy ZJNAqAmzVZaBCPGTHSCp+6zm5/h3AEGoLQ/+0bOpTeHvP0tP/eZ5hWPSUzOt/N/Kg/WZ LUhrThZgV15BsUt/+yHN4byowVq96B/kBLrTffpffCXEBWPsZOdgZ9OiiAhRcQXunDRR VQe2w3wU8m/T8cGSWoAst92yudYr9UFyvoyVbg0tnQfsU9zO9xT0anNBX/MakoAhP61c LSMR/1wyVE5oGFji7erXk425dZ+saZqnxzvkRcWvnST0jpMA6OLQcUntJQuTpF/Otjwv Cu8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712806223; x=1713411023; 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=sDd2y7a8PQvTN2h5ZpS8iMOxfknTWA6r717OasSZqys=; b=VUygKH8tcdf1MnKjRs+4VK1W2/kfFKaA+NBQ89CNpCmlaAB/yUiSpWef75XRWvBKpv AnLq8oEhW1xM9VntUgE8QiygCRj6qKxNvycEV6f/tX96DHmhiwgzWk/sNNKBMAkQ9uIG G3VOSzmJY3TigurpykCn50RljfSTwXUiDZ5+XtMaKP1mHKthvi5qDOrepj/35hAXzSIT 6Xskct3BCSWSmm0/1u+GV9s5r4W2DQLERVwSPNaRLtIK0wTo/FoVaOtLQe56sBLejhzL dQaSxDtdfPB7gvu5WEDTBACKsTAHx4FDOWNR1fhNYJC25Tfhnl38rklqQVVrm2Y0NhGh PN7w==
X-Forwarded-Encrypted: i=1; AJvYcCUesho5nC4IF9TArWyYjGg5EhTVb4rS0Tm/TJLPjhToWJq9J4l1iYeCw3vBB7RM8EzFAg0JCCFEqZXgbRTx
X-Gm-Message-State: AOJu0YyS8ybA2hyCQYBkZXMbSLpT5RQq6kT5iSWpYRU8DiWrcuoSyxT6 dY7uC65Hp+PahcK3BiKs1hcFTvfAA7k1eIsQIrfz0hCyYyDl4ZccC5EmTGCVxk+AsF3TDckqesj aUxbzUk77fZqFsDoFD/T5RhunPq35mP8lZBPTXctW7LXdvR/Y8RWB
X-Google-Smtp-Source: AGHT+IE5X1z4Rig5MSlSvj3EUA4Dv7BEKzA7FnBz4kXJwKPar/JBIXQKFzC1hzqXFg4xmNE4qSdUni1ORZh4NYu1KU0=
X-Received: by 2002:a2e:90cb:0:b0:2d4:5370:5e8a with SMTP id o11-20020a2e90cb000000b002d453705e8amr3540955ljg.22.1712806223090; Wed, 10 Apr 2024 20:30:23 -0700 (PDT)
MIME-Version: 1.0
References: <6A5E5F35-B35F-4358-8EE1-3BD82329141E@jisc.ac.uk> <6FBC1B5A-BF28-4B05-B2B2-A60DA4707755@gmail.com> <CAPt1N1m-Ye8vfOVnsPesFshLMV5QuVoxWqM=HVZiJ37zaBg6AA@mail.gmail.com>
In-Reply-To: <CAPt1N1m-Ye8vfOVnsPesFshLMV5QuVoxWqM=HVZiJ37zaBg6AA@mail.gmail.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 11 Apr 2024 12:30:09 +0900
Message-ID: <CAKD1Yr1NTvFj0zB0=+nnUKck7TBtwHFz2XoFkD1smx4yCuZohQ@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007fc5580615c9c610"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/D3V9dKoAB3rdqUMXaspb2DFLeMk>
Subject: Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2024 03:30:28 -0000

On Thu, Apr 11, 2024 at 1:04 AM Ted Lemon <mellon@fugue.com> wrote:

> I continue to think that section 3,  "Operational Issues Regarding
> Preference for IPv4 addresses over ULAs," should make the new proposed ULA
> behavior mandatory rather than optional. I don't see a downside to making
> it mandatory. Hosts will come into compliance when they can; older
> implementations will not implement this new behavior, but I don't see any
> point in perpetuating that.
>

Absolutely agree. This document should not proceed without that MUST.
Preferring non-local ULA over IPv4 is incorrect because IPv4 implies global
reachability, and ULA does not offer global reachability. So publishing
this document without the MUST is harmful: an implementation that does not
implement the SHOULD will cause regressions and break use cases that work
today.

Also, MUST allows us to make ULA more useful than it is today. It is
*desirable* to be able to publish non-local ULAs and have hosts know what
is local and what is not. As a simple example: once all hosts implement the
MUST, it will be safe to publish local ULAs in the global DNS, because
hosts won't try to use them unless they are local.

v2.23.0 | Report a Bug | By Email