IETF Logo Mail Archive

Re: [v6ops] new draft: draft-byrne-v6ops-clatip

<holger.metschulat@telekom.de> Fri, 25 October 2013 13:04 UTC

Return-Path: <holger.metschulat@telekom.de>
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 0A7D511E83E0 for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2013 06:04:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 a7C5TO9U0ws3 for <v6ops@ietfa.amsl.com>; Fri, 25 Oct 2013 06:04:16 -0700 (PDT)
Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7A58511E831D for <v6ops@ietf.org>; Fri, 25 Oct 2013 06:04:12 -0700 (PDT)
From: holger.metschulat@telekom.de
Received: from he111510.emea1.cds.t-internal.com ([10.206.92.113]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 25 Oct 2013 15:04:10 +0200
Received: from HE111490.emea1.cds.t-internal.com ([10.206.92.87]) by HE111510.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 25 Oct 2013 15:04:10 +0200
To: v6ops@ietf.org
Date: Fri, 25 Oct 2013 15:04:09 +0200
Thread-Topic: [v6ops] new draft: draft-byrne-v6ops-clatip
Thread-Index: Ac7Gf9DowRmN9HMfSWCYX3uNm9/78gKya7pw
Message-ID: <AFAB9759B1DE4F4187483FC509B50199011699077A4C@HE111490.emea1.cds.t-internal.com>
References: <201310111245.r9BCj0319881@ftpeng-update.cisco.com>
In-Reply-To: <201310111245.r9BCj0319881@ftpeng-update.cisco.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: draft-byrne-v6ops-clatip@tools.ietf.org
Subject: Re: [v6ops] new draft: draft-byrne-v6ops-clatip
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: Fri, 25 Oct 2013 13:04:21 -0000

Hi all,

I think this is a valueable draft, making sure that the CLAT IP address is well-defined and does not collide with other use cases when using RFC1918 addresses as the CLAT IP address.

Some thoughts:

- Can we exclude that a UE is using CLAT and DS-Lite at the same time?
- Should we also nail down a specific IP address out of that range (e.g. 192.0.0.3) for the CLAT interface with the freedom to choose a different IP address out of that subnet if necessary?
- Some application implementations switch to "I am behind NAT mode" when seeing an RFC1918 address and behave differently than directly connected to the Internet without NAT. This (in my opinion) bad "NAT discovery" will not be triggered with this IP address range.
- The requirements towards the CLAT IPv4 address should be better described. In the draft, I read "locally unique IPv4 address" and "unique address" - should be worded like "IPv4 address that must be unique within the UE and must not be used by any host the UE may connect to".


My €0.01,

Holger

v2.23.0 | Report a Bug | By Email