[v4v6interim] Questions for the group

Ed Jankiewicz <edward.jankiewicz@sri.com> Fri, 03 October 2008 15:28 UTC

Return-Path: <v4v6interim-bounces@ietf.org>
X-Original-To: v4v6interim-archive@ietf.org
Delivered-To: ietfarch-v4v6interim-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC43128C27D; Fri, 3 Oct 2008 08:28:56 -0700 (PDT)
X-Original-To: v4v6interim@core3.amsl.com
Delivered-To: v4v6interim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0644528C27D for <v4v6interim@core3.amsl.com>; Fri, 3 Oct 2008 08:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.019
X-Spam-Level:
X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 1NFuLFM9q8QH for <v4v6interim@core3.amsl.com>; Fri, 3 Oct 2008 08:28:50 -0700 (PDT)
Received: from mailgate-internal4.sri.com (mailgate-internal4.SRI.COM [128.18.84.114]) by core3.amsl.com (Postfix) with SMTP id 720D828C1FC for <v4v6interim@ietf.org>; Fri, 3 Oct 2008 08:28:50 -0700 (PDT)
Received: from smssmtp-internal2.sri.com (128.18.84.116) by mailgate-internal4.sri.com with SMTP; 3 Oct 2008 15:28:44 -0000
X-AuditID: 80125474-ab196bb000000a40-c8-48e63a2b335d
Received: from srimail1.sri.com (srimail1.SRI.COM [128.18.30.11]) by smssmtp-internal2.sri.com (Symantec Mail Security) with ESMTP id E525521AF2D for <v4v6interim@ietf.org>; Fri, 3 Oct 2008 08:28:43 -0700 (PDT)
Received: from [192.168.2.101] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K86004875NUSM58@mail.sri.com> for v4v6interim@ietf.org; Fri, 03 Oct 2008 08:28:43 -0700 (PDT)
Date: Fri, 03 Oct 2008 11:28:46 -0400
From: Ed Jankiewicz <edward.jankiewicz@sri.com>
To: v4v6interim@ietf.org
Message-id: <48E63A2E.6080804@sri.com>
MIME-version: 1.0
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
X-Brightmail-Tracker: AAAAAA==
Subject: [v4v6interim] Questions for the group
X-BeenThere: v4v6interim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of coexistence topics for the 01-Oct-2008 v4-v6 coexistence interim meeting <v4v6interim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/v4v6interim>
List-Post: <mailto:v4v6interim@ietf.org>
List-Help: <mailto:v4v6interim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

due to travel constraint I ran out before the final poll.  for the 
record, here is my response to what I think the scenarios ended up 
being, and the questions on the floor.  Caveat:  while I am answering in 
the context of my understanding/interpretation of the needs of the 
organization I support, the opinions are mine, not those of my employer 
or customer.  By "core" I mean the major enterprise networks and 
backbones that US DoD will be running.   For the translation scenarios, 
"my IPv4-only network" e.g. may be a subset.  Also note, as I stated at 
the meeting, solutions space needs to consider where the constraint is - 
either the application, host or "my network" supports only 1 address 
family - and I believe the translation discussion should be centered on 
application and host-stack adaptation.  Other techniques can satisfy the 
"my network" only carries one address family.

Scenario 1: IPv4 sites reaching the global IPv4 Internet?

    Q) do you have to cope today?
    A) right now, dual-stack core adequately meets this need.

    Q) do you think you may have to cope in the future?
    A) potentially.  Several policy documents and business case for IPv6 
assume that operational cost will be incentive to turn off IPv4 routing 
in the core, so tunneling solutions will be needed

    Q) Should IETF invest cycles in defining this scenario and 
developing solutions?
    A) Yes. 

Scenario 2: Providers running out of private IPv4 space?

    Q) do you have to cope today?
    A) no.

    Q) do you think you may have to cope in the future?
    A) no.

    Q) Should IETF invest cycles in defining this scenario and 
developing solutions?
    A) Yes. 

Scenario 3: My IPv6-only network to Global IPv4 Internet?

    Q) do you have to cope today?
    A)  only in experimental context.  There is some irrational 
resistance to IPv6 adoption due to FUD about losing access to the IPv4 
Internet.

    Q) do you think you may have to cope in the future?
    A) potentially.  If IPv4 routing is turned off in parts of the core, 
these are equivalent to an IPv6-only network.  Also, some constituents 
are very interested in tactical networks taking advantage of new work in 
IPv6 mobility not available in IPv4; this may result in greenfield 
IPv6-only deployments.  Maintaining "access to the global IPv4 Internet" 
would be desirable.

    Q) Should IETF invest cycles in defining this scenario and 
developing solutions?
    A) Yes. 

Scenario 4:  Global IPv6 Internet to My IPv4-only network?

    Q) do you have to cope today?
    A) Yes, in development, testing and experimental contexts.

    Q) do you think you may have to cope in the future?
    A) absolutely.  large existing base of networked equipment with long 
anticipated lifespan that is IPv4-only.

    Q) Should IETF invest cycles in defining this scenario and 
developing solutions?
    A) Yes.  And I intend to contribute in this area.

Scenario 5: Global IPv4 Internet to My IPv6-only network?

    Q) do you have to cope today?
    A) Only in experimental context.

    Q) do you think you may have to cope in the future?
    A) potentially, see Scenario 3.

    Q) Should IETF invest cycles in defining this scenario and 
developing solutions?
    A) Yes. 

Scenario 6: My IPv4-only network to global IPv6 Internet?

    A) Yes, in development, testing and experimental contexts.

    Q) do you think you may have to cope in the future?
    A) absolutely.  large existing base of networked equipment with long 
anticipated lifespan that is IPv4-only.

    Q) Should IETF invest cycles in defining this scenario and 
developing solutions?
    A) Yes.  And I intend to contribute in this area.

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  ed.jankiewicz@sri.com 

_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim