IETF Logo Mail Archive

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

<holger.metschulat@telekom.de> Sat, 30 November 2013 22:54 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 057371AE4A1 for <v6ops@ietfa.amsl.com>; Sat, 30 Nov 2013 14:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level:
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] 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 1rErnXlOU_Lm for <v6ops@ietfa.amsl.com>; Sat, 30 Nov 2013 14:54:07 -0800 (PST)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6571AE4A0 for <v6ops@ietf.org>; Sat, 30 Nov 2013 14:54:06 -0800 (PST)
From: holger.metschulat@telekom.de
Received: from he113497.emea1.cds.t-internal.com ([10.206.92.154]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 30 Nov 2013 23:54:04 +0100
Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE113497.emea1.cds.t-internal.com ([::1]) with mapi; Sat, 30 Nov 2013 23:54:03 +0100
To: swmike@swm.pp.se
Date: Sat, 30 Nov 2013 23:54:03 +0100
Thread-Topic: AW: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt
Thread-Index: Ac7lx8czE5p1+Ck6TcO9MHrmE3WUVgHVeF+w
Message-ID: <AFAB9759B1DE4F4187483FC509B501990116999AFA14@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> <AFAB9759B1DE4F4187483FC509B501990116996E9FB3@HE111490.emea1.cds.t-internal.com> <alpine.DEB.2.02.1311200904140.1157@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1311200904140.1157@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: Sat, 30 Nov 2013 22:54:10 -0000

Hi Mikael,

sorry for the late reply. 

What I am thinking: Should the network be set up to offer an unabiguous access method to the end device , or should the end device be able to detect the "Internet Access toolset" (public IPv4, private IPv4 with NAT, NAT64, native IPv6) that the network it is connected to offers and pick the most appropriate methods by itself?

I am fearing that we get into a similar trouble as with SIP when using NAT/PAT, which failed because the client, NAT gateway and/or SIP server tried to fix the NAT/PAT translation in SIP signalling sometimes by only by "guessing"?

Holger

-----Ursprüngliche Nachricht-----
Von: Mikael Abrahamsson [mailto:swmike@swm.pp.se] 
Gesendet: Mittwoch, 20. November 2013 09:09
An: Metschulat, Holger
Cc: v6ops@ietf.org
Betreff: Re: AW: [v6ops] I-D Action: draft-ietf-v6ops-nat64-experience-04.txt

On Wed, 20 Nov 2013, holger.metschulat@telekom.de wrote:

> I agree, but are there any other choices?

We could provide the problem case and have "someone" develop standards to fix it? I think it's a pretty common case going forward that the network supports a combination of IPv4, DS and IPv6 devices being connected even to a wifi network or LAN (not necessarily mobile). Then one doesn't have the choice to have different APNs.

One way would be to have a recommendation to detect NAT64 and then detect NAT44, and in the case of both being present, prefer one of them consistently?

Hardest case to handle would be GUA IPv4 and IPv6 with NAT64, then there would have to be heuristics to actively detect the DNS64 doing A->AAAA and not use the AAAA pointing to the NAT64 prefix, but instead use A records for those.... if that's what we want.

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

v2.23.0 | Report a Bug | By Email