IETF Logo Mail Archive

[v6ops] Re: 464XLAT in Multi-interface environments (was: I-D Action: draft-ietf-v6ops-claton-02.txt)

tojens.ietf@gmail.com Tue, 05 November 2024 14:09 UTC

Return-Path: <tojens.ietf@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 DFD5CC270C60 for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2024 06:09:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=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 mEjf-509e3FP for <v6ops@ietfa.amsl.com>; Tue, 5 Nov 2024 06:09:55 -0800 (PST)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E961CC221195 for <v6ops@ietf.org>; Tue, 5 Nov 2024 06:09:49 -0800 (PST)
Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-2e2a97c2681so3956286a91.2 for <v6ops@ietf.org>; Tue, 05 Nov 2024 06:09:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730815789; x=1731420589; darn=ietf.org; h=thread-index:content-language:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3WXz4MTVhs/UJrmITqKrPUYMKkUgilJ3Lb6w7372rb4=; b=mW/TZD3LDDx2g8xxwMggedqqjMGa/422P6j7MvDZ1M9CLoFzbDe1DifzSIo8qfUf1+ IEi5L9Y/F9e/+hNFoQp8MlKSdnqkJI2xQkz7Frofub8z4jGIIgCqvZiDY2EnbdRPgrx3 bGgkX4aH7aZFpG4cQrUdmomwcvTot/aNyDH/kmD8EggnnfDcnIkYk8EX3yvAKcgr0Gii 3voJM86wzm5o/THEq0bVa0PCUufh/iQ9CHIHNoof1pRN5Ke3w9GRMir0iJr6ENQvkoty amii85tRy8z259ANPriiYuT9lbXNqkNBl5YrBwwJLgy1fMqmS/XtgihQXTKcrGXs8hWg KVNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730815789; x=1731420589; h=thread-index:content-language:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3WXz4MTVhs/UJrmITqKrPUYMKkUgilJ3Lb6w7372rb4=; b=Iy9NWRHP7OYWMWnA5f38RcrLlHjmtnV3tcI+YO6mCCnbvvCgVdaacNUPclYNZ0nI2a U1fvWhZ+z2jTfZDtwq/A/Ajhzgc1JHose1yLuz+O9nd5yZjsC/eBtdePe0gBXFN+k4+V f4vG1730hw9l4jsbfvfeJTKCidE18SsiQ4ex6X8dHQIAKymNiIYB8ihETFtDNCc7QNml Ih3okaRRz4nNKJyk4wGLJXWve+FfYZD/pE76ajtD3s0hrCo8hawOumuRvMoBvyHwVykD ZHcP2fCbq68Tgxa4BvWJgYwkz0Dweej2/83QoyWNmYI6orQiqEyyKkAS2z9iIb5KuRE/ 90Sg==
X-Gm-Message-State: AOJu0Ywgaizy3q6F6eg9IH3X33X8ZWuhW88Q/TYWQHjIN2QDNA0CWDYX 9BzxYuq5IKfhtSRmPu4CJLfriV1rSzLqi9vjeOcIGl0vV+8SqM62HKGx9H59
X-Google-Smtp-Source: AGHT+IHzGeFM8Lut7WWpwWRFfoLflR1yMSoYG68E4knyQzGuruiuelRp6GhE2WqiGxvhOnFJVBZ5hw==
X-Received: by 2002:a17:90b:4a8c:b0:2e2:acd7:1df0 with SMTP id 98e67ed59e1d1-2e92cf85afamr22887567a91.41.1730815788960; Tue, 05 Nov 2024 06:09:48 -0800 (PST)
Received: from tojensdell ([2001:67c:370:128:6cf4:5841:46e5:5070]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-211057d5331sm77338055ad.273.2024.11.05.06.09.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Nov 2024 06:09:48 -0800 (PST)
From: tojens.ietf@gmail.com
To: 'Jen Linkova' <furry13@gmail.com>, 'Philipp Tiesel' <philipp@tiesel.net>
References: <172954645439.2070596.1455805667911500824@dt-datatracker-78dc5ccf94-w8wgc> <5009F747-6459-4F9F-BF83-C1F3437B5CC4@tiesel.net> <CAFU7BATO7PB5igFi566k01puf0WmSFFvpajFhRi7x_eh6neFmA@mail.gmail.com> <50DAE53B-06D5-4331-9C86-2D1B4A80B9BF@tiesel.net> <CAFU7BAQesaEcH9wG3oggAgjTXJxs24MFA4b5EGKN-OvL3XRrTg@mail.gmail.com>
In-Reply-To: <CAFU7BAQesaEcH9wG3oggAgjTXJxs24MFA4b5EGKN-OvL3XRrTg@mail.gmail.com>
Date: Tue, 05 Nov 2024 14:09:48 -0000
Message-ID: <018a01db2f8c$60ea8230$22bf8690$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_018B_01DB2F8C.60EA8230"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQFMJlrcQSNsThydqhPn2XcsCvh3NAEaKJMiAhc/GOwCW5+VowJCqrjps4hJx4A=
Message-ID-Hash: X6ZLE53LYRYMDGY5UFKJREMVHN7CAZGB
X-Message-ID-Hash: X6ZLE53LYRYMDGY5UFKJREMVHN7CAZGB
X-MailFrom: tojens.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: 'V6 Ops List' <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [v6ops] Re: 464XLAT in Multi-interface environments (was: I-D Action: draft-ietf-v6ops-claton-02.txt)
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/kRgZZ93DTmR8r5OKgMNqysHVxAM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

> I'd love to hear what the implementers think. I assumed - apparently incorrect - that it's easier to use different addresses.

 

You are correct – I have a preference for unique source addresses per CLAT instance for design and runtime simplicity. That’s not to say moving this to a MAY is problematic, unless this is going to impact how PLAT implementors interop with CLAT instances (I cannot see why it would).

 

> So yes, maybe only addresses from PIOs received together with PREF64 shall be used...

 

I think this is reasonable, but it would be interesting to hear from PLAT implementors if this would break current implementations.

 

> However if there are multiple prefixes [in other mechanisms], it's going to be a disaster - another argument in favour of not using 7050 (This might need to be mentioned in…

 

Yes, this is worth mentioning as an operational consideration (no normatives, just notice to deployers where foot-guns are hidden). TBH, I would prefer to all-up recommend not having any case outside of 2.1, but I realize I’m living in the clouds.

 

Thanks,

Tommy

v2.46.0 | Report a Bug | By Email | System Status