Re: [BEHAVE] Questionon embedded address format in draft-baker-behave-v4v6-framework-02

"Dan Wing" <dwing@cisco.com> Fri, 24 April 2009 23:24 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2A803A697F for <behave@core3.amsl.com>; Fri, 24 Apr 2009 16:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.312
X-Spam-Level:
X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 shsAj7bYO0MQ for <behave@core3.amsl.com>; Fri, 24 Apr 2009 16:24:02 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BB4CD3A6CFA for <behave@ietf.org>; Fri, 24 Apr 2009 16:24:02 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.40,244,1238976000"; d="scan'208";a="176638293"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 24 Apr 2009 23:25:09 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3ONP9wv029210; Fri, 24 Apr 2009 16:25:09 -0700
Received: from dwingwxp01 ([10.32.240.197]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n3ONP99F000342; Fri, 24 Apr 2009 23:25:09 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Iljitsch van Beijnum' <iljitsch@muada.com>, 'Rémi Després' <remi.despres@free.fr>
References: <D109C8C97C15294495117745780657AE0B8E2371@ftrdmel1> <01C41FE7-338B-4C26-BE6A-AD0119404276@cisco.com> <49DC7354.8070305@free.fr> <7E8115D0-C412-4A5F-9281-1C5C97868152@cisco.com> <49DF5476.5030306@free.fr> <D109C8C97C15294495117745780657AE0B9CD4ED@ftrdmel1> <49E7C48D.3020305@gmail.com> <D109C8C97C15294495117745780657AE0B9CD792@ftrdmel1> <55CFDB58-ADD2-460E-9142-87F28E44506E@cisco.com> <49E8CFD9.40904@it.uc3m.es> <49ED219C.1070202@gmail.com> <49EDD647.3060500@free.fr><49EDD750.1070502@network-heretics.com> <49EDDC57.1060302@free.fr><49EE1507.9090306@network-heretics.com><49EEC270.7040607@free.fr> <49EEDADA.8040906@it.uc3m.es><49EF1888.5020302@free.fr> <49EF1D4B.5050300@it.uc3m.es><49EF5017.5030409@free.fr> <49EF6F5D.2010306@it.uc3m.es><49F032DE.3060604@free.fr> <49F03BB4.9050103@it.uc3m.es><49F074D4.2070006@free.fr> <49F07ACF.9000505@it.uc3m.es><49F1D55E.6000003@free.fr> <0C02E699-3F36-4C04-AEB8-59E78D49B827@muada.com>
Date: Fri, 24 Apr 2009 16:25:09 -0700
Message-ID: <02ca01c9c533$e8f14620$c5f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Thread-Index: AcnFJMyqG/9lg4bjREGetTmmkb6LvQADdwZw
In-reply-to: <0C02E699-3F36-4C04-AEB8-59E78D49B827@muada.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2417; t=1240615509; x=1241479509; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:=20RE=3A=20[BEHAVE]=20Questionon=09embedded=09addr ess=09format=09in=09draft-baker-behave-v4v6-framework-02 |Sender:=20; bh=VZC2CRsY8oqa6jQ9RAz2iBKr2Vffg4mYamG38evh/Ig=; b=NPnjn2jJhbaz6r2kSSqpXCKpP+0asa3tmO/IEAqZges38EeuLKcC6PVUpq xA052l1IdQ0jBu7/tG/tbM74nxCa2L+9sdAnt9BCOnEBatxKJndKtNEAN079 mF8qidf2F1;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
Cc: 'Behave WG' <behave@ietf.org>
Subject: Re: [BEHAVE] Questionon embedded address format in draft-baker-behave-v4v6-framework-02
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Apr 2009 23:24:03 -0000

> -----Original Message-----
> From: behave-bounces@ietf.org 
> [mailto:behave-bounces@ietf.org] On Behalf Of Iljitsch van Beijnum
> Sent: Friday, April 24, 2009 2:36 PM
> To: Rémi Després
> Cc: Behave WG
> Subject: Re: [BEHAVE] Questionon embedded address format in 
> draft-baker-behave-v4v6-framework-02
> 
> On 24 apr 2009, at 17:06, Rémi Després wrote:
> 
> >> i don't know if i want to go there, not at least until we 
> have the  
> >> WK prefix defined.
> 
> > IMHO, this remark is by itself an INCENTIVE to have a WKP asap. As  
> > soon there is one defined, DynDNS clients of IPv4-only servers can  
> > be upgraded to produce synthetic AAAAs and send them to 
> > existing DNS  
> > servers. The end result is that these servers become immediately  
> > accessible by IPv6-only clients whose NAT64s are configured with  
> > this prefix.
> 
> So you want to create synthetic AAAA records at the source (the  
> authoritative DNS server) and trust that there wil be a translator  
> somewhere that will provide connectivity for those AAAA addresses to  
> IPv6 hosts.
> 
> This is not a good idea. The translators aren't out there today, and  
> it's unlikely they're going to be universal any time soon.
> 
> And even if every IPv6 host were served by a translator, this 
> would be  
> problematic because now dual stack hosts will first try to 
> connect to  
> the synthetic AAAA address and only then to the real A address.
> 
> If people want to make their v4-only services available to IPv6-only  
> clients, what they should do is run their own translator locally (or  
> arrange to be served by someone else's translator) using global  
> unicast IPv6 addresses. Then the entire IPv6 internet will be 
> able to connect to those services through that translator and 
> there won't bre any problems.

That falls into the "well-known prefix causes harm" category.

I recall that one of the presentations at the Google IPv6 
conference showed there were a lot of Teredo and 6to4
prefixes advertised in DNS.  If IANA assigns a well known 
prefix for 6/4 translation, we should expect some people
will stick that prefix into their DNS records.  Perhaps
out of incompetence, perhaps while debugging or learning, 
or perhaps because 'it works fine for my site that way'.

-d