IETF Logo Mail Archive

Re: Tunnel-to-NAT scenario

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 17 June 2008 22:19 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 6268A3A6B72 for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 15:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.296
X-Spam-Level:
X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 C67W44jnyYMP for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 15:19:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 46C223A69B4 for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 15:19:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1K8jVL-000Kag-El for v6ops-data@psg.com; Tue, 17 Jun 2008 22:18:19 +0000
Received: from [64.233.166.176] (helo=py-out-1112.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <brian.e.carpenter@gmail.com>) id 1K8jVH-000Ka7-7h for v6ops@ops.ietf.org; Tue, 17 Jun 2008 22:18:16 +0000
Received: by py-out-1112.google.com with SMTP id d32so2225305pye.19 for <v6ops@ops.ietf.org>; Tue, 17 Jun 2008 15:18:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=T2MmXPXuDVgzIYYOuQIQBsVil7/Bs6+yff6X810URPc=; b=BpH+nJGs5Fp5MrkT/hNbjAYQHfmsCmUOGcPReNMyvTJ9NAHIw/IHVLi9OzZLxhScfa C8IlKWeaVaKoJnA/3m/dhSmXgrMoiAPnN34EuyqZPCJWn2Z7emKHyrcw2LviMRDuzOPE c+GoSFdrcb4w6+Rn02Npo6Dxd0+Roz/NyxHw8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=UwrUFl77eVmEI1G+BWKk31hSW7DcMJB7Fq+i6N2RdcQk8ZlyaPs/j+5Ue5fT2TA63X cGpyEcE3TxmS7xVK6hXpA52nYqc3E8+suh2R/k7+wolqSwpk7qWHJal28c0eJFqp7Tnj Rgd+Vm0j34OPuSaWO3aA0MGm8dm+OY5qtnP/w=
Received: by 10.114.124.12 with SMTP id w12mr8749852wac.210.1213741091690; Tue, 17 Jun 2008 15:18:11 -0700 (PDT)
Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id g25sm9756776wag.4.2008.06.17.15.18.10 (version=SSLv3 cipher=RC4-MD5); Tue, 17 Jun 2008 15:18:11 -0700 (PDT)
Message-ID: <48583820.8080600@gmail.com>
Date: Wed, 18 Jun 2008 10:18:08 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Iljitsch van Beijnum <iljitsch@muada.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <4856F297.50608@gmail.com> <7446ED57-C2AF-40D2-A993-42E8F592F049@muada.com> <48583075.2020408@gmail.com> <C17751DB-0506-49B2-93FD-812E41A8EDA9@muada.com>
In-Reply-To: <C17751DB-0506-49B2-93FD-812E41A8EDA9@muada.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On 2008-06-18 10:02, Iljitsch van Beijnum wrote:
> On 17 jun 2008, at 23:45, Brian E Carpenter wrote:
> 
>>> The actual packet mangling should be simple
>>> enough, the problem is that the client can't express the IPv6
>>> destination in an IPv4 packet without modifications to the IPv4 client
>>> (and those modifications would be unlikely to work through middleboxes).
> 
>> That's why you go to a traditional v4-to-v4 NAT at the boundary.
>> No new mangling code is needed. From the v4 point of view this
>> is bog standard NAPT with configured port mapping.
> 
> So if you're an IPv4 client and I'm an IPv6 server with address
> 2001:db8:31::1, what do you put in the destination address of the IPv4
> packets you send to me?

The public address of the NAT to which you are tunneling. Of course,
that NAT has to be configured to forward port N through a tunnel
to whatever IPv4 address 2001:db8:31::1 has borrowed.

(draft-despres-v6ops-apbp-00.txt would automate the borrowing
process, if you don't want to configure it.)

This doesn't get rid of NAPT nastiness for supporting servers.
But if someone insists on running a server for IPv4 clients that
doesn't have its own public IPv4 address, that nastiness is
intrinsic. The question is what's the simplest way to deal
with it.

    Brian

v2.23.0 | Report a Bug | By Email