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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 08 May 2022 23:23 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 A77B8C14F749 for <v6ops@ietfa.amsl.com>; Sun, 8 May 2022 16:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.952
X-Spam-Level:
X-Spam-Status: No, score=-3.952 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, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cC5J1sm_Wuw2 for <v6ops@ietfa.amsl.com>; Sun, 8 May 2022 16:23:18 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 EA250C157B3F for <v6ops@ietf.org>; Sun, 8 May 2022 16:23:18 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id v10so10591811pgl.11 for <v6ops@ietf.org>; Sun, 08 May 2022 16:23:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=6LySXE6pOSVz88s4LpiodLOOgDoQTA0vs2RHT3qlNe4=; b=W4Ekv9SLgJ1YdT3xhklqSEdAUsoRj7i4ZYxP7nkbyQjmz8ANvEe+8h9Kt68PGfJJCY uP7E9+hC7S24eYVOl1juFFJ2KA2J8dlLu9mz5WqGqKV0huWSeQdtKaWdxBNfYhTl1kHN TEHAqjTvHYC/h/74rDKo+3APBEnw+vJBOYyLJy80I0rF2H7fA0epPkAfxtyrfwcBRSWx N7W104fMv4g7+t98//WIzM9rmadS4m0IxjKfm81aYBbwOpDnhUwGLrUP1X7eVelgxZUN xK3ctlzG42P6euPcR2qvGIR7+xOIDC5sOiyizI/CGUKG0j/r9Yl6k5/WmrU12YEDfxCW TcQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6LySXE6pOSVz88s4LpiodLOOgDoQTA0vs2RHT3qlNe4=; b=3oMY5ak4kYhjlGNXI6oCSft+Dgj93UPugWGlbMGug7oHpoiQxFyNId5ckUMZOIV/PS +QD6SJAGcwpJ+bltPICdmmRMs2azibabpcWpNK/ofP3BeCM8j+7oROsz3oqmFUiYU1le SLoahhA0fUcwSa/+7bM5SBNgpkrc6wY6RpuPA0pX0HdmQ8GefdQvfpdziWCBzMu/BWgs rwC5z3RQVGhzVbNtUZfSUwlHEVHiR3uQsT6N9sU/iDHDgxaRyacgG1VxrecJd1JHvI44 JtesT+2HrdlNrOaLMg3TFoOzpPvufABPNdiwN/WGImTH/o56mnEC8STvnVkHKOpPWhYN I1Ug==
X-Gm-Message-State: AOAM531gJW2NW3vXjmGQ2t3YzfWC7VFOKgWQMU2XZPR6d5Dtqg2syzgF 0vAsBmntFn14cINtjPoqox3hX3pHs3sVxg==
X-Google-Smtp-Source: ABdhPJwZQk/VSRe48lY2yTnUbkf9fd0+s+Mfsdr1sKD2eexmmyjLqbAK/0WuYlF85MqMnI+ewnlmVw==
X-Received: by 2002:a62:1611:0:b0:50a:41c5:e6fc with SMTP id 17-20020a621611000000b0050a41c5e6fcmr13625500pfw.35.1652052198159; Sun, 08 May 2022 16:23:18 -0700 (PDT)
Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id ba1-20020a170902720100b0015e8d4eb294sm5608031plb.222.2022.05.08.16.23.16 for <v6ops@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 May 2022 16:23:17 -0700 (PDT)
To: IPv6 Operations <v6ops@ietf.org>
References: <165064500009.9969.16134230557484818454@ietfa.amsl.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <87aa5bcf-05cf-d170-1efb-d9caa6b48e6c@gmail.com>
Date: Mon, 09 May 2022 11:23:13 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <165064500009.9969.16134230557484818454@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/yoV0Z0iMK84-fK4P1u-czvJBaVs>
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: Sun, 08 May 2022 23:23:22 -0000

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