Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update might break current ULA+IPv4 hostnames
Ted Lemon <mellon@fugue.com> Sun, 12 November 2023 15:07 UTC
Return-Path: <mellon@fugue.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 ED755C17C538 for <v6ops@ietfa.amsl.com>; Sun, 12 Nov 2023 07:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.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 9PoUNlBGoHXe for <v6ops@ietfa.amsl.com>; Sun, 12 Nov 2023 07:07:05 -0800 (PST)
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 F2FC7C17C88B for <v6ops@ietf.org>; Sun, 12 Nov 2023 07:07:04 -0800 (PST)
Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-67131800219so23238186d6.3 for <v6ops@ietf.org>; Sun, 12 Nov 2023 07:07:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1699801623; x=1700406423; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hvR3AwSB5MP4DEJfVzI6OJ/N1C/xz3p7jLiur/Auv/s=; b=iqde+L0f6Rdz9sWlTTS/+sQM3sfQlifDzZdEH7GNUVbXAivUCUGlIAwUujUQi2ErPb ka3sOMTIskAB4/ZFNTnibIW8n+xJnsjlp1erE1lxreU9SXTOCRsYDec+WFGWBzq0cNLh WE5wjXs9bvAAaKOYhjFHQHitbG0dbRq+wH8vG+we/DgmXAFEm/ePULMJQVy14LXzXIbS 2c1jvxwOGFxeib5SBex4MShM/nyTNdQbZs6GdAzNxuFnPgGS+9ecYcrj7tV6bWTr8orX PyU3Ke2LM3XGF6KSJVGdwGXzE1cY5OYzfDXEVj5td7FC4NYCvcYIVQ/3UAY+ELdxQ7zS RSEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699801623; x=1700406423; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hvR3AwSB5MP4DEJfVzI6OJ/N1C/xz3p7jLiur/Auv/s=; b=fT5fpOtnnv76s2ols0NYIp1TsbDVP0q+gr+RVWN1gm75Nbe1xi0R+oZ/R+VKFMKF6/ 5xQc9gRwQf75m85WC5H2YqBzoWtVwsDsJK/CmX+9UhU9+ffNiTrKwevtI9VJ6m2l7aHD scc+L4X6TJo5zjyGOjdRlP7T5J1nWf0McHwDUERV3gKjRlpYDCuMuzstZnIZYcdXcST0 GIl49+LbgxmNv3Pr54Si9uUVhzO9+eCRqJpF7re93loJAn0YBXpmtubn09lgbB6+f5Mc ewg0RZggIVZ5X9mQ2RiTT/a28Opk1T6feYTyUqg/47M3xgzyOHZGqiIoLl/rICb5PWxz qmQg==
X-Gm-Message-State: AOJu0YwMKrGp4oK771HxFFI4mghuBjYr8mK9xbnlbnw/OtExSDZLza12 vCcKA2gnc6hNhNbyJkGV6nJvQJ0uHx9cQPlHKpB/BQ==
X-Google-Smtp-Source: AGHT+IFFTmfvmzonRJzbUban1TC9PqJgonE8Fa+BcrRlHPhZYTLlzjTZL9FJRDW4FGKN4QeZ0z3MM28MfSFrqV6y/fs=
X-Received: by 2002:a0c:ee91:0:b0:66d:182a:c083 with SMTP id u17-20020a0cee91000000b0066d182ac083mr4614343qvr.9.1699801623547; Sun, 12 Nov 2023 07:07:03 -0800 (PST)
MIME-Version: 1.0
References: <CAO42Z2ypqtQT85iccM0N59885Zp+o+X-Lx34CjvaAf+JH9go3w@mail.gmail.com> <52796575-6400-4017-BA5C-4746B187B285@employees.org>
In-Reply-To: <52796575-6400-4017-BA5C-4746B187B285@employees.org>
From: Ted Lemon <mellon@fugue.com>
Date: Sun, 12 Nov 2023 15:06:51 +0000
Message-ID: <CAPt1N1kqXY5TfNhyBsFVcezzFzxSrphaQOCdC6_8CiHk8N6=4Q@mail.gmail.com>
To: Ole Trøan <otroan@employees.org>
Cc: IPv6 Ops WG <v6ops@ietf.org>, Mark Smith <markzzzsmith@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f5e80d0609f5e7b9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/UUowhInJQfCMUc0aOHWnSpZx8s4>
Subject: Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update might break current ULA+IPv4 hostnames
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
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, 12 Nov 2023 15:07:06 -0000
I don’t know where this would actually go wrong, though. These ULAs are
only ever seen on the adjacent link. They aren’t routed. They aren’t
discoverable other than on the adjacent link. So if you can see them, you
can reach them. If you are worried about the case where snac numbers the
adjacent link because it’s v4only, that’s also no problem because there’s
no competition between a routable v6 source address and an unrouteable one.
There is the edge case where there is no prefix on the link that is
suitable for use by the snac router, but there is a prefix on link that is
routed. In this case if the operator doesn’t configure RA guard, the
non-routable ULA address could wind up being used as a source address.
However, if the host follows rule 5.5 this won’t happen. And I think this
is a misconfiguration in any case: if you want to control addressing on a
link, I think you have to use RA guard as well as DHCP.
Op zo 12 nov 2023 om 09:37 schreef Ole Trøan <otroan@employees.org>
> Matk,
>
> > On 12 Nov 2023, at 12:19, Mark Smith <markzzzsmith@gmail.com> wrote:
> >
> > Normally, Host A's ULA address should have a path through the local
> > network to Host B's ULA address and vice versa, so Host A and B's ULA
> > addresses should be preferred over Host A and Host B's GUA addresses.
>
> Come to think about it. Wouldn’t RFC6724 also fail in the MPMH case?
>
> Source host A with GUA1+GUA2 (from ISPA AND ISPB)
> And destination host B with GUA3.
>
> 6724 will return the source address with the longest matching prefix to
> GUA3. So only one of these:
>
> {GUA1, GUA3}
> {GUA2, GUA3}
>
> The SA determines exit path, so depending on which ISP is down.
> Communication will fail.
> Redundancy is the whole point of multi-homing…
>
> The other case I am concerned about is the one where within a single
> network multiple routers make up their own ULA and use that to assign
> addresses to directly connected hosts but do not participate in routing. We
> then have multiple disjointed ULA domains within the network. With RFC7078
> and SNAC routers I am not sure if we can avoid that. This would possibly
> have been cleaner with site-locals.
>
> O.
>
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… Nick Buraglio
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… Ole Trøan
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… David Farmer
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… Brian E Carpenter
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… Brian E Carpenter
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… Ted Lemon
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… Mark Smith
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… Ted Lemon
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… Ted Lemon
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… Vasilenko Eduard
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… Ole Trøan
- Re: [v6ops] [IPv6] draft-ietf-6man-rfc6724-update… Ole Troan