Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Mon, 18 March 2024 20:55 UTC

Return-Path: <Fred.L.Templin@boeing.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 3D859C1D61E1 for <ipv6@ietfa.amsl.com>; Mon, 18 Mar 2024 13:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com header.b="B947MfLy"; dkim=pass (1024-bit key) header.d=boeing.onmicrosoft.com header.b="aQeNJ+oL"
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 ly3uNvukNhsZ for <ipv6@ietfa.amsl.com>; Mon, 18 Mar 2024 13:55:29 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDA1C1D5C77 for <ipv6@ietf.org>; Mon, 18 Mar 2024 13:55:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 42IKtPe6014674; Mon, 18 Mar 2024 16:55:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1710795326; bh=pDmH/RlnfKpmBR/6AoRnqyhyzZ1t1r16UNf7rGkV6+k=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=B947MfLyHc7DWUedFI84xmiH0I08UXIUjDXCcNyMtCxwMmczl/iO76t9o4uL+bxo9 hbRymn2psYuKVElqjkovEvls5JX3038O7RsTr8B8dF/OyEI+5oOZd2zItGQb0nCiI3 5nwbExmvq2THHcOJzsXWHhMSagZpe/aaFmkrc1/06i6Ae+J8RwePwsGpkyeTaP9pQi gKiOeLNqoEtLNLeAyzQWjlMrPlE/RPMpFbiIsZEuaZCkGGdluCF0O8z53eayAB6W8V K7DGdzrMpln1b9U5FLr0u2Y/cKnEd1XYcQLYpbNoTOvyXgjCy2xfSXJ/GVu2V9gUB3 dRRnymBLj3myQ==
Received: from XCH16-03-11.nos.boeing.com (xch16-03-11.nos.boeing.com [144.115.66.83]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 42IKtL6T014625 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Mar 2024 16:55:21 -0400
Received: from XCH16-09-10.nos.boeing.com (144.115.66.159) by XCH16-03-11.nos.boeing.com (144.115.66.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 18 Mar 2024 13:55:20 -0700
Received: from XCH19-EDGE-C01.nos.boeing.com (130.76.144.197) by XCH16-09-10.nos.boeing.com (144.115.66.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35 via Frontend Transport; Mon, 18 Mar 2024 13:55:20 -0700
Received: from USG02-CY1-obe.outbound.protection.office365.us (23.103.199.175) by boeing.com (130.76.144.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 18 Mar 2024 13:55:05 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=EJoC9Io+1IXSaQDPFUcw+3CoykOr523xnZemtk+83p7LRYT8g+QIsfM+PRJL/ggyYuwRwWOFlVo4AEA4thxX6ggfQD60bPfeY8PQhVmGnqR6C/JZkeHOTNeFI2B1D+6gPhYcyfrRE9f9O4GlE5SMP6qo0Fu3Q/0rY4Dkni5wDkljHXnImnmzM3cQVglpWeONPXZ3RWJR0/PqHsj5FcPiQc2MAcZLBKXMF9nxsULluu+otAA0VQxel5KEBoqJ25kNn71cEn4SVWGh8fXHIqCmdzBRTwjO70rf6HHlqzDKkYc1mUevBlGL8D13NrheqlIlf27M06OtK1MRbwo9wWopAg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pDmH/RlnfKpmBR/6AoRnqyhyzZ1t1r16UNf7rGkV6+k=; b=NEXkzwuPT/XWJdlACrqDv5DHIuAWbNvTNf3joUUfRusfcZ3r1FfVcC2eytoSnel66A4APX4P8DnwPWbNAMOpp1ah8yrf8rtryF/+ui3/5WTVmYocAGkxzO2EJjljX94mbiqbyyYQaIM8bBzFJIGILztUDfHF8pYCeYzyVf2twh79SE/guCDIwepFHcCG0WI4k9na8uGRqSPffLs/p5WGGZcP1AjRehQGsofmk6RAzjhX78x2rk1Cb2CCWjYUUp9U4GaSm+CfzuzhVngVCaJUyNEZVhexNfvJo0Wqae7Jf4CLraTDk3brBwi8Pzl0lYdu8ZSbVlHPZmuV6+X5uxTRLA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=boeing.com; dmarc=pass action=none header.from=boeing.com; dkim=pass header.d=boeing.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.onmicrosoft.com; s=selector1-boeing-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pDmH/RlnfKpmBR/6AoRnqyhyzZ1t1r16UNf7rGkV6+k=; b=aQeNJ+oLUGMXCp3oP2PG9LFoDtbNl4kBgoDfMcT7rq2t5rct2b/sZFqsO5WEOaVML6vP9c4rHR8qn8MNJL46nWCSP1wsaCcmYdrfAeFLzTceeDneraegaZgi41POM2UC/3lC7E4TKtwoPOnWNAfhuhwmHYgE5PMZZtbMrtcIvPo=
Received: from BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:183::19) by BN0P110MB2020.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:19b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.27; Mon, 18 Mar 2024 20:55:05 +0000
Received: from BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM ([fe80::8c1e:e835:7bba:e88e]) by BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM ([fe80::8c1e:e835:7bba:e88e%4]) with mapi id 15.20.7386.025; Mon, 18 Mar 2024 20:55:05 +0000
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Mark Smith <markzzzsmith@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, IPv6 List <ipv6@ietf.org>
Thread-Topic: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
Thread-Index: AQHaeXaNdbDoA4TzmUq7v0zHD6Zs3A==
Date: Mon, 18 Mar 2024 20:55:05 +0000
Message-ID: <BN0P110MB14200EF94010012482F20E9AA32DA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM>
References: <df333346-f108-3782-0ff5-4bd85d7b49ac@gmail.com> <015F13BE-32F7-4C8B-8C86-C9153FE9C9E9@employees.org> <CAPt1N1mr+YLQjHf6wKK__-K1-Rywtg0K03DpwZZRz6USHOKfhA@mail.gmail.com> <75254.1710741218@dyas> <CAPt1N1keJHigR0LTG_Q-3SNDccfq5VKOVXU3wTreFgYa8KMVew@mail.gmail.com> <CAKD1Yr1wVuNDwGHa_aRzz5HThV5mtJwy1Km7=GT912DzcwcXFQ@mail.gmail.com> <CAPt1N1nG8bNeLw1LW_0NK-XJC1J_mhN82xyTnTnM0JR=RWr4Zg@mail.gmail.com> <CAO42Z2yqmx40PCdUPacq_ULWunCHiV6RfcJSGjNUatv4SrjEcA@mail.gmail.com> <b1278d74-4971-b2d9-260e-adc3d3243e9c@gmail.com> <CAO42Z2yW8xC=j0dApgXqmoAECVMr3N0ezorSYQD-mfcMSjs27A@mail.gmail.com> <70a2c5d6-f370-bf4e-c5bc-fea2016dba18@gmail.com> <CAO42Z2xak94R_GA0SkJwFs0uP2jmpCJ3=eon1DDjK7=gP8BX8A@mail.gmail.com>
In-Reply-To: <CAO42Z2xak94R_GA0SkJwFs0uP2jmpCJ3=eon1DDjK7=gP8BX8A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=boeing.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BN0P110MB1420:EE_|BN0P110MB2020:EE_
x-ms-office365-filtering-correlation-id: 03b90960-897d-4abe-7249-08dc478db01f
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jtGmgrBvJKYHelJ0G/wQxX5+zHvk+aNphC88Y9wE6Xa2DEDHxLfRtr0it9pT48djYvVh0Pp8EyW1GNqvxzDp8MThZHldomWZy/mHfHbmEKOnNk5aUX9DK/YoQD8Fo7oww5i67Yc7kET1qTb+rFOaHdkACZN1qd1Pi1G/K5qrGZZJVmgK6qe9VHSvHT3Zd+P6/rf/KbyLDnHAi0+BZxlDb8FDfTGKZg9iTg2FD3tOvd7hm0el8f2wOnpdDZBN8AoaVIAuuNJmwuGU+KH/SdU9YVsj4hoUkIXm2TAZxkA9EfdDayFgctfkdXdSfvZoQpDMIEoQPDic6plmiPbvPETAZO2b44lwM3iKw2flVMzA4i8ZzmYdwtatoDvokfgffs+m5QEgyQlRUGFncMPfpOnnnDAfIDWM7vn9Bziig+Kf0TwKGkFs+KFRFwIzYOT+RYbe9flzG61YZ2OfhtGPZzNTCJ+OUa+Lgt4awUaF4fib7zp6juE3yff+6OKKM7Cef7RDG8bANtNnnJxMYGRw5QnvJbP5zwLXRK8h73YsaslprLv1cXlMXCZYMst5jJOn/eBhIRirSFhP8T9pLaIDbjcle74tKIWt9n008RsGzvBAyXCvpmKlBZ4cnps/iGsBn7zPfB0rukx6ZPRMdn4cAjUM64hM7rqY6XqD3tPjWcSUKCw=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(1800799015)(366007)(38070700009); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: AL8aHrSj4Zd/5I72ApzbNv9daF4WYB1BLjdMnpUwgshAjFppTtIH3k4CEhOaiavvF6ZtR8+lVQKZsWq3/70ajn7xnEsg2btE9yujQ7LjOe2PDb0z7ClZblvE/xi0cFf0SADL8Isy4bbHNR8pWXh2q7dg4uCmaqyOIwpvnoHI8SFz+0Nfbs1Iv7c5Ysq0x8qEOVx6B0QI5muz1bWM94y1QqGXIiAjOKqHnbINe0VOyfadiqKDa4N/CQlyqtlpGkKI6en5kDwkJJQEAPwdl0oOkeNSTvoD9E8K/kQTdPbtEJbcigGu2wdcaUyidt6IGZiukHdlV22ny7bwYxICWtoS5afTLe2SM0kqKqWer7/LdvZbrUWemQa8iPfMFafU/tqNwMr1nkFoHlWWClrKjYgzOhqpQPnU+M4NVTQ7h20PogB928d2ZmAZQ5bHDWEyN8j8ls7i+bhIjjjO8YDpTTQQFgzn/FJiXV6TlswOVT+4LxslMRG1nbMmyRn/9TFVGHDITK1hbzZr2u/LX0sf4Tsxubpl099FCshHHAH9Zbbkozoimomu44dmtMOCfQ3FLInrcUYuoHoUAxIlTLOMwDBHaaofslcfewDuKIuB58ShZnhDJ3MHOFrlq4PW6GMRrMkRibUQkcCr4WaM/yx5suFPTsMOnMR0rnATVM1RXR4k7mriozIXfTzqOF67MKUwpxEpNN/X5LvaFuHEdp+bDjGFjRK6iogQChop9fo1zvxU4LvG7bJEf/2yzUxSXA5FULHolvD2d296UOY6Ks6TjxobrNr4wB/LZSi/FHhWCrlk06/Kbml2YNlJ0IypsRs3woR/FPnaGp27Oy9GkUkiQWeiF4yr8Tu0td4GUNtzYE3y4FnRBQrmyCGaV75u82vvYA8g3LIoQJ4wVQFjixCjRX9TL3VzsdI80xu9Jz2gn5z9KiQXcTiYWY1xSxb2oPlvVLMrEnKtmBgg8oCSRR4jPaOCFmOp+KXBKAPrdRU0WsHepqGHYIjpqvWQ88AF0vNhiRN5af6bGxo0nS+bICefFTevh91btrc0zI/gfXXNGSWgCBvnyO/CLpyh2cL9R+wbYABBZpa51TksmioWJRi24veFETP550z4V7A3KAwj6WJMdAJPxLwVIg/reDkJMchsu8u2mO0GNi2xBmuQh4nfg8OCraVMietFMBYa6lMSniFNYySHymefKGAqPnEu4FTUQuR9ZqhUyEVmKUfqi2Y6nZ987g7fQtDFiDo9N5IM3NnPeDikb66DPQqZUbnFH8sh/K5i7HpnuBFGN1gyQW3/aNEhJFqaIsJlBLLK/szyLbBMoanSQEtHQeGUYwiqHUfqp42Zla4e8PZQaxrlexul6qC7EU7CHCg3elL7WyhNfKkmWMCDQCZMwLUoCGNHXivog9+g0XT0vAZNcIqUYIMDcfzHPtEdlRyezvSfngl+is0aKtMZV6/aL9CGs+E0C1VdVVXGxJRseyMQ+VhXDwEH5WHqLxqY5MZ8ZFAiGQHNOfi5pNog9H3fZPnRMZCQCjMGLpGc
Content-Type: multipart/alternative; boundary="_000_BN0P110MB14200EF94010012482F20E9AA32DABN0P110MB1420NAMP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 03b90960-897d-4abe-7249-08dc478db01f
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2024 20:55:05.0177 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bcf48bba-4d6f-4dee-a0d2-7df59cc36629
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0P110MB2020
X-OriginatorOrg: boeing.com
X-TM-SNTS-SMTP: 76792CA06B020B9A4F666E043CCA4CA29F6301CCA44DDE286A1D173EDDE58BE42000:8
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/IED5d2mw1qT3PPSOF-80NDnQL6Q>
Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
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: Mon, 18 Mar 2024 20:55:33 -0000

I (still) support adoption, but the whole world does not need to be all-PA or all-PI;
we can have it both ways, but this spec is essential in either case.

From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Mark Smith
Sent: Monday, March 18, 2024 1:30 PM
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>; IPv6 List <ipv6@ietf.org>
Subject: [EXTERNAL] Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

EXT email: be mindful of links/attachments.



On Tue, 19 Mar 2024, 05:11 Brian E Carpenter, <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:
Mark,
On 19-Mar-24 01:36, Mark Smith wrote:
>
>
> On Mon, 18 Mar 2024, 18:42 Brian E Carpenter, <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com> <mailto:brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>>> wrote:
>
>     On 18-Mar-24 21:35, Mark Smith wrote:
>      > On Mon, 18 Mar 2024 at 18:03, Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com> <mailto:mellon@fugue.com<mailto:mellon@fugue.com>>> wrote:
>      >>
>      >> Right. In fact I think we recommend that for the home router use case already. Sorry, I was really trying to figure out a reason why we’d want this, but internal ULA handles the “no renumbering” concern, so that’s not a reason.
>      >>
>      >
>      > ULAs won't solve the renumbering problem after
>      > draft-ietf-6man-rfc6724-update (and doesn't  with RFC 6724).
>      >
>      > Once GUAs are preferred over ULAs by default, then GUAs will
>      > automatically be used when ULAs are available to reach a host, if they
>      > share a single DNS/mDNS name.
>      >
>      > A host could have 2 distinct DNS names, one for the ULA address, and
>      > one for the GUA address, however that makes the first step of
>      > Destination Address selection an unstated and unfriendly one, each and
>      > every time - a human takes the first DA selection step, deciding which
>      > DNS name they use for the host.
>      >
>      > Happy Eyeballs v3 won't solve this problem either, it uses
>      > RFC6724(-update) sort order to choose which IPv6 addresses to attempt
>      > to connect to first, so GUA will be chosen first (and of course Happy
>      > Eyeballs doesn't get supplied with or chooses between 2 DNS names for
>      > the same node.)
>
>     HE v3 can still be changed. See the discussion a few months ago about
>     get_addr_pairs() for example.
>
>     https://github.com/becarpenter/getapr/blob/main/ProofOfConcept.md <https://github.com/becarpenter/getapr/blob/main/ProofOfConcept.md>
>
>
> I don't think it needs to be charged. It's primary purpose is to deal with reachability problems in the presence of a DNS entry with multiple IPv6 and/or IPv4 addresses.

Sure. But if the multiple DNS entries happen to include both a ULA and a GUA for the same FQDN, HE will give what you consider below to be the wrong answer. (Since I agree with you, my get_addr_pairs() is coded to give the right answer, i.e. prefer ULA-ULA.)

So HE needs at least to have a built-in policy option for this.

> Why not let HE deal with the rarely unreachable ULAs if somebody erroneously puts them in global DNS, or when a ULA much be unreachable for some other reason.

It will. Which is why I think Lorenzo's concern about unreachable ULAs is unnecessary.

>
> RFC 6724 got 2 things wrong:
>
> - put ULAs below IPv4
>
> - put ULAs below GUAs
>
> RFC6724-update only fixes one of those problems.

That's really for the other thread...

You're right I've confused the threads, however if nearly everything I thought I was writing about rfc6724-update also applies validly to a  rfc6296-bis discussion, I think that says it's a single problem space and a solution or related solutions need to cover the single problem space.

Regards,
Mark.



>
> ULAs are the replacement for site-locals, just without the ambiguity of site-locals.
>
> Site-locals were preferred over GUAs, due to the scope comparison. ULAs, being the direct replacement for site-locals, should also be preferred over GUAs (not via a scope check, however the outcome should be the same).
>
> I think anybody who takes the position that the first IPv6 DA returned by getaddrinfo() must work,

Indeed. get_addr_pairs() claims that the first address pair _should_ work, which is a rather different claim.

    Brian


> which is implied by GUAs being preferred over ULAs, is really saying the following:
>
> - IPv6 hosts should only ever have a single address, because having multiple addresses implies that multiple addresses are needed because there may be reachability problems to act if those addresses.
>
> - getaddrinfo() only needs to return a single IPv6 address for any and all DNS look ups, making DA/SA selection much simpler.
>
> - Happy Eyeballs only needs to attempt to connect to a single IPv6 address and a single IPv4 address, also making HE simpler.
>
> - Multipath transport layer protocols have no value since there would only be a single IPv6 address to connect to on a host.
>
> Regards,
> Mark.
>
>
>
>           Brian
>
>      >
>      > Regards,
>      > Mark.
>      >
>      >> Op ma 18 mrt 2024 om 16:37 schreef Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com> <mailto:lorenzo@google.com<mailto:lorenzo@google.com>>>
>      >>>
>      >>> On Mon, Mar 18, 2024 at 4:09 PM Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com> <mailto:mellon@fugue.com<mailto:mellon@fugue.com>>> wrote:
>      >>>>
>      >>>> On Mon, Mar 18, 2024 at 3:53 PM Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca> <mailto:mcr%2Bietf@sandelman.ca<mailto:mcr%252Bietf@sandelman.ca>>> wrote:
>      >>>>>
>      >>>>> I agree.
>      >>>>> We had 6RENUM WG sometime ago.
>      >>>>> (It's confusing that "RENUM" BOF has no link to 6RENUM in the datatracker)
>      >>>>
>      >>>>
>      >>>> I think we were a bit naive when we did that work. I think if we want renumbering to be usable, we actually need to account for all the configuration data that contains IPv6 addresses, and I don't think we did that. Dynamically regenerating the entire distributed configuration database whenever our prefix changes is very difficult to get right. We need a solution that's on the same level of difficulty as RA, not a giant distributed database problem.
>      >>>
>      >>>
>      >>> A better solution to this problem is to run both ULA and global space. Internal resources and networks can use ULAs and will never need to be renumbered. Client-facing links can additionally have global addresses configured. Those do need to be renumbered when changing ISPs, but no databases need to be updated.
>      >>
>      >> --------------------------------------------------------------------
>      >> IETF IPv6 working group mailing list
>      >> ipv6@ietf.org<mailto:ipv6@ietf.org> <mailto:ipv6@ietf.org<mailto:ipv6@ietf.org>>
>      >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>      >> --------------------------------------------------------------------
>      >
>      > --------------------------------------------------------------------
>      > IETF IPv6 working group mailing list
>      > ipv6@ietf.org<mailto:ipv6@ietf.org> <mailto:ipv6@ietf.org<mailto:ipv6@ietf.org>>
>      > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>      > --------------------------------------------------------------------
>