[Snac] Host Requirements for SNAC Use?

Erik Auerswald <auerswal@unix-ag.uni-kl.de> Sun, 20 August 2023 18:24 UTC

Return-Path: <auerswal@unix-ag.uni-kl.de>
X-Original-To: snac@ietfa.amsl.com
Delivered-To: snac@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B25C14F693 for <snac@ietfa.amsl.com>; Sun, 20 Aug 2023 11:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 vg-AiT9obLxc for <snac@ietfa.amsl.com>; Sun, 20 Aug 2023 11:24:01 -0700 (PDT)
Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (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 DC3BCC14F726 for <snac@ietf.org>; Sun, 20 Aug 2023 11:23:59 -0700 (PDT)
Received: from sushi.unix-ag.uni-kl.de (sushi.unix-ag.uni-kl.de [IPv6:2001:638:208:ef34:0:ff:fe00:65]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 37KIO3wl085137 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <snac@ietf.org>; Sun, 20 Aug 2023 20:24:03 +0200
Received: from sushi.unix-ag.uni-kl.de (ip6-localhost [IPv6:::1]) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 37KINuNP018873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Aug 2023 20:23:56 +0200
Received: (from auerswal@localhost) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Submit) id 37KINtuL018872; Sun, 20 Aug 2023 20:23:55 +0200
Date: Sun, 20 Aug 2023 20:23:55 +0200
From: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
To: SNAC List <snac@ietf.org>
Message-ID: <20230820182355.GA4872@unix-ag.uni-kl.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Author: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/snac/SXIt8RGKYyqDsg41Kucg-qVhIj4>
Subject: [Snac] Host Requirements for SNAC Use?
X-BeenThere: snac@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Mailing list for discussing problems relating to the automatic connection of stub networks to existing infrastructure networks. " <snac.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/snac>, <mailto:snac-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/snac/>
List-Post: <mailto:snac@ietf.org>
List-Help: <mailto:snac-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/snac>, <mailto:snac-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Aug 2023 18:24:02 -0000

Hello SNAC WG,

when looking at the basic idea of connecting a stub network via stub
router to an existing link (the AIL), in general a host on the AIL would
need to use the stub router as gateway to reach the stub network.  If this
host already has IPv6 connectivity to the Internet, the stub router may
be added to that list.  Now the host needs to determine which gateway
to use for a given packet.  Both the IETF Proposed Standard RFCs and
existing host implementations allow to choose the wrong gateway, i.e.,
a gateway that does not have a next-hop to deliver the packet.

It seems to me as if some assumptions beyond the most minimal IPv6 host
implementations are required to connect a stub network via stub router
without additional configuration.

RFC 8504 (BCP 220) requires adherence to RFC 4191 which describes three
host types called A, B, and C.  Only type C hosts can reliably choose
the correct gateway.  BCP 220 also recommends (but does not require)
adherence to RFC 8028 for first-hop router selection. Among other
contents, RFC 8028 recommends use of RFC 6724 section 5 rule 5.5.

If the host behaves like a type C host from RFC 4191, and the stub router
advertises the stub prefix(es) as off-link, the host chooses the stub
router to reach the stub network.  If the stub router also uses a low
default router preference there is some chance that the host will not
use it to reach destinations not on the stub network.  Perhaps this
could be added to draft-ietf-snac-simple?

If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule
5.5, and it implements the procedure described in RFC 6724 section 10.6,
and the stub router advertises a ULA prefix as on-link on the AIL, and
the stub network uses ULAs from the same 48-bit global ULA prefix as
advertised by the stub router on the AIL, then the host will use the
stub router to reach the stub network, and will not use it to reach
other destination.  Perhaps this could be added to draft-ietf-snac-simple?

Since a host may decide to send packets for destinations off the stub
network to the stub router, it might be a good idea to require the stub
router to forward such packets to a default router detected on the AIL
(e.g., via RA).

If there is no IPv6 default router on the AIL, the stub router should
make it likely that connecting it does not break IPv4 connectivity to
the Internet.  If the host conforms to RFC 6724, use of ULAs by the stub
router suffices.  This, of course, means that the RFC 6724 preference of
IPv4 over ULA is required for safe stub router use. Perhaps this could
be added to draft-ietf-snac-simple?

Best regards,
Erik
-- 
Inside every large problem is a small problem struggling to get out.
                        -- Hoare's Law of Large Problems