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

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 14 November 2013 06:58 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 A0D3C21E80D2 for <v6ops@ietfa.amsl.com>; Wed, 13 Nov 2013 22:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.953
X-Spam-Level:
X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.296, 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 R2SLQO5+cMMZ for <v6ops@ietfa.amsl.com>; Wed, 13 Nov 2013 22:58:51 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id EABF621E81B8 for <v6ops@ietf.org>; Wed, 13 Nov 2013 22:58:39 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id AA7309C; Thu, 14 Nov 2013 07:58:38 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9EADF9A; Thu, 14 Nov 2013 07:58:38 +0100 (CET)
Date: Thu, 14 Nov 2013 07:58:38 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: holger.metschulat@telekom.de
In-Reply-To: <AFAB9759B1DE4F4187483FC509B50199011699555191@HE111490.emea1.cds.t-internal.com>
Message-ID: <alpine.DEB.2.02.1311140756400.5805@uplift.swm.pp.se>
References: <97EB7536A2B2C549846804BBF3FD47E1237E18A6@xmb-aln-x02.cisco.com> <alpine.DEB.2.02.1311050329470.26054@uplift.swm.pp.se> <97EB7536A2B2C549846804BBF3FD47E1237E1941@xmb-aln-x02.cisco.com> <CAM+vMES=xhq7VF8SvqEZEz3ZCRN8p1zWiabkNnU6ucKVya6KQQ@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303A137B3@UK30S005EXS06.EEAD.EEINT.CO.UK> <20131108172730.GM81676@Space.Net> <alpine.DEB.2.02.1311090926500.26054@uplift.swm.pp.se> <20131109132552.GQ81676@Space.Net> <6536E263028723489CCD5B6821D4B21303A157F2@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAM+vMET6mqVQOm4GVnfkvNEGYuVSvTBVnrPOgFvj86Kmx8rnfw@mail.gmail.com> <20131111145452.GF81676@Space.Net> <AFAB9759B1DE4F4187483FC509B50199011699555191@HE111490.emea1.cds.t-internal.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
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: Thu, 14 Nov 2013 06:58:56 -0000

On Thu, 14 Nov 2013, holger.metschulat@telekom.de wrote:

> this needs to be resolved in the provider's network by applying DNS64 
> only to those UE that have an IPv6-only connection. Usually, IPv6-only 
> connectivity means a separate APN with a dedicated IPv6 pool, so either 
> IPv4 and IPv4v6 UE get a different DNS server than the IPv6-only UE, or 
> the DNS server is the same and it can deduce from the client's IPv6 
> address whether it's an IPv4v6 or and IPv6-only client.

I oppose this reasoning. It brings in unneeded complexity in the mobile 
core network to handle all this logic, and besides, customers should be 
able to choose if they want IPv4v6 or IPv6 only, meaning you don't know in 
advance.

It's beneficial if standards allow for less complexity in backend systems. 
Complex backend systems is less problem for huge ISPs, but it is for 
smaller ones. Also, even huge ISPs benefit from less complexity in their 
backend systems.

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