RE: What flexibility do 6to4 NAT have with address formats?

"Perkins, Carroll G" <Carroll.Perkins@serco-na.com> Wed, 14 October 2009 12:42 UTC

Return-Path: <Carroll.Perkins@serco-na.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 EA67D3A69ED for <ipv6@core3.amsl.com>; Wed, 14 Oct 2009 05:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 MDLnM1XGx1Jv for <ipv6@core3.amsl.com>; Wed, 14 Oct 2009 05:42:20 -0700 (PDT)
Received: from SNAET01.serco-na.com (snaet01.serco-na.com [209.27.15.9]) by core3.amsl.com (Postfix) with ESMTP id 853103A69F2 for <ipv6@ietf.org>; Wed, 14 Oct 2009 05:42:20 -0700 (PDT)
Received: from SNAHTCAS02.serco-na.com (10.11.11.142) by SNAET01.serco-na.com (209.27.15.9) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 14 Oct 2009 08:40:05 -0400
Received: from snamb01.serco-na.com ([fe80::1cde:8ef7:e871:90ac]) by SNAHTCAS02.serco-na.com ([::1]) with mapi; Wed, 14 Oct 2009 08:40:46 -0400
From: "Perkins, Carroll G" <Carroll.Perkins@serco-na.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Christian Huitema <huitema@microsoft.com>
Date: Wed, 14 Oct 2009 08:40:45 -0400
Subject: RE: What flexibility do 6to4 NAT have with address formats?
Thread-Topic: What flexibility do 6to4 NAT have with address formats?
Thread-Index: AcpMZ7mzD65WFpfWQ5SiwJzqIOTmlgAYI/1D
Message-ID: <FE653BE0C4967449B3B5081DA1D26CAEC003DF20BD@SNAMB01.serco-na.com>
References: <6B55F0F93C3E9D45AF283313B8D342BA211A8C1D@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>, <4AD51F5D.9070106@gmail.com>
In-Reply-To: <4AD51F5D.9070106@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 6man 6man <ipv6@ietf.org>
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: Wed, 14 Oct 2009 12:42:22 -0000

"routers should never treat /64 as special or as any kind of limit. It's just a convention that /64 is
considered the longest normal subnet prefix, which happens to be compatible with SLAAC"

Not sure which vendor router implementations of IPv6 you are talking about, but the /64 division is almost universally used across so many router configuration panels, IPv6 address management applications, etc that ignoring or changing it basically kills any chance of having a proposed standard accepted by IETF.  For example, read the manual on the D-Link DIR-615 Hardware ver C1 Firmware ver 3.11NA to see what I am talking about.  The /64 BOUNDARY IS HARDCODED INTO THE FIRMWARE AND IS UNCHANGEABLE.

One of the situations occurring with todays IPv6 adoption is that long-time IPv4 techies are looking for the variability that IPv4 embodies because of it's definition on the fly during the last 20 years.  But IPv6 basically defines out as much variability as possible to keep IPv6 implementations compatible across vendors.  Think like Japanese cars, they all have different names, but most of the underlying parts come from the same suppliers.  So IPv4 techies knowledge base on protocol variabilities is basically factored out of IPv6 definitions to the greatest extent possible.  Formal evidence of variabliity limitation is that NIST has set up standardized testing lab structures for IPv6 devices to be certified, process modeled after what Underwriter Labs has done for electrical appliances.  By the end of 2010, all commercial IPv6 devices should be NIST lab certified against a given set of IETF standards or there will be no commercial market for them.  But the best thought experiment is: How many 47 cycle AC hairdryers have you seen at Wal-Mart lately?

Above comments based on 2 years of IPv6 implementation experience.  Carroll Perkins



________________________________________
From: ipv6-bounces@ietf.org [ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter [brian.e.carpenter@gmail.com]
Sent: Tuesday, October 13, 2009 8:46 PM
To: Christian Huitema
Cc: 6man 6man
Subject: Re: What flexibility do 6to4 NAT have with address formats?

On 2009-10-14 03:38, Christian Huitema wrote:
...
>
> 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.

As I understand it, routers should never treat /64 as special
or as any kind of limit. It's just a convention that /64 is
considered the longest normal subnet prefix, which happens to
be compatible with SLAAC. So I can't see any fundamental
reason why the IPv4 address bits can't straddle the /64
boundary. However, they should clearly skip over the UG bits
so the resulting 64-bit IID is consistent with the IID rules.
That will break byte alignment.

>
> 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.

If you do straddle the /64 boundary, you will not have a null
IID so the issue goes away. If not, using null feels wrong to
me. Firstly, it conflicts with the current (harmless and
possibly implemented) spec. Secondly, specifying a value is no
big deal as far as I can see.

>
> 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?

Why wouldn't it be OK? I can't see why it's a question.
The normal expectation is that different hosts have different
IIDs so I am curious why this matters.

   Brian

>
> -- Christian Huitema
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org
> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------