[v6ops] Re: [EXTERNAL] Re: ##freemail## Re: Re: New Version Notification for draft-link-v6ops-claton-03.txt

Tommy Jensen <Jensen.Thomas@microsoft.com> Wed, 12 June 2024 21:09 UTC

Return-Path: <Jensen.Thomas@microsoft.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 C07E2C09E1D0 for <v6ops@ietfa.amsl.com>; Wed, 12 Jun 2024 14:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=microsoft.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 wjcg1-m62dbo for <v6ops@ietfa.amsl.com>; Wed, 12 Jun 2024 14:09:27 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on2090.outbound.protection.outlook.com [40.107.65.90]) (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 13849C1F58A5 for <v6ops@ietf.org>; Wed, 12 Jun 2024 14:09:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ok1Sa693T+Y3M3ZizWJYDVytD6XLm/BZJBw/OrfXvPyoi+f+fTqe1DteEGdCP0tLLlui4KgNwtK0PxzT7OzX25uW2AwtvUYIQlp1Sg5DdKVW8rlIslJU4IZBls3vHc46BGzSbWdxGrR48OVAza3ogTcQVukE479wlf71vhlNFYQLngXYbAZg3ZLMfVwVYNAoopdqRCajO9u7Zi8UJr4LazHrOwmf3ZN4D8ejPX6X08AnGMoVAiMaJHBQCBGc91dwOsrB8tAB5EDFgPA4AVbcNA+JDe1m7v+sym2NHVmEFo3SxsfJBKyQSFbUNkkReVVMWt15QKd4sZugns9oc01Ydw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6IB6xnSJwa6zUnoAGntyGpgvEVJA2PTgMz645577mWE=; b=OHVAe5bp4ESquaftokMfRcM9a6R78XQtsnqphmLnQ18SqCs4NeIfRqQEPPVpKLdd/MEH6aXwugEwhqF9+5c7II13JxSUkPmnVuRgCfR0gfXTdnGrRJAgzSak7uZ0NSUBD7RzVn/kUTesm/O4y3/fTQi3HZ3zcIBiMFjSEWEIK+EDUeVwEcvbH1bGvHF49TE5BvxiHyujgyVrXFxewI8SpD+VJLnI0EkcLxkBnxN4pplzgeyoHk9Fth6S4xcj5L35rZzxmZ47RzsTR/tJPlQP1e7AYdcoGTF8h12GDJvS7ETswO9fzglis3SsAmzpOv3aLxsCdzMdq2UZAP2hwtg1BQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6IB6xnSJwa6zUnoAGntyGpgvEVJA2PTgMz645577mWE=; b=Nxn44OvJ6207TNZMwTnutv8cgB0l1+YHyz7qPO9eMkYrzOqE62BYOO9maC6Tr4SRuZftwwSTmK5GDniaXpBAe55gY+r0yWTNbb835TCH4lsLzu3t+7Cqmmd+H87/ZfxqyNjFy6BeGnDE5ysFtR8RrHA6LCxf1lutkhNlzFF8hT0=
Received: from PH0PR00MB1352.namprd00.prod.outlook.com (2603:10b6:510:10f::10) by PH0PR00MB1393.namprd00.prod.outlook.com (2603:10b6:510:d2::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7688.0; Wed, 12 Jun 2024 21:09:20 +0000
Received: from PH0PR00MB1352.namprd00.prod.outlook.com ([fe80::dd8f:8395:431d:f72c]) by PH0PR00MB1352.namprd00.prod.outlook.com ([fe80::dd8f:8395:431d:f72c%6]) with mapi id 15.20.7715.000; Wed, 12 Jun 2024 21:09:20 +0000
From: Tommy Jensen <Jensen.Thomas@microsoft.com>
To: "Kawashima Masanobu(川島 正伸)" <kawashimam=40nec.com@dmarc.ietf.org>, Jen Linkova <furry13@gmail.com>
Thread-Topic: [EXTERNAL] [v6ops] Re: ##freemail## Re: Re: New Version Notification for draft-link-v6ops-claton-03.txt
Thread-Index: AQHavLIaT0aYmAiixEi801WSrCQ7BrHEnTFM
Date: Wed, 12 Jun 2024 21:09:20 +0000
Message-ID: <PH0PR00MB1352FCDE33ABCDECE23E59A5FAC02@PH0PR00MB1352.namprd00.prod.outlook.com>
References: <171656605305.48682.1088678194134276372@ietfa.amsl.com> <CAFU7BAQGyuEJ1iLSEyKQE__kmihV_TgEOmPyepdt08yEFTuh1Q@mail.gmail.com> <C5F7334E-7146-419D-9701-3C3E81EF3F1F@consulintel.es> <CAFU7BASYWz6Op3xo5kkcoJoLgFCFwgivefeMZ9hm5b3P8PZ-BA@mail.gmail.com> <TYVPR01MB1075098996E154F057B19DE91D2C02@TYVPR01MB10750.jpnprd01.prod.outlook.com> <CAFU7BAQUwBy8a7ueDja0XKkjg88WXupXmQ3kQ6aHgy0ffPcGqw@mail.gmail.com> <TYVPR01MB1075057CB2A901A0E2DCA3D38D2C02@TYVPR01MB10750.jpnprd01.prod.outlook.com>
In-Reply-To: <TYVPR01MB1075057CB2A901A0E2DCA3D38D2C02@TYVPR01MB10750.jpnprd01.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2024-06-12T21:09:21.364Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR00MB1352:EE_|PH0PR00MB1393:EE_
x-ms-office365-filtering-correlation-id: cb0b2bcb-1847-4c88-df40-08dc8b23edb0
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230034|376008|1800799018|366010|38070700012;
x-microsoft-antispam-message-info: JQq6g8yTlk12tlvEX37RGpIIHdpE12kzOQEgbBKGptYerKrWwOdcat09X3OoWrcnsPSlvlRKW/I9WiZSi84EB7SG0tj+ehZnzFnz1XedP2zM8SbHGM8ZT43DN3aKn23qr8W9kfz57uD/iyKSy+YTdD9JKC/e4b/ytwRjKRgKHSYk/ZJowSpsjJZIkFoivnj3bp7+eoNgBPYulaGahRweNBCe/6hBwBahjAG697OW9hGz8+HSjXmZagU8H7ilut/3mJXC9ScLJDmxMcsmT6rzR6J7fSgfzCri8HWR48JZXVmMZRk78tMeeePxMYdw/mNtx7ddhzpizKyLPdUnDCkcv0SAIw7IS1mGdjRmUCPhXEqDLVsovK9gHRa1OXbJx3n1Ad8mPhGnTzwKsPp6parrE34QpLT3wVumOh+GMrmk4p2hR+eJCJb1WJ2XYJwZQ69/9rqqyQmqnwKm3prQF0KgO55Yg1yYQcGhPQ18q9Kp0aVC4JN/M1rvOSwDeVHCS7AVex9FCOHn+akKg6+gAMr+jLFEygyvitzHfDZihh7i8z7JoIcQQTGU2LoB7oSYdsJIvVpZ7Ni8qcEfxUtUy7PQrHzhCehOSFciEHrQOoYm/YVsK5PA8pl/yRJT+3fPBMKoFDnxwnizPL9OuSn+PO4NNvMjUdJWAd6LkBdgoM3AiXL8PH1yuApuNFJjRTjvHWh9WEqlvYFr3jibE34yFRtpmXsnAx1oS9NylP6yJsjkWZ4xOGMyyUFeopgJEkidMHgMK1lBCO7ZXmbR1Cd1mvnjtqNiIWy+vqM0qHQif9kr4o2hDIyX4CIhs+/vYIlthfA3qDlG0TJoXshnYcfWTD2lJZr1+qH/ZBtDjjGixHTk0hHDP0MBaxfiNCYQS7Iw4+OL1ZL3FuSkbuTElRAhZYBuBD3ZKkwxFiT4SnuJr6STrzt78yZ7UqAUpdH5+quDu3T9nMLzTbNYlwcwbdoLGMPhVjZBTaaWTm5a8CKrJmLFWk2kkZI6odYmrSh8wz+f2gr0xNf5dLQ5Zeewiiu95Rm/kMcMvyz/ClvE81C8KhKyV5hBPMfNfDpD6zXc45CX6upou5KkBhqNoz7hwrtA6sgo7pX8dNIaeyvctGxCLcUK2FMW4JjUUH+UjNG5PRw5KMzsPdkrn2c7poNTKPdfPIXIUF/RYAaGwIQDKjR+E5RXOZgbZ/3dVAp8BUwDVunGVL6vhNTatbJXa/YFXdm8ENEXqhmJ5FZdNuUHtYqEy3SLpVFtzoO0yrf1hvOustB9P/4aalc85x6N3pXrZhDKcAUpEiuBvG7pCVAvobUp3TQ/PzfKSdZm1oUIR7dbjTse15jG
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR00MB1352.namprd00.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230034)(376008)(1800799018)(366010)(38070700012);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: i72oWB01C3OcS723+aNpjupHdvld17UYxRjXQ5KNw9YZpDM4v9flP7uKRX4MsB44gG2cHUM+GD4Q1G/ZPydZT75qrBmJk+7QEV1ezj/WMqrvE9Op4KqhDIWwiYdKAT6UctBxlW9pwseywEEMi/exAerLkCPnaSeeZOSVu3RrP7rnsjCXM6q6K5jBIniUzVbp03GJ/oS+Q6xw+vVzSV4x/S7FZfa9PlwXtMOBOZKr/Z3aEWiP/HlKLue5kc+09U+ryrN97UPIvNNse/Hb9BDX1GkSx3PqZpkcAg0IY6VeD/sUF31JPx2bMxzXc6jzVs+vuOmY6wofa8Btv6reZwJ3xcECIyyYmQk7EsG9LPgj3tD2GpwB7k4N6UQl4IAoPeGqAmHL+4m/iVNtFgau+cp60wevnKgTn+g6IvqwaLm8knWNx4sKReVH/V/TOQB5eODbd001DBwhIKyuyzQ+Ia8Q3pWJ7XPeA5VLc14gf/Uw1Cj6KV1A6Fo6YvDBmHfrYCiW+QutHCOQVfOhnWp+yk2pq6As1rUzwNH6/DxeXB6Ur5AAjvCwtnoTA0CatK/NtMBz51CuL/vqhH5JqIBwQlMCLnD/mpSh+UZ5Pc5EoFK3lJXrJQ4vNKXEeCuP25W4tCx74k5NQddgph0ZehQHiXHNoSxbfyNtJ5lylTO92+iGbeNxJFMzdZ+vwV4HWahgHWNglPI54Mfyw+nm6Xvjl6gmMUDXDsDvqTsOjcm/Al53XL5X1Tjqsi0vbUu7DLuFME4FKh8EN2gH1Tb45mIhvCvJHZjm+zOUcuvjboPQiim8OeKQit1YsRBP/e9oZqmyA5+tSxiG5uqAN5HAWn9CWp72v+8riauBPcjysLHOkV9KEXUo/cZhxKOzBDL3S+GuqKCCtpHm28O4QyA9avjTAYS3Ogk5c0a3Y5TCLMsFFqhVwRmHtgYvUBRDw3aMO61m4T5EqPQxl+nux5ynYtFZo9QcZUVzsLnIWwXYXaBNtOVZB021NZOzprCGF3kUOklcSPHGnf1X9Rj1+vPf0sAJjs7n5n7sVgMNUwQ5pZQa1KsZK+ZkNeOp4gB6N0K2izQ6JKfA/vbLoyJGxyJzKi5kAiQS68y/rJp1rJb3YCrYoprl+jUMm7oHWhx8+tJPQCR8S/CEvk3kiNpZ/7CwYuIfGvqE1rZc6ImEMqJcxsP/KgT5TGna4ojK0bkd3JTFLAHP6M0x6kDLQ6rJoUyUCHWYjPS5jLTu3EbCt/emExNWHFr8DbuPRwiTbNFkALlDKOUSH4j/+b2vlCljCjT+HguAfAmjrO1RzbKU6lFE4FmHnl8aT0yFyZQdvij9fSiPnruXW+UNN4ihSMTrydltigSLs5gc0l16qFdkqKIBDzhIeS37pK40N/DevBwZ67MBe2kB+2kCZxl1N2ktknTZ405KODhjfuk5BhIu2ekdnMvbZ2RlD5CP6BXAzSbbye6gGbeFt12GCb51KtZyzvSkC3q3G61GrIiVMCdxl8pqgrCAtcd+IewEyc0zKs0q40q+hy20Dsq8h7jPTGQeA3D0Bg0QEAx7vhX8tPcmq8P3uFTROdZoq7SO7nJUl9074lno1K5scmZlxR+ogGr6FSxfR/YHMTqUYsAPJQS8rVutBdqZ1JwUB70EbKypMumm6wQ7Q/6kq8EC
Content-Type: multipart/alternative; boundary="_000_PH0PR00MB1352FCDE33ABCDECE23E59A5FAC02PH0PR00MB1352namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR00MB1352.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cb0b2bcb-1847-4c88-df40-08dc8b23edb0
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2024 21:09:20.7497 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Y/iEdca0wZDm+A3AY+ITHYA1n/hJrdbG8EOe0aGNqHUo7ciT9rvMaNTN/EA9C2gZ0VjXn2RVmMkcjk+/cMg6GA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR00MB1393
Message-ID-Hash: SESOIDRA5CSCUZ342LFAB3CF2OMITDN7
X-Message-ID-Hash: SESOIDRA5CSCUZ342LFAB3CF2OMITDN7
X-MailFrom: Jensen.Thomas@microsoft.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: "jordi.palet@consulintel.es" <jordi.palet=40consulintel.es@dmarc.ietf.org>, V6 Ops List <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: [EXTERNAL] Re: ##freemail## Re: Re: New Version Notification for draft-link-v6ops-claton-03.txt
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/4mx4hAG3PudEVP45HCgqV4a_Uco>
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>

Hello Masanobu-さん,

>> Maybe we can say "MUST disable CLAT unless explicitly configured not to do so"?
>> Would that address your case?
>
>Yes, that sentence is fine to me. :-)
>At least we allow some exceptions.

