[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