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.
- draft-ietf-v6ops-nat64-pb-statement-req-00 - are … marcelo bagnulo braun
- Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - … Rémi Denis-Courmont
- Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - … marcelo bagnulo braun
- RE: draft-ietf-v6ops-nat64-pb-statement-req-00 - … teemu.savolainen@nokia.com
- Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - … Rémi Després
- Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - … Brian E Carpenter
- Re: draft-ietf-v6ops-nat64-pb-statement-req-00 - … Iljitsch van Beijnum