Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - are changes in dualstack hosts acceptable or not?

Iljitsch van Beijnum <iljitsch@muada.com> Sun, 27 July 2008 21:59 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8670A3A6809 for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 27 Jul 2008 14:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 gx9mRF135Wzh for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 27 Jul 2008 14:59:40 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C9F63A6906 for <v6ops-archive@lists.ietf.org>; Sun, 27 Jul 2008 14:59:39 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1KNEGg-0008oG-0m for v6ops-data@psg.com; Sun, 27 Jul 2008 21:59:06 +0000
Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <iljitsch@muada.com>) id 1KNEGc-0008nd-MX for v6ops@ops.ietf.org; Sun, 27 Jul 2008 21:59:04 +0000
Received: from [172.16.9.89] (guestroom-nat.meeting.ietf.org [130.129.64.64]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m6RLwKFO037618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Jul 2008 23:58:41 +0200 (CEST) (envelope-from iljitsch@muada.com)
Cc: marcelo bagnulo braun <marcelo@it.uc3m.es>, Jari Arkko <jari.arkko@piuha.net>, Dave Thaler <dthaler@windows.microsoft.com>, 'IPv6 Operations' <v6ops@ops.ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-Id: <7DC3D9D2-8787-4834-9933-31D09B6737C9@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Rémi Denis-Courmont <rdenis@simphalempin.com>
In-Reply-To: <200807251911.16835.rdenis@simphalempin.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - are changes in dualstack hosts acceptable or not?
Date: Sun, 27 Jul 2008 22:58:30 +0100
References: <4889EAD2.8060809@it.uc3m.es> <200807251911.16835.rdenis@simphalempin.com>
X-Mailer: Apple Mail (2.926)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 25 jul 2008, at 17:11, Rémi Denis-Courmont wrote:

>> So, the question is: is a dual stack host a v6 host (i.e. changes are
>> acceptable) or is it a v4 host (i.e. changes are not acceptable)?

> Regardless of the current requirements, I would argue it is not  
> acceptable
> that dual-stack nodes need to be modified, for the exact same reason  
> as it is
> not acceptable that IPv4-only nodes need to be modified: deployment  
> would be
> highly impractical.

Note that these issues aren't necessarily binary.

If a dual stack host is presented with synthetic AAAA records along  
with A records, the host will try to use translated connectivity when  
it could have used native connectivity. The requirements require that  
this is avoided. One way to avoid this is to upgrade hosts so they  
automatically prefer real A records over synthetic AAAA records. This  
is rather inconvenient, bu there are only 10 - 20 operating systems in  
the world. Another way to avoid this situation is to make sure that  
dual stack hosts are never served by a recursive nameserver with DNS64  
functionality. However, there are many thousands of ISPs and hundreds  
of thousands of organizations running significant networks in the  
world, which would all have to do this.

So yes, requiring host modifications is bad, but imposing operational  
restrictions has the potential to be much worse in time and money. On  
the other hand, everyone can change their own network, while few  
people can change their OS.