Re: [BEHAVE] v6 content for IPv4-only clients

Dan Wing <dwing@cisco.com> Mon, 01 July 2013 17:19 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B4A21F9FF6 for <behave@ietfa.amsl.com>; Mon, 1 Jul 2013 10:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.377
X-Spam-Level:
X-Spam-Status: No, score=-110.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFGh4itJExzh for <behave@ietfa.amsl.com>; Mon, 1 Jul 2013 10:19:09 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFC821F9F6A for <behave@ietf.org>; Mon, 1 Jul 2013 10:18:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1728; q=dns/txt; s=iport; t=1372699126; x=1373908726; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=SG8Jeym71A2haw6pIfRO/esThaU+Bfv+k9pXb+zIUnQ=; b=MNaxXgBnYH0VKZkPnF0N5/wNXN+tO5T2GuTQzuhySP/HTVOc+jahsQ0m oCRqwDS6WfpOJiC5g72BgLH0GFPZXlhWjdg8N3bPr68fIIs1uqd6t5Sr3 VZewp9qOUSisvW+E6C8OQRv5kByostP8Gd1U9vk2/ARU1IkPVKa6W0uPg s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAJe40VGrRDoG/2dsb2JhbABagwkyv2N/FnSCIwEBAQMBOjINBQsLRlcGE4gJBQ28HI4mgQUzB4MEYwOJI44lgSmQHIMxHIEs
X-IronPort-AV: E=Sophos;i="4.87,975,1363132800"; d="scan'208";a="84929880"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 01 Jul 2013 17:18:45 +0000
Received: from sjc-vpn2-667.cisco.com (sjc-vpn2-667.cisco.com [10.21.114.155]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r61HIi5N021541; Mon, 1 Jul 2013 17:18:45 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB0146E019@S2010EXCH1.ad.local>
Date: Mon, 01 Jul 2013 10:18:44 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <779AE7C6-8349-4DEA-92FC-00E520B80632@cisco.com>
References: <786F13AA11E69F4DB2CCA23F7400C2FB0146E019@S2010EXCH1.ad.local>
To: Branimir Rajtar <Branimir.Rajtar@t.ht.hr>
X-Mailer: Apple Mail (2.1508)
Cc: "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] v6 content for IPv4-only clients
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 01 Jul 2013 17:19:13 -0000

On Jul 1, 2013, at 12:59 AM, Branimir Rajtar <Branimir.Rajtar@t.ht.hr> wrote:

> Hello everybody,
>  
> Just wanted to let you know my colleagues and me just posted a new draft describing how IPv4-only clients can access content available only on IPv6. Please take a look and comment:
> http://datatracker.ietf.org/doc/draft-rfvlb-behave-v6-content-for-v4-clients/

The document says:

  1.2.  Covered Scenarios

   As described in [RFC6144], there are multiple scenarios for IPv4/IPv6
   translation.  This document covers mainly Scenario 4: An IPv4 Network
   to the IPv6 Internet, but is not limited to be used for the following
   scenarios as well:

   o  Scenario 2: The IPv4 Internet to an IPv6 Network

   o  Scenario 6: An IPv4 Network to an IPv6 Network

   These scenarios are not subject of this draft and can be elaborated
   in future documents, if deemed necessary.


I don't think Scenario 2 is solvable with the approach described in draft-rfvlb-behave-v6-content-for-v4-clients, because draft-rfvlb-behave-v6-content-for-v4-clients describes assigning IPv4 addresses from RFC1918 space.  If public space were to be assigned instead of RFC1918 space, public IPv4 space would be consumed at the same rate as running a normal dual-stack server, so nothing is gained compared to operating a normal dual-stack server.

It would be helpful to include a network diagram showing the location of the DNS proxy (which is a new function), the NAT46 function, and the Internet. I have a topology in my head, and I believe my topology is accurate, but I can't be sure until I see a diagram of where these elements would be located.  Thanks.

-d