IETF Logo Mail Archive

Re: [v6ops] BIH vs 464XLAT

Cameron Byrne <cb.list6@gmail.com> Tue, 27 March 2012 10:59 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47B721F89D8 for <v6ops@ietfa.amsl.com>; Tue, 27 Mar 2012 03:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.142
X-Spam-Level:
X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
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 Xuq2EpD8dFV7 for <v6ops@ietfa.amsl.com>; Tue, 27 Mar 2012 03:59:54 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAC921F89D6 for <v6ops@ietf.org>; Tue, 27 Mar 2012 03:59:54 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so4956195yhk.31 for <v6ops@ietf.org>; Tue, 27 Mar 2012 03:59:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=n8PXHcLJ0IOdloSGbxdtwwcQslqZs1mSge/ikF6v6gs=; b=ghtRu51UuN65i6QylMq9s8ysziznUe1KfIOWBY7oWHmBl+PSLukVVf3MgEnHG7tynW BCpZgE8g7BTdX4osFsBRqkbj+XCDNVvcj/RUEsZQmBqzNEggZmYYyM5+tuSbUI5+WM/H GEWacaySg/ezoJKVDbVlUGluPdE+ZJumyWczHmqhO5Ihrk/bGoqVsGaiPeTODdAMdQnw QbqmPSZSd+NlVR1s2D1L5vkfwX4zud/2f0hJ0XBmVILF6dz//XJ0ZdLgTrCxCirY34Ur f1A3nDhbg29Xi6mf0vTCevhzkHK4BsIveP355IBTEi7fRSpTHGKq75fSPbIGW+vgbhQc Y8QA==
MIME-Version: 1.0
Received: by 10.68.197.65 with SMTP id is1mr8525614pbc.70.1332845993305; Tue, 27 Mar 2012 03:59:53 -0700 (PDT)
Received: by 10.143.160.13 with HTTP; Tue, 27 Mar 2012 03:59:53 -0700 (PDT)
In-Reply-To: <4F719752.4060601@viagenie.ca>
References: <4F719752.4060601@viagenie.ca>
Date: Tue, 27 Mar 2012 03:59:53 -0700
Message-ID: <CAD6AjGR-Y=8812WuySzhwiSf2-CP5yH=+bhgc1OM-h5qXyHTyA@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org
Subject: Re: [v6ops] BIH vs 464XLAT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Mar 2012 10:59:58 -0000

On Tue, Mar 27, 2012 at 3:32 AM, Simon Perreault
<simon.perreault@viagenie.ca> wrote:
> I was thinking that bump-in-the-host (BIH) could be used for something like
> 464XLAT, and after some questioning I was pointed to the following extract from
> RFC6535:
>
>   The IETF recommends using solutions based on dual stack or tunneling
>   for IPv6 transition and specifically recommends against deployments
>   utilizing double protocol translation.  Use of BIH together with a
>   NAT64 is NOT RECOMMENDED [RFC6180].
>

FYI -- i fought this restriction in BEHAVE.  Lost.

> Wouldn't this anti-recommendation also apply to 464XLAT?
>
> Did the consensus on double translation change?
>

I have to assume so since Softwires has mountain of work that is
double translation, and in fact MAP-T is triple translation, NAT4464

It is perhaps the situation that BIH came a few months too soon for
the IESG to be responsive to the realistic need of double translation.

That said, 464XLAT seldom uses double translation in practice when
used together with DNS64

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.3

Double translation is only invoked in the case when NAT64/DNS64 alone
would result in failure of communication due to IPv4-only sockets or
IPv4 literals.

So, the tradeoff is double translation or communication failure.
Subscribers who don't know what IP is like the double translation
solution that loads Skype.

There is also the fact the IESG passed this
http://tools.ietf.org/html/draft-weil-shared-transition-space-request-15
... which is clearly a tip of the hat to NAT444.  It would be
unconscionable for the IESG to support NAT444 and not support
something that required IPv6 and enabled IPv6 like 464XLAT

CB

> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email