[v4tov6transition] comments on draft-lee-v4v6tran-problem-02
Jari Arkko <jari.arkko@piuha.net> Tue, 21 September 2010 02:09 UTC
Return-Path: <jari.arkko@piuha.net>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46503A68E6 for <v4tov6transition@core3.amsl.com>; Mon, 20 Sep 2010 19:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.439
X-Spam-Level:
X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbXNQxC0Glu9 for <v4tov6transition@core3.amsl.com>; Mon, 20 Sep 2010 19:09:14 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8EE753A68DB for <v4tov6transition@ietf.org>; Mon, 20 Sep 2010 19:09:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 55E032CC3C for <v4tov6transition@ietf.org>; Tue, 21 Sep 2010 05:09:36 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6052qfpUhHb for <v4tov6transition@ietf.org>; Tue, 21 Sep 2010 05:09:35 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 345A52CC30 for <v4tov6transition@ietf.org>; Tue, 21 Sep 2010 05:09:34 +0300 (EEST)
Message-ID: <4C9813DE.6040409@piuha.net>
Date: Mon, 20 Sep 2010 19:09:34 -0700
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: "v4tov6transition@ietf.org" <v4tov6transition@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [v4tov6transition] comments on draft-lee-v4v6tran-problem-02
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Sep 2010 02:09:15 -0000
Good questions; a lot of the answers I suppose are general purpose IPv6 deployment and addressing plan guidance. All these questions deserve documentation, while I suspect some of the material exists there's probably some that does not exist. It would be good for the document to review what guidance material already exists, however. I have two comments Section 2.2: it should also talk about how to deal with the residual problems where an IPv6-only model is chosen (as discussed in draft-arkko-ipv4-only-experience, there are issues with some applications, for instance). Secondly, to avoid this document becoming focused on general purpose network planning guidance, I would suggest that the IS-IS and OSPF questions be either framed as relating to support of IPv6, or removed. On Section 2.3, I'm not entirely sure that a high-availability switch from IPv6 to IPv4 or vice versa is a requirement. Sure, a nice thing to have, but in most networks that I can think of, if they need to available then both IPv4 and IPv6 parts need to be available. (Though in some cases you can simulate lack of IPv6 high-availability solution by falling back to IPv4. But my point is that there is no requirement that says high availability must be achieved in precisely this manner.) On Section 2.4, its not clear that a fully populated reverse DNS is required for all devices. Those devices that are servers tend to have DNS entries anyway, so lack of reverse DNS records for some other devices may not be a big problem. But I might be missing something. Section 3: this is precisely why we are talking about homegate/homenet WG in the IETF. On Section 4, I'd say that for some of these questions the answer may be "don't do that" in the general case (e.g., ipv6 only app talking to ipv4-only app) though some special cases may still work OK (e.g., web traffic through a NAT64 works fine even if all devices in the NAT64 network are IPv6 only and everyone else in the Internet is IPv4 only). Also: the best way to provide IPv4 access to applications in an IPv6-only network is to go back to a dual-stack network, or fix the remaining apps to work right. I'm not kidding. Some of the questions in Section 5 would be more about IPv4 large scale nat operational considerations than on IPv6 deployment. I think we should keep the two separated. I think the questions in Section 6 on security are at the wrong level. We don't ask about the security of IPv4, we ask about the security of application X, what our firewall can handle, etc. Those same questions exist in the IPv6 space, but probably there are many products that lack some security feature on the IPv6 side. The answer is that everyone must go through what they need and make sure their vendors provide the necessary support also in IPv6. Jari