I would like to understand how this would work in practice. There are two things that both need to occur for a CLAT node to end up preferring 464XLAT over IPv4 direct connectivity:

(1)  The CE does not know that it needs to send out DHCP Option 108 for some reason, and
(2)  The CLAT node admin (client OS or a CE providing CLAT downstream) needs to specifically opt into it

Point (2) essentially restricts this to enterprises because consumers aren't going to go in and modify CLAT settings at any meaningful rate, and they should not be doing this by default.

I'm confused about when (1) applies in a managed environment. Can you please help me understand when the CE will not know that it needs to respond to send DHCP Option 108? I do not want to encourage deployments to avoid using Option 108 when it would otherwise work. The text ought to include considerations that explain when it is appropriate for implementors to provide such configuration (it ought to be of a limited scope).

Thanks,
Tommy

________________________________
From: Kawashima Masanobu(川島 正伸) <kawashimam=40nec.com@dmarc.ietf.org>
Sent: Wednesday, June 12, 2024 3:17 AM
To: Jen Linkova <furry13@gmail.com>
Cc: jordi.palet@consulintel.es <jordi.palet=40consulintel.es@dmarc.ietf.org>; V6 Ops List <v6ops@ietf.org>
Subject: [EXTERNAL] [v6ops] Re: ##freemail## Re: Re: New Version Notification for draft-link-v6ops-claton-03.txt

