Re: [v6ops] enable-ula.py
otroan@employees.org Fri, 13 May 2022 07:48 UTC
Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1176C15949C for <v6ops@ietfa.amsl.com>; Fri, 13 May 2022 00:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.897
X-Spam-Level:
X-Spam-Status: No, score=-6.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 6Z3Gcljsi2e0 for <v6ops@ietfa.amsl.com>; Fri, 13 May 2022 00:48:03 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 AE865C14792F for <v6ops@ietf.org>; Fri, 13 May 2022 00:48:03 -0700 (PDT)
Received: from astfgl.hanazo.no (ti0389q160-1689.bb.online.no [212.251.183.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 01C984E11AA2; Fri, 13 May 2022 07:48:03 +0000 (UTC)
Received: from smtpclient.apple (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 0E54C725FC5A; Fri, 13 May 2022 09:47:59 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: otroan@employees.org
In-Reply-To: <27ca530a-0897-e615-b990-dd88ec22b2bc@gmail.com>
Date: Fri, 13 May 2022 09:47:58 +0200
Cc: Vasilenko Eduard <vasilenko.eduard@huawei.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <88496827-EDA5-4B19-8FE5-1D40973BB3F8@employees.org>
References: <c52c20ee-772c-3c4c-b87f-e76de7d157a9@gmail.com> <cbe52294-48c7-07f3-9d08-c0a68f56f637@gmail.com> <fd0b026e289b4e11a6636d1942c34315@huawei.com> <f978a0bd5771429381258e81541add98@huawei.com> <73b15db0-ab2b-8f13-0b59-106e177667c7@gmail.com> <03bdac98e61046b790afd433fcb0ffdc@huawei.com> <27ca530a-0897-e615-b990-dd88ec22b2bc@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/uvI5B0XjR9ir8_2mi19brTIh-wU>
Subject: Re: [v6ops] enable-ula.py
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2022 07:48:07 -0000
> In my opinion we are constrained by the socket library and in particular by getaddrinfo(). That is how essentially all software is written - call getaddrinfo() and use the first destination address that it returns. There may be exceptions (such as a browser that implements Happy Eyeballs) but that is the default. So we can only try to change the default behaviour of getaddrinfo(). Am I the only one who finds it ironic that a decades old function prototype should dictate how we standardise the IP networking stack? ;-) Writing a modern IPv6 application that supports firewall traversal, multiprefix-multihoming, ephemeral addresses, addresses of different scope and reachability... perhaps you could do it with the BSD socket API, but I haven't seen many running examples of that. Perhaps MOSH, but that application invents it's own session layer. Best regards, Ole
- [v6ops] enable-ula.py Brian E Carpenter
- Re: [v6ops] enable-ula.py Brian E Carpenter
- Re: [v6ops] enable-ula.py Vasilenko Eduard
- Re: [v6ops] enable-ula.py Vasilenko Eduard
- Re: [v6ops] enable-ula.py Brian E Carpenter
- Re: [v6ops] enable-ula.py Vasilenko Eduard
- Re: [v6ops] enable-ula.py Brian E Carpenter
- Re: [v6ops] enable-ula.py Vasilenko Eduard
- Re: [v6ops] enable-ula.py otroan
- Re: [v6ops] enable-ula.py Philip Homburg
- Re: [v6ops] enable-ula.py Gert Doering
- Re: [v6ops] enable-ula.py Brian E Carpenter
- [v6ops] Unix code & ULA preference [was enable-ul… Brian E Carpenter
- Re: [v6ops] enable-ula.py Philip Homburg
- Re: [v6ops] enable-ula.py Mark Smith
- Re: [v6ops] enable-ula.py Bob Harold