IETF Logo Mail Archive

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

<holger.metschulat@telekom.de> Wed, 20 November 2013 07:53 UTC

Return-Path: <holger.metschulat@telekom.de>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26521AC4C1 for <v6ops@ietfa.amsl.com>; Tue, 19 Nov 2013 23:53:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.075
X-Spam-Level:
X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScufHocIjeWH for <v6ops@ietfa.amsl.com>; Tue, 19 Nov 2013 23:53:31 -0800 (PST)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABA31AE17E for <v6ops@ietf.org>; Tue, 19 Nov 2013 23:53:30 -0800 (PST)
From: holger.metschulat@telekom.de
Received: from he111493.emea1.cds.t-internal.com ([10.206.92.96]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 20 Nov 2013 08:53:23 +0100
Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE111493.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 20 Nov 2013 08:53:22 +0100
To: swmike@swm.pp.se
Date: Wed, 20 Nov 2013 08:53:23 +0100
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt
Thread-Index: Ac7hBvNb2G3OI+r/R3q0cwKj0TMpSQES9Ddg
Message-ID: <AFAB9759B1DE4F4187483FC509B501990116996E9FB3@HE111490.emea1.cds.t-internal.com>
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> <alpine.DEB.2.02.1311140756400.5805@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1311140756400.5805@uplift.swm.pp.se>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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.15
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: Wed, 20 Nov 2013 07:53:34 -0000

Hello Mikael,

I agree, but are there any other choices? 

One could argue that the UE is responsible by itself to use NAT64 correctly when attaching to an IPv6-only context, e.g. by performing automatic NAT64 prefix detection and performing DNS64 internally (which would have the benefit to work with DNSSEC) in addition to 464Xlat.

Holger

-----Ursprüngliche Nachricht-----
Von: Mikael Abrahamsson [mailto:swmike@swm.pp.se] 
Gesendet: Donnerstag, 14. November 2013 07:59
An: Metschulat, Holger
Cc: gert@space.net; phdgang@gmail.com; v6ops@ietf.org
Betreff: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

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

v2.23.0 | Report a Bug | By Email