Re: [v6ops] I-D Action: draft-buraglio-v6ops-ula-01.txt

otroan@employees.org Mon, 09 May 2022 09:09 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 BD851C159526 for <v6ops@ietfa.amsl.com>; Mon, 9 May 2022 02:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_ZEN_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 tOJtZSKDO3Lg for <v6ops@ietfa.amsl.com>; Mon, 9 May 2022 02:09:14 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::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 9D058C159527 for <v6ops@ietf.org>; Mon, 9 May 2022 02:09:14 -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 E621D4E11A5E; Mon, 9 May 2022 09:09:12 +0000 (UTC)
Received: from smtpclient.apple (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id EAE7E71D1F89; Mon, 9 May 2022 11:09:10 +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: <87aa5bcf-05cf-d170-1efb-d9caa6b48e6c@gmail.com>
Date: Mon, 09 May 2022 11:09:10 +0200
Cc: IPv6 Operations <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C709A752-B22E-48D5-BC5E-5599574DE839@employees.org>
References: <165064500009.9969.16134230557484818454@ietfa.amsl.com> <87aa5bcf-05cf-d170-1efb-d9caa6b48e6c@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/bQG9AvhVNsTXjwpjLGBQLmR6VYs>
Subject: Re: [v6ops] I-D Action: draft-buraglio-v6ops-ula-01.txt
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: Mon, 09 May 2022 09:09:18 -0000

Brian,

I think what you have below is fine.

We also have to take into consideration that both 10.1.0.0/16 and fdee:face:fade::/48 may provide global connectivity.

An application wouldn't know before it tried. So it's important to remember that 6724 only gives an ordered list of SA, DA pairs to try. It does not give an ultimate answer.

O.


> On 9 May 2022, at 01:23, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> Hi,
> 
> Thanks for this draft. I have a few comments (and a tiny nit at the end).
> 
>> The core issue is the stated interpretation from gai.conf that has the following default:
>> #scopev4  <mask> <value>
>> #    Add another rule to the RFC 6724 scope table for IPv4 addresses.
> 
> I'm not sure why this matters. RFC6724 is quite correct to indicate that
> most IPv4 unicast addresses formally have global scope, but auto-config
> and loopback addresses have link-local scope. IPv6 is pretty much the
> same, and in particular ULAs have *global scope* even though they are
> not globally reachable. RFC1918 addresses are identical to ULAs in
> that respect.
> 
> Citing RFC4291 and https://www.rfc-editor.org/rfc/rfc8190.html#section-2.1
> would clarify the difference between global scope (architectural) and
> globally reachable (practical). What we care about here is whether an
> address is globally reachable ("no" for both RFC1918 and ULA, although
> they are both architecturally global). Unfortunately this distinction is
> lacking in the description of gai.conf and, I suspect, in the code of
> Linux getaddrinfo().
> 
> What I think is lacking in the draft is an explanation of how
> getaddrinfo() works and why it matters. Here's a walkthrough that
> I hope will help clarify what I mean:
> 
> Consider an end-user network with the following properties:
> 
> It is dual stacked.
> It uses 10.1.0.0/16 (NATted to the Internet).
> It uses (or wants to use)  fdee:face:fade::/48 for internal IPv6.
> It uses 2001:db8:fade::/48 for external IPv6
> 
> We'll neglect for now whether it has a subnet structure. It shouldn't
> matter.
> 
> Consider a host user.mynet.example.com, a local server printer.mynet.example.com,
> and a remote server www.theirnet.example.com. Assume they have these various
> addresses:
> 
> user.mynet.example.com has:
> 
> 10.1.0.1
> fdee:face:fade::1
> 2001:db8:fade::1
> 
> printer.mynet.example.com has:
> 
> 10.1.0.10  (A record in local DNS)
> fdee:face:fade::a  (AAAA record in local DNS)
> 
> www.theirnet.example.com has:
> 
> 192.0.2.15  (A record in global DNS)
> 2001:db8:cafe::f  (AAAA record in global DNS)
> 
> What do we *want* to happen?
> 
> If user opens a connection to printer, we want it to choose
> SA = fdee:face:fade::1
> DA = fdee:face:fade::a
> 
> If user opens a connection to www, we want it to choose
> SA = 2001:db8:fade::1
> DA = 2001:db8:cafe::f
> 
> Now, if user does a DNS lookup, via getaddrinfo(), the results
> will look like this (in the Python universe):
> 
> For printer:
> 
> (<AddressFamily.AF_INET: 2>, 0, 0, '', ('10.1.0.10', 0))
> (<AddressFamily.AF_INET6: 23>, 0, 0, '', ('fdee:face:fade::a', 0, 0, 0))
> 
> For www:
> 
> (<AddressFamily.AF_INET6: 23>, 0, 0, '', ('2001:db8:cafe::f', 0, 0, 0))
> (<AddressFamily.AF_INET: 2>, 0, 0, '', ('192.0.2.15', 0))
> 
> At this point, consider what RFC6724 says:
> 
>   As a consequence, we intend that implementations of APIs such as
>   getaddrinfo() will use the destination address selection algorithm
>   specified here to sort the list of IPv6 and IPv4 addresses that they
>   return.  Separately, the IPv6 network layer will use the source
>   address selection algorithm when an application or upper layer has
>   not specified a source address.
> 
> Thus, to get the desired behaviour, what matters is destination
> address selection: if we select DA = fdee:face:fade::a, then the
> ULA source address will follow.
> 
> Of course this is a small matter of programming, and most programmers
> just pick the first address. That's why we need the Section 10.6
> mechanism of RFC6724, to insert an appropriate precedence like
>       fdee:face:fade::/48 45 14
> 
> which will prioritize local use of ULAs but will change nothing
> for off-site access.
> 
> At that point in my thinking, I started coding the program that
> I posted yesterday.
> 
> Nit:
> 
> s/gai.cnf/gai.conf/
> 
> Regards
>   Brian
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops