What flexibility do 6to4 NAT have with address formats?

Christian Huitema <huitema@microsoft.com> Tue, 13 October 2009 14:38 UTC

Return-Path: <huitema@microsoft.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271DF3A68EB for <ipv6@core3.amsl.com>; Tue, 13 Oct 2009 07:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhZJFMYuXfg7 for <ipv6@core3.amsl.com>; Tue, 13 Oct 2009 07:38:45 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4742D3A68AD for <ipv6@ietf.org>; Tue, 13 Oct 2009 07:38:45 -0700 (PDT)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 13 Oct 2009 07:38:53 -0700
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.20; Tue, 13 Oct 2009 07:38:46 -0700
Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.171]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Tue, 13 Oct 2009 07:38:47 -0700
From: Christian Huitema <huitema@microsoft.com>
To: 6man 6man <ipv6@ietf.org>
Subject: What flexibility do 6to4 NAT have with address formats?
Thread-Topic: What flexibility do 6to4 NAT have with address formats?
Thread-Index: AQHKTBLenI3gZ4LIvkKZSynuTjxdMQ==
Date: Tue, 13 Oct 2009 14:38:43 +0000
Message-ID: <6B55F0F93C3E9D45AF283313B8D342BA211A8C1D@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2009 14:38:46 -0000

We were having a discussion when preparing the next version of the "translated addresses" document. This document describes the address format used by protocol translators, including "stateless translators" that rely on algorithms to map an IPv6 address to an IPv4 address. The work is going on in the BEHAVE working group, but the expertise on address formats lies in the IPv6 WG. Hence the questions to this list.

There are a couple of constraints, of various importance, that we need to address. You mention checksum neutrality, and we can certainly accommodate that, but there are a few others that lead to discussions. For example, for stateless translation, we need to be able to route packets in the IPv6 network based on the IPv4 address. If we want to protect against address spoofing, we need to also perform reverse path checks based the IPv4 address. Even for stateful translation, we may need to select the translator based on the target IPv4 address, e.g. to perform load balancing.

That requirement can be accommodated in several ways, the simplest one being to format the addresses a prefix (well known or network specific), concatenated with the IPv4 address and a suffix. That way, the network can perform internal routing and checks on the combination of  prefix+IPv4 address. But then, there are a few complications.

First, we wonder about the importance of the 64 bit boundary. Addressing documents specify that the global address is essentially formed of a 64 bit subnet prefix and a 64 bit host identifier, with the host identifier compatible with IEEE 802 identifiers. Does that mean that the "routing" requirement of stateless translation can only be addressed if the IPv4 bytes are entirely contained within the subnet prefix? Different authors have different opinions, so WG input would be beneficial.

Second, we wonder about the constraints of host identifiers. A first question is whether an all null identifier would be legitimate and practical. There is some evidence that it works with most stacks. But there is also a statement in the addressing document that the all null address is reserved for the subnet anycast address. Do stacks actually implement the subnet anycast function? Should the specification be removed from the addressing RFC? Can we just ignore it? If we cannot ignore it, we will have to specify some value different from zero for the suffix. A "checksum neutrality" field might do that, but please consider the second question.

The second question regards the uniqueness of host identifiers. Suppose we define the address used for stateless translation as: 32 bit "provider" prefix, 32 bit IPv4 address, and a constant identifier, either 0 or the "checksum neutrality" value, which is only a function of the provider prefix. Suppose now that for some reason there are two "IPv4 addressed" hosts on the same link, e.g. because many servers are located in the same server room. The two hosts will have different addresses, in different 64 bit subnets, but they will also have different host identifiers. Is that OK? 

-- Christian Huitema