[You don't often get email from kawashimam=40nec.com@dmarc.ietf.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hi Jen,

Thank you for your reply.
Please see my comments inline below.

> > 2. CLAT enable/disable : SHOULD or MUST I'd prefer SHOULD rather than
> > MUST.
> > There is other use case where we prefer CLAT than native IPv4.
> > For example, in Japan, IPv4aaS is faster than IPv4 PPPoE.
> > Therefore, we need to allow some exceptions.
>
> A question: so the device *does* have a native IPv4 address, but you do not want
> it to be used?

I don't want to use native IPv4 in that situation.

> Can you use Option 108 to disable IPv4?

Yes, we can use Option 108, but the problem is that we don't know
the upstream is IPv4 PPPoE or IPv4aaS. CE router only knows it.
If CE router support Option 108, problem will be solved.

> Maybe we can say "MUST disable CLAT unless explicitly configured not to do so"?
> Would that address your case?

Yes, that sentence is fine to me. :-)
At least we allow some exceptions.

> > 3. Coexistance of CLAT enabled CE router and CLAT enabled hosts
> >
> > IMHO, we need to add another requirement for the coexistance of CLAT
> > enabled CE router and CLAT enabled hosts.
> >
> > 464XLAT-7:  If CLAT is enabled on CE Router, The IPv6 Transition CE
> > Router SHOULD implement [RFC8781] ("Discovering PREF64 in Router
> > Advertisements") and implement [RFC8925] ("IPv6-Only Preferred Option
> > for DHCPv4") in order to coexist with "IPv6-Only Capable Endpoints"
> > for IPv6-Mostly Networks.
> >
> > The difference between 464XLAT-4(NEW TEXT) and 464XLAT-7,
> > 464XLAT-4(NEW TEXT) is for discovering PREF64, whereas 464XLAT-7 is
> > for CLAT capable hosts configuration.
> > We might be able to merge 464XLAT-4(NEW TEXT) and 464XLAT-7, though.
>
> That's a very good point.
> I totally agree that CE routers shall be able to send PREF64 and recognize/honour
> Option 108.
> How about:
>
> 464XLAT-7: If the IPv6 Transition CE Router performs CLAT functions it SHOULD
> also  include the PLAT prefix  in Router Advertisements
> (RFC8781) sent via the LAN interfaces. If the IPv6 Transition CE Router acts as a
> DHCP server it SHOULD enable DHCP Option 108
> (RFC8925) processing. The router SHOULD have a configuration knob to disable
> DHCP Option 108 processing.

This is fine to me. Thanks.

Regards,
Masanobu

========================
 NEC Platforms, Ltd.
 KAWASHIMA Masanobu
 kawashimam@nec.com
 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.necplatforms.co.jp%2Fen%2F&data=05%7C02%7CJensen.Thomas%40microsoft.com%7Ccf8c4568532c466d27d108dc8ac93864%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638537844100594728%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=c2shtAWq2yZL%2FKjsjFZgl2rXB4ESUsxNd9NhiCeMkc8%3D&reserved=0<https://www.necplatforms.co.jp/en/>
========================



> -----Original Message-----
> From: Jen Linkova <furry13@gmail.com>
> Sent: Wednesday, June 12, 2024 6:30 PM
> To: Kawashima Masanobu(川島 正伸) <kawashimam@nec.com>
> Cc: jordi.palet@consulintel.es <jordi.palet=40consulintel.es@dmarc.ietf.org>;
> V6 Ops List <v6ops@ietf.org>
> Subject: ##freemail## Re: [v6ops] Re: New Version Notification for
> draft-link-v6ops-claton-03.txt
>
> Masanobu-さん
>
> Thank you very much for your comments.
>
> On Wed, Jun 12, 2024 at 6:56 PM Kawashima Masanobu(川島 正伸)
> <kawashimam@nec.com> wrote:
> > Please see my comments bellow.
> >
> > 1. The title
> > The draft title "464 Customer-side Translator (CLAT): Node Recommendations"
> > should be "464XLAT Customer-side Translator (CLAT): Node
> Recommendations".
>
> ;) oops, fixed.
>
> > 2. CLAT enable/disable : SHOULD or MUST I'd prefer SHOULD rather than
> > MUST.
> > There is other use case where we prefer CLAT than native IPv4.
> > For example, in Japan, IPv4aaS is faster than IPv4 PPPoE.
> > Therefore, we need to allow some exceptions.
>
> A question: so the device *does* have a native IPv4 address, but you do not want
> it to be used?
> Can you use Option 108 to disable IPv4?
> Maybe we can say "MUST disable CLAT unless explicitly configured not to do so"?
> Would that address your case?
>
> > 3. Coexistance of CLAT enabled CE router and CLAT enabled hosts
> >
> > IMHO, we need to add another requirement for the coexistance of CLAT
> > enabled CE router and CLAT enabled hosts.
> >
> > 464XLAT-7:  If CLAT is enabled on CE Router, The IPv6 Transition CE
> > Router SHOULD implement [RFC8781] ("Discovering PREF64 in Router
> > Advertisements") and implement [RFC8925] ("IPv6-Only Preferred Option
> > for DHCPv4") in order to coexist with "IPv6-Only Capable Endpoints"
> > for IPv6-Mostly Networks.
> >
> > The difference between 464XLAT-4(NEW TEXT) and 464XLAT-7,
> > 464XLAT-4(NEW TEXT) is for discovering PREF64, whereas 464XLAT-7 is
> > for CLAT capable hosts configuration.
> > We might be able to merge 464XLAT-4(NEW TEXT) and 464XLAT-7, though.
>
> That's a very good point.
> I totally agree that CE routers shall be able to send PREF64 and recognize/honour
> Option 108.
> How about:
>
> 464XLAT-7: If the IPv6 Transition CE Router performs CLAT functions it SHOULD
> also  include the PLAT prefix  in Router Advertisements
> (RFC8781) sent via the LAN interfaces. If the IPv6 Transition CE Router acts as a
> DHCP server it SHOULD enable DHCP Option 108
> (RFC8925) processing. The router SHOULD have a configuration knob to disable
> DHCP Option 108 processing.
>
> >
> > -----Original Message-----
> > From: Jen Linkova <furry13@gmail.com>
> > Sent: Tuesday, June 11, 2024 6:03 AM
> > To: jordi.palet@consulintel.es
> > <jordi.palet=40consulintel.es@dmarc.ietf.org>
> > Cc: V6 Ops List <v6ops@ietf.org>
> > Subject: [v6ops] Re: New Version Notification for
> > draft-link-v6ops-claton-03.txt
> >
> > Hi Jordi,
> >
> > Thank you very much for your review and comments.
> >
> > On Sat, May 25, 2024 at 8:44 PM jordi.palet@consulintel.es
> <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:
> >
> > > 0) Abstract
> > >    464XLAT ([RFC6877]) defines an architecture for providing IPv4
> > >    connectivity across an IPv6-only network.  The solution contains two
> > >    key elements: provider-side translator (PLAT) and customer-side
> > >    translator (CLAT).  This document provides recommendations on when a
> > >    node shall enable or disable CLAT.
> > > I will say:
> > >
> > >    464XLAT ([RFC6877]) defines an architecture for providing IPv4
> > >    connectivity across an IPv6-only network.  The solution contains two
> > >    key elements: provider-side translator (PLAT) and customer-side
> > >    translator (CLAT), and optionally a DNS64.  This document provides
> recommendations on when a
> > >    node shall enable or disable CLAT.
> >
> > I do hope that we shall be able to get rid of DNS64 soon and this draft might
> outlive DNS64.
> > How strongly do you feel about mentioning DNS64 here? As it’s a rather
> optional element, I have a slight preference to not overload the text..
> >
> >
> > > 1) Intro
> > >    464XLAT is widely deployed in 3GPP networks (as described in
> > >    Section 4.2 of [RFC6877]) where a mobile phone performs the CLAT
> > >    function, providing a private IPv4 address and IPv4 default route for
> > >    the applications and tethered devices.  Enabling 464XLAT allowed
> > >    mobile operators to migrate User Equipment (UE) devices (also known
> > >    as mobile phones) to IPv6-only mode, where those devices are only
> > >    assigned IPv6 addresses.
> > > I will not use migrate (in general in any IETF IPv6 transition document), in
> many languages the “translation” or “reading” has the implication to fully disable
> IPv4, which is not the case (you migrate from Windows 10 to Windows 11, because
> Windows 10 is not longer running, but you transition from IPv4 to IPv6, because
> they still coexist). We keep confusing people when we use migration. One of the
> “IPv4” I think can be removed to make it shorter. I will say that the common case
> is mobile phone or CE (mobile router, a router with a 3GPP interface) Also, the IPv6
> addresses are assigned on the WAN, just for clarity. So, I will say:
> > >
> > >    464XLAT is widely deployed in 3GPP networks (as described in
> > >    Section 4.2 of [RFC6877]) where a mobile phone performs the CLAT
> > >    function, providing a private IPv4 address and the default route for
> > >    the applications and tethered devices.  Enabling 464XLAT allowed
> > >    mobile operators to transition User Equipment (UE) devices (typically
> > >    mobile phones and CEs) to IPv6-only mode, where those devices, in the
> WAN interface, are only
> > >    assigned IPv6 addresses, however still providing IPv4aaS (IPv4 as a
> Service) inside the device.
> >
> > How about this:
> >
> > “464XLAT is widely deployed in 3GPP networks (as described in Section
> > 4.2 of  RFC6877) where User Equipment (UE) devices (such as mobile
> > phones and CE routers) perform the CLAT function, providing a private
> > IPv4 address and default route for the applications and tethered devices.
> Enabling 464XLAT allowed mobile operators to transition UE devices (also known
> as mobile phones) to IPv6-only mode, where those devices are only assigned IPv6
> addresses on their WAN interfaces.”
> >
> >
> > I’m dropping IPv4aaS as the first sentence does say that applications and
> tethered devices get IPv4.
> >
> >
> > > I think the only form of PLAT is NAT64, so
> > >         Even if the network provides PLAT in the form of NAT64 make
> > > it just shorter such as:
> > >         Even if the network provides PLAT (NAT64)
> >
> > I’ve realized that it’s the first time NAT64 is mentioned, so it would make sense
> to add a reference here. So to make it more readable I’d suggest keeping “in the
> form”:
> >
> > “Even if the network provides PLAT in the form of NAT64 (RFC6146).."
> >
> > > It can be other kind of devices, so instead of:
> > >    hosts like desktops and laptops still need the
> > >    network to provide IPv4 addresses, as otherwise IPv4-only
> > >    applications fail
> > > use:
> > >    hosts like desktops, laptops or other devices still need the
> > >    network to provide IPv4 addresses, as otherwise IPv4-only
> > >    applications and devices will fail
> >
> > How about:
> > “hosts (desktops, laptops etc) still needed the network…”
> >
> > > I think is still important to keep mentioning IPv4aaS so people don’t believe
> they loose IPv4:
> > >    it becomes possible to
> > >    migrate those devices to IPv6-only mode
> > > So:
> > >
> > >    it becomes possible to
> > >    transition those devices to IPv6-only mode with IPv4aaS
> >
> > > Could be not just public Wi-Fi, so instead of:
> > >    Networks such as public Wi-
> > >    Fi, enterprise networks
> > > use:
> > >    Networks such as Wi-Fi hotspots, enterprise networks
> > >
> >
> > Thanks, we'll update the text.
> >
> > > Then, instead ensure that is well understood that the CLAT can be also in a CE:
> > >    *  CLAT is performed by the host itself.
> > > So:
> > >    *  CLAT is performed by the host itself or a CE.
> > > or
> > >    *  CLAT is performed by the node (host or router).
> >
> >  This paragraph is describing the “Wireless” mode (CLAT on a host) outside of
> 3GPP - in Wi-Fi hotspots, enterprise networks etc. So in this scenario it’s
> important that CLAT is performed by a host, not a CE router.
> >
> > > Use CE across all the document instead of CPE, for consistency with
> > > previous documents? (7084, 8585, ...)
> >
> > At the same time RFC6877 uses ‘CPE’.  I’ve always assumed ‘CE’ and ‘CPE’
> can be used as  synonyms...
> >
> > > This document complements [RFC6877] by providing I think your
> > > document is complementing RFC8585 (or both of them)?
> >
> > Will change to “This document complements [RFC6877] and updates
> > [RFC8585] “
> >
> > > 5) Enabling CLAT
> > > I think it must be "CLAT MUST NOT” be enabled if.
> >
> > Yes, that was Jeremy's comment too. The next revision will have that change.
> >
> > > and
> > > IPv6-only node MUST enable
> >
> > The full sentence:
> > "Therefore an IPv6-only node SHOULD enable CLAT as soon as an Router
> Advertisement containing PREF64 option is received."
> > To be honest I have some reservations re: changing this particular SHOULD to
> MUST.
> >
> > If we say ‘MUST’ would it make any host which doesn’t do it
> > non-compliant. However I, for example, have a significant number of
> > devices which are IPv6-only but they do not have clat enabled, because
> > they only need (allowed to) talk to a very limited set of destinations
> > - and all those destinations are IPv6-enabled. So I do not want those devices to
> enable CLAT at all. So I think we shall allow implementations to be configured to
> have CLAT disabled.
> >
> > > I think here 8585 should be cited as well:
> > >    If RAs received by the node do not contain a PREF64 option, the node
> > >    MAY use other mechanisms to detect the PLAT presence and obtain the
> > >    NAT64 prefix (such as [RFC7050], see also RFC8585).
> >
> > I do not think 8585 defines any new mechanisms to obtain/discover the
> > NAT64 prefix.
> >
> > > Instead of:
> > >         has already obtained an IPv4 address.
> > > may be:
> > >         has already obtained an IPv4 address by other means.
> >
> > With the proposed change the sentence will read:
> > "The node SHOULD enable CLAT after discovering the NAT64 prefix, unless by
> that time the node has already obtained an IPv4 address by other means".
> > I might be missing smth but "by other means" is a bit confusing here, as it's not
> clear what "other" refers to..
> >
> >
> > > Typo (extra coma, space) or something missing after 108: DHCP Option
> > > 108,
> >
> > Thank you, fixed.
> >
> > > May be we need to consider defining a maximum delay instead of "The delay is
> implementation specific”.
> >
> > If we want to do this, I’d rather specify the default value and let
> > implementations choose whether they want to use it or not. I guess the
> > delay shall be comparable with an RTT between the client and the DHCP
> > server(s) - but I do not know what value to choose here. Any suggestions?
> >
> > > I think this is not clear:
> > >    The node MUST follow recommendations from Section 4 of [RFC7335] to
> > >    avoid IPv4 address space conflicts.
> > > You mean for the internal (LANs) IPv4 addressing, or for the translation if the
> CLAT don’t have a translation-reserved /64 obtained from the WAN prefix (so the
> CLAT performs first stateful NAT44 and then a stateless NAT46, instead of a
> stateless NAT46) ?
> >
> > RFC7335 is very specific to 192.0.0.0/29.
> >
> > Would it be more clear if we change the text to “If the node supports multiple
> IPv4 continuity solutions, the node MUST follow recommendations…”?
> >
> > > 7.1) CLAT IPv4 Addresses
> > > We may need to clarify for what are those addresses used in a 1st paragraph
> in this section, as it may be confused with translation addresses … see my
> comment above.
> >
> > We'll add some text to clarify that, thank you!
> >
> > > Actually the comment that you do about “despite the word wireless” … is also
> applicable (reversed) in the dedicated prefix model, as you can use that model for
> an UE (tethering) or 3GPP router, etc. So I will say some more text is needed there
> similar to the one in the single-address model, so the reader get that. May be:
> > > The dedicated prefix model, can be also used in wireless and 3GPP networks,
> and in that case there may be different possible architectures, such as as UE
> turns itself into a router providing one or multiple RFC1918 prefixes for different
> subnets, and using different IPv6 prefixes for different downstream networks, or
> shares a single prefix (RFC7278).
> >
> > How about adding the following text:
> > "Despite the word "wireline", this architecture is applicable for
> > wireless or 3GPP routers: such router can provide IPv4 connectivity to
> > connected devices, performing CLAT functions for traffic sent/received
> > via the IPv6-only uplink interface
> >
> > > 7.2) CLAT IPv6 Addresses
> > > I don’t think this is right:
> > >    However, deployments where each node can obtain a
> > >    dedicated /64 just for CLAT are rather uncommon, to say the least.
> > >
> > > For example, I recall (hopefully not wrong) that VPP implementation does that
> (Ole could confirm).
> > > I’ve seen also some CE implementations doing that. A CE should receive in the
> WAN a /48 prefix, then uses one of the them for the translation. This allows a
> stateless NAT46 instead of stateful NAT44 + stateless NAT46.
> >
> >  I agree, the text needs to be relaxed a bit - I was thinking about
> enterprise/public WiFi cases mostly, where CLAT nodes do not get prefixes, only
> addresses.
> >
> > >Clearly should be the preferred and recommended way. This document should
> “push” for that as well.
> >
> >  I do not think it’s realistic. Please do not forget that this
> > document is not just for CE or 3GPP cases, but for hosts like laptops
> > and desktops. Obtaining /64 per each laptop would be only possible in
> > networks which implement pd-per-device draft, and we can not expect it
> > to happen everywhere. Also, there are networks which do not have
> > scalability issues which would justify pd-per-device. If we make clat
> > require /64 it might be seen as a reason not to deploy v6-mostly. In
> > single-address model, the CLAT instance only needs a single IPv6
> > address, not /64
> >
> >
> > However it just occurred to me that  we might want allow  that for
> > each IPv4 address the instance obtain an IPv6 address - either via
> > SLAAC on the upstream side, or - in case of PD-per-device - from the
> > delegated /64
> >
> > So I think we shall add smth like:
> > "In a dedicated prefix model, the instance MAY obtain a dedicated IPv6 address
> for each CLAT IPv4 address."
> >
> > > 8) Updated to RFC8585
> > > Unless I missed something, 464XLAT-5 has no changes? if that’s the case, I
> don’t think that paragraph need to be neither in the old/new text?
> >
> > I was minimizing the number of “old/new” blocks, so I included XLAT-5 as it’s
> located between XLAT-4 and -6, both of them being changed.
> > I’ll split it in two, if it’s more readable.
> >
> >
> > > One last comment. Because at the beginning of the document its already said
> that the PLAT is a NAT64, may be for clarity/simplicity, in the rest of the document
> we can avoid using NAT64, and then use always just PLAT?
> >
> > Good point, we'll clean up the text a bit.
> >
> > > > El 24 may 2024, a las 18:10, Jen Linkova <furry13@gmail.com> escribió:
> > > >
> > > > Hello,
> > > >
> > > > Here is the updated version of the CLAT recommendations draft.
> > > > The key changes:
> > > > - some sections are reordered to improve readability
> > > > - the draft now recommends disabling CLAT as soon as IPv4
> > > > connectivity becomes available (not doing so would have not just
> > > > performance implications but security ones as well)
> > > > - a (simplified) diagram is added to illustrate the logic of
> > > > enabling and disabling CLAT.
> > > >
> > > > Comments are appreciated.
> > > >
> > > >
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: <internet-drafts@ietf.org>
> > > > Date: Sat, May 25, 2024 at 1:54 AM
> > > > Subject: New Version Notification for
> > > > draft-link-v6ops-claton-03.txt
> > > > To: Jen Linkova <furry13@gmail.com>, Tommy Jensen
> > > > <tojens@microsoft.com>
> > > >
> > > >
> > > > A new version of Internet-Draft draft-link-v6ops-claton-03.txt has
> > > > been successfully submitted by Jen Linkova and posted to the IETF
> > > > repository.
> > > >
> > > > Name:     draft-link-v6ops-claton
> > > > Revision: 03
> > > > Title:    464 Customer-side Translator (CLAT): Node Recommendations
> > > > Date:     2024-05-24
> > > > Group:    Individual Submission
> > > > Pages:    14
> > > > URL:      https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-link-v6ops-claton-03.txt&data=05%7C02%7CJensen.Thomas%40microsoft.com%7Ccf8c4568532c466d27d108dc8ac93864%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638537844100605394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OWoP6U5ma6VeILqa4uoH3w%2Bn8T1NfbFVZl69jp%2BGuwU%3D&reserved=0<https://www.ietf.org/archive/id/draft-link-v6ops-claton-03.txt>
> > > > Status:   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-link-v6ops-claton%2F&data=05%7C02%7CJensen.Thomas%40microsoft.com%7Ccf8c4568532c466d27d108dc8ac93864%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638537844100612735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Hgog1fx2Cv3%2F7SP2Fx4pgYLNSmF%2BKEd5a268jCXpyCw%3D&reserved=0<https://datatracker.ietf.org/doc/draft-link-v6ops-claton/>
> > > > HTML:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-link-v6ops-claton-03.html&data=05%7C02%7CJensen.Thomas%40microsoft.com%7Ccf8c4568532c466d27d108dc8ac93864%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638537844100618296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FuwFfkyMtfGh8Y1TDQ%2B%2BRtPqZtVPq%2BVZe9gW1XRZEWc%3D&reserved=0<https://www.ietf.org/archive/id/draft-link-v6ops-claton-03.html>
> > > > HTMLized: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-link-v6ops-claton&data=05%7C02%7CJensen.Thomas%40microsoft.com%7Ccf8c4568532c466d27d108dc8ac93864%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638537844100623596%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=uo1NS6LG5SXLLGzTLhXAT9PEpPsxf0x78UyqOiDYEws%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-link-v6ops-claton>
> > > > Diff:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-link-v6ops-claton-03&data=05%7C02%7CJensen.Thomas%40microsoft.com%7Ccf8c4568532c466d27d108dc8ac93864%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638537844100628570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6pu5UPsZ%2F99LAKV3JpjomuL%2BfYXH44O0aRmHWfJV%2ByU%3D&reserved=0<https://author-tools.ietf.org/iddiff?url2=draft-link-v6ops-claton-03>
> > > >
> > > > Abstract:
> > > >
> > > >   464XLAT ([RFC6877]) defines an architecture for providing IPv4
> > > >   connectivity across an IPv6-only network.  The solution contains two
> > > >   key elements: provider-side translator (PLAT) and customer-side
> > > >   translator (CLAT).  This document provides recommendations on when a
> > > >   node shall enable or disable CLAT.
> > > >
> > > >
> > > >
> > > > The IETF Secretariat
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers, Jen Linkova
> > > >
> > > > _______________________________________________
> > > > v6ops mailing list -- v6ops@ietf.org To unsubscribe send an email
> > > > to v6ops-leave@ietf.org
> > >
> > >
> > > **********************************************
> > > IPv4 is over
> > > Are you ready for the new Internet ?
> > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.theipv6company.com%2F&data=05%7C02%7CJensen.Thomas%40microsoft.com%7Ccf8c4568532c466d27d108dc8ac93864%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638537844100633559%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=PtVmlXXqZdZdK8aZ3CSZhkSgcFVSteLgneSGxdeCC6E%3D&reserved=0<http://www.theipv6company.com/>
> > > The IPv6 Company
> > >
> > > This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of the
> individual(s) named above and further non-explicilty authorized disclosure,
> copying, distribution or use of the contents of this information, even if partially,
> including attached files, is strictly prohibited and will be considered a criminal
> offense. If you are not the intended recipient be aware that any disclosure,
> copying, distribution or use of the contents of this information, even if partially,
> including attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
> > >
> > >
> > >
> > > _______________________________________________
> > > v6ops mailing list -- v6ops@ietf.org To unsubscribe send an email to
> > > v6ops-leave@ietf.org
> >
> >
> >
> > --
> > Cheers, Jen Linkova
> >
> > _______________________________________________
> > v6ops mailing list -- v6ops@ietf.org
> > To unsubscribe send an email to v6ops-leave@ietf.org
>
>
>
> --
> Cheers, Jen Linkova