Re: [v6ops] IPv6 mostly for DS-Lite

Brian Candler <brian@nsrc.org> Wed, 20 March 2024 11:13 UTC

Return-Path: <brian@nsrc.org>
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 ADAA6C15109A for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2024 04:13:31 -0700 (PDT)
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, 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, 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=nsrc.org header.b="ua3J545M"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="LJdRDTLZ"
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 6nz-bzzXlpm6 for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2024 04:13:24 -0700 (PDT)
Received: from fout8-smtp.messagingengine.com (fout8-smtp.messagingengine.com [103.168.172.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395EBC14F6B6 for <v6ops@ietf.org>; Wed, 20 Mar 2024 04:13:24 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.nyi.internal (Postfix) with ESMTP id 27A101380099; Wed, 20 Mar 2024 07:13:23 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 20 Mar 2024 07:13:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nsrc.org; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm2; t=1710933203; x=1711019603; bh=3O03QfPoF/ X6InMg6Y58Xqt7/CbsDODlI7wvn/dCihc=; b=ua3J545McaaiBXiDJ4Azn6zPUP fu9D7xuUHX/DACqb1LurEiz178c7pGnQuLYhdhUJMXLIQkEHMR4BN0YBhqOxvk7k ExflGyGDUB0OXbXGt4M9HSmXtB8QOs6lbewC9SUYIFu49crm+dZ7B/BN20kWpFyE p61qjyxXQhoZ16Fm17ws/5NK7KbMMU4umKr5EkvO5NWxEfF8JwiwJsfCImklARQh 1B4uJnCUfsoeLaFOjYZSbnVwfGMP6ePciEmz5JzfeDAPN1fvgSpLQ/Dbqp+k+wcQ /ZZ3b2va4/A9kj+ys/4xs9rIbnjP4dWMeKIMxwfBS+TcqktMD+xQzZkj+6CQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1710933203; x=1711019603; bh=3O03QfPoF/X6InMg6Y58Xqt7/Cbs DODlI7wvn/dCihc=; b=LJdRDTLZSajipF2IUMiSVpkfWuZNqCDDxgkTXuyuRKCG vD/AONI/fVdmObzRDasLoctH35eJ5u+u+twJHDlqUPBHoiWvG//V6Rk4tt8c9+HM LIymUK05+hW/edfSDSzknBfX3SQtqsdVlC2JT0cdbtEUXqApKB+1Akf+6EAKRmfQ mB8L6HO73SsGivZRLOe1gUDehPmUZevqTgjD3WOXZvQ8OODJY6yy0zTtTPggWPOy niMrXY7YtmXrNxknWwkKFV6Hsdw+8zBArBWRigxWRv0Kv96a/o62joYi5EfFsUzv TsFRxlp4hbFCvO5QjYM9f4Hebw93mWyeMoHe0X1viQ==
X-ME-Sender: <xms:0sT6ZVKH26LmKZMMlhuCyuzi6eM3q8Eghc7xrIkHxPaa_vuuEl_hnw> <xme:0sT6ZRJmmrZ5qenbzgCBkJf3qkp-EPSi1hQXD5x1uCF8jzDdOChTsdTQI2m7alYrN 3wrm4tmGx9hPiCSDlU>
X-ME-Received: <xmr:0sT6Zdv5aSNba0XT33EO0Ti9K4TW0omNjnYLvOfsOYKq0AeDNt8zDyKdJxxq0vk>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrleeggddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtkfffgggfuffvvehfhfgjsegrtderredtvdejnecuhfhrohhmpeeurhhirghn ucevrghnughlvghruceosghrihgrnhesnhhsrhgtrdhorhhgqeenucggtffrrghtthgvrh hnpeeftdekhfevffeihfeghfelieeliedtgffgffevveejhfetueduieefteeuueeffeen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhirg hnsehnshhrtgdrohhrgh
X-ME-Proxy: <xmx:0sT6ZWaQYc_2BwMo-mT1PjXoIc3cJwCXehYBMftBQxdJdMKYqJEAyw> <xmx:0sT6ZcbjkcJstUTGS1CmnmfgVi-XxcIFLYUhv5U1Y5fJz6WqOXwAsA> <xmx:0sT6ZaB7MBp09oDHdBmEoeQzxHa6R3fx74fiI6Gz_k7av2x1vXxJ0w> <xmx:0sT6Zab009-02uTXNJCFA8SzMy1D21uUf1pAUk4JXpD72FDGUMAElg> <xmx:08T6Zbz05ta985owbufVch0k5RNJORmDG9-egPCeWgYbqCm99ZAGMg>
Feedback-ID: i8f09498f:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 20 Mar 2024 07:13:22 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------11UvSJINU726qzYfyHm4yTAJ"
Message-ID: <921d40b9-b51f-44e3-a95d-5afd0a4240c7@nsrc.org>
Date: Wed, 20 Mar 2024 11:13:21 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: Gert Doering <gert@space.net>, Mark Andrews <marka@isc.org>
Cc: v6ops <v6ops@ietf.org>
References: <Zfqag8pqi3in3G5p@Space.Net> <2AA6E4EF-01CA-4CE5-AF73-9BCA4B0586B0@isc.org> <ZfrAxrloVYBojJj_@Space.Net>
From: Brian Candler <brian@nsrc.org>
In-Reply-To: <ZfrAxrloVYBojJj_@Space.Net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7OcPZQzvsxHQD3OFb2eI8EYW9ZQ>
Subject: Re: [v6ops] IPv6 mostly for DS-Lite
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: Wed, 20 Mar 2024 11:13:31 -0000

On 20/03/2024 10:56, Gert Doering wrote:
> I tend to disagree - NAT64 could happen on the CPE for ipv6-mostly
> "behind the CPE" networks, and then going ahead with DS-Lite'ing the
> resulting IPv4 packet.  Yes, NAT4444, but for legacy things only.

Unfortunately, that would imply that the CPE would also have to do 
stateful NAT44, prior to encapsulating packets to the AFTR.

In a traditional DS-Lite, the encapsulation on the CPE can be stateless, 
since the AFTR uses the combination of (CPE) source IPv6 + tunnelled 
source IPv4 to distinguish NAT sessions. Of course, the CPE hands out 
distinct IPv4 addresses to each client via DHCPv4.

But if you're doing NAT46 on the client and NAT64 on the CPE, all the 
clients will be using 192.0.0.2, so you can't just pass the source 
address as-is to the AFTR.  You'd need either to allocate and map a fake 
IPv4 address for each IPv6 CLAT client address, or do NAT-PT where the 
local state table also includes CLAT IPv6 address.

Not saying it's impossible - but it ain't pretty.