Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 05 November 2013 02:30 UTC

Return-Path: <swmike@swm.pp.se>
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 223FA11E82CF for <v6ops@ietfa.amsl.com>; Mon, 4 Nov 2013 18:30:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.842
X-Spam-Level:
X-Spam-Status: No, score=-5.842 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 fKser8EkuqZL for <v6ops@ietfa.amsl.com>; Mon, 4 Nov 2013 18:30:31 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 57CCB21F9FB3 for <v6ops@ietf.org>; Mon, 4 Nov 2013 18:30:31 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 86ED39C; Tue, 5 Nov 2013 03:30:30 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 82A519A; Tue, 5 Nov 2013 03:30:30 +0100 (CET)
Date: Tue, 5 Nov 2013 03:30:30 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com>
Message-ID: <alpine.DEB.2.02.1311050329470.26054@uplift.swm.pp.se>
References: <20131013235941.31896.30276.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt
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, 05 Nov 2013 02:30:38 -0000

On Tue, 5 Nov 2013, Eric Vyncke (evyncke) wrote:

> I have hard time to understand the case described in section 3.1.4 
> "co-existence of NAT44 and NAT64". Why would a provider use both at the 
> same time? Using NAT44 + native IPv6 is sensible, using IPv6-only + 
> NAT64 is also valuable but I cannot imagine why NAT44 and NAT64 could be 
> use together for the same subscribers.

Mobile.

It's up to the terminal to initiate a connection in the APN, and you don't 
know if it'll be IPv4 only, IPv6 only or dual stack.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se