(ngtrans) proposal for a revised NGtrans charter

Alain Durand <alain.durand@sun.com> Wed, 05 December 2001 19:07 UTC

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03157 for <ngtrans-archive@odin.ietf.org>; Wed, 5 Dec 2001 14:07:05 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23829; Wed, 5 Dec 2001 12:05:06 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21520; Wed, 5 Dec 2001 11:05:11 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5J4jHt011062 for <ngtrans-dist@sunroof.eng.sun.com>; Wed, 5 Dec 2001 11:04:45 -0800 (PST)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5J4jF3011061 for ngtrans-dist; Wed, 5 Dec 2001 11:04:45 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ngtrans@sunroof.eng.sun.com using -f
Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5J4fHt011054 for <ngtrans@sunroof.eng.sun.com>; Wed, 5 Dec 2001 11:04:41 -0800 (PST)
Received: from marlin.sun.com (vpn-129-150-5-71.EBay.Sun.COM [129.150.5.71]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5J4b4W205187; Wed, 5 Dec 2001 11:04:40 -0800 (PST)
Message-Id: <5.1.0.14.0.20011205105744.07832e08@jurassic.eng.sun.com>
X-Sender: durand@jurassic.eng.sun.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 05 Dec 2001 11:05:40 -0800
To: ngtrans@sunroof.eng.sun.com
From: Alain Durand <alain.durand@sun.com>
Subject: (ngtrans) proposal for a revised NGtrans charter
Cc: Randy Bush <randy@psg.com>, bwijnen@lucent.com, fink@es.net, tony Hain <tony@tndh.net>, alain.durand@sun.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: Alain Durand <alain.durand@sun.com>

Hi folks,

To prepare our Friday meeting in Salt Lake City, we, chairs,
have been working on a proposal for a revised charter
for our working group.

Please read it in preparation of the meeting as we will base
the discussion on it.

	- Alain/Bob/Tony.


            Next Generation Transition Working Group (NGtrans)


Chair(s):

    Alain Durand <Alain.Durand@sun.com>
    Bob Fink <fink@es.net>
    Tony Hain <tony@tndh.net>

Document Editor:

    Bob Fink <fink@es.net>

Operations & Management Area Director(s):

    Randy Bush <randy@psg.com>
    Bert Wijnen <bwijnen@lucent.com>

Operations & Management Area Advisor:

    Randy Bush <randy@psg.com>

Mailing Lists:

    General Discussion: ngtrans@sunroof.eng.sun.com
    To Subscribe: majordomo@sunroof.eng.sun.com
    In Body: in body: subscribe ngtrans
    Archive: ftp://playground.sun.com/pub/ngtrans/mail-archive

Web Pages:

    Charter: http://www.ietf.org/html.charters/ngtrans-charter.html
    Working group info: http://6bone.com/ngtrans/

Background:

    IP version 6 or IPv6 (also formerly known as IP Next Generation or
    IPng) is intended to support the continued growth of the Internet,
    both in size and capabilities, by offering a greatly increased IP
    address space and other enhancements over IPv4. The IP Next
    Generation Transition (NGtrans) working group was originally
    chartered by the IESG to specify the tools and mechanisms that might
    be used for transition to IPv6. In addition, it was chartered to
    write documents outlining how the various transition tools and
    mechanisms might apply to various scenarios for a transition to IPv6.
    After the original NGtrans was chartered, the 6bone IPv6 Testbed was
    created in 1996. Coordinating transition efforts with the 6bone to
    foster the development, testing, and deployment of IPv6 was then
    added to the NGtrans charter.

    Many tasks of the original charter have been completed, and several
    core IPv6 transition protocol specifications are now on the IETF
    standards track.  In addition numerous Informational RFCs have been
    created that are, in varying degrees, applicable to transition goals.

    This charter focuses on completing the remaining work items deemed
    most essential to transition, while still not shutting the door on
    new ideas that may provide new insight into transition.

Work plan:

    The goals of the NGtrans working group are:

    - Document operational requirements and recommended practises for
    major pieces of the Internet infrastructure in a mixed world of IPv4
    only, IPv6 only and dual stack nodes.  Those pieces include, but are
    not limited to:  Routing, DNS, Mail, Network monitoring, Web,
    Multicast, VoIP,...
    This work is to be done in cooperation with the relevant experts
    and/or the relevant working groups when applicable.

    - Serve as a review board and body of competence and coordination for
    IPv6 transition and operational issues that span multiple IETF
    working groups.  This includes providing technical input to the
    IESG/IAB, IANA, the Internet Address Registries and operational
    communities, with regard to IPv6 transition and operation related
    issues, e.g., address allocation policies and procedures and
    operational management mechanisms.

    - Coordinate with the IPv6 6bone testbed, operating under the IPv6
    Testing Address Allocation allocated in Experimental RFC 2471, to
    foster the development, testing, and deployment of IPv6.

    - Keep all IPv6 transition tool documents moving along publication /
    standardization track. Those tools enable transition to a mixed world
    of IPv4 only, IPv6 only and dual stack nodes. They falls into three
    categories:
       - dual-stack tools which assure that both protocols are supported
       equally throughout the infrastructure.
       - tunneling tools to enable IPv6 island to communicate over an
       IPv4 infrastructure
       - translation tools that enable communication between IP4 and IPv6
       nodes.  As a large number of tools are already documented, new
       tools would have to justify the problem space they are solving
       that is not already addressed by existing tools/mechanisms.

    - Document how to use those tools in major transition scenarios and
    document how those tools interact together.

    The non goals of this working group are:

    - Define extensions to IPv6. this is done in the ipv6 working group.

    - Develop multi-homing solutions. This is done in the multi6 working
    group.

    - Define particular extensions for IPv6 to existing Internet
    protocols. This is done in the relevant working groups.

    - Define or document tools/mechanisms/scenarios that are only
    applicable to very specific environment and are not representative
    enough of a wide community.

The list of the working group's current work items is as follows:

    - Revise and advance to Draft Standard the basic Transition Mechanism
    (MECH) document [RFC 2893]
    - Revise and advance to Draft Standard the Stateless IP/ICMP
    Translator (SIIT) document [RFC 2765]
    - Revise and advance to Draft Standard the Network Address
    Translation - Protocol Translation (NAT-PT) document [RFC 2766]
    - Revise and advance to Draft Standard the Connection of IPv6 Domains
    via IPv4 Clouds (6to4) document [RFC 3056]
    - Revise and advance to Draft Standard the An anycast prefix for 6to4
    relay routers (6to4-ANYCAST) document [RFC 3068]
    - Complete work on the Intra-Site Automatic Tunnel Addressing
    Protocol (ISATAP) document and move to Proposed Standard
    - Complete work on the Short term NAT requirements for IPv6
    transition (NATREQ4IPv6) document and move to Proposed Standard
    - Complete work on the Tunneling IPv6 over UDP through NATs
    (SHIPWORM) document and move to Proposed Standard
    - Complete work on the 6to4 and DNS (6to4-DNS) document and move to
    Proposed Standard
    - Complete work on the Support for Multicast over 6to4 Networks
    (6to4-MULTICAST) document and move to Proposed Standard
    - Complete work on the MIME TYPE Definition for Tunnels (MIME-TYPE)
    document and move to Proposed Standard
    - Complete work on the Dual Stack Transition Mechanism (DSTM)
    document and move to Proposed Standard
    - Complete work on the Dual Stack Transition Mechanism Extensions-1
    (DSTMEXT1-AIIH) document and move to Proposed Standard
    - Complete work on the Extensions to SIIT and DSTM for enhanced
    routing of inbound packets (SIIT-DSTM) document and move to Proposed
    Standard
    - Complete work on the Dual Stack deployment using DSTM and 6to4
    (6to4-DSTM) document and move to Informational RFC
    - Complete work on the Connecting IPv6 Domains across IPv4 Clouds
    with BGP (BGP-TUNNEL) document and move to Informational RFC
    - Complete work on the Dual Stack Hosts using "Bump-in-the-API" (BIA)
    document and move to Informational RFC
    - Complete work on the IPv6 DNS Operational Requirements (DNS-OPS-
    REQ) document and move to Informational RFC
    - Complete work on the IPv6 over IPv4 tunnels for home to Internet
    access (HOMETUN) document and move to Informational RFC
    - Complete work on the Interaction of transition mechanisms
    (INTERACTION) document and move to Informational RFC
    - Complete work on the Survey of IPv4 Addresses in Currently Deployed
    IETF Standards (IPV4SURVEY) document and move to Informational RFC
    - Complete work on the IPv6 SMTP Requirement (IPv6-SMTP-REQUIREMENT)
    document and move to Informational RFC
    - Complete work on the Moving in a Dual Stack Internet (MOVING)
    document and move to Informational RFC
    - Complete work on the An IPv6/IPv4 Multicast Translator based on
    IGMP/MLD Proxying (MTP) document and move to Informational RFC
    - Complete work on the A Guide to the Introduction of IPv6 in the
    IPv4 World (TRANSITION) document and move to Informational RFC

    New work items not listed above require the approval of the working
    group and Internet Area directors before they will be taken on by the
    working group.

    Priority will be given to work items that will most broadly affect
    the transition and coexistence of IPv6 and IPv4 in the global
    Internet.  It is expected that now the focus of the working group
    will shift from tools and mechanisms to actual plans to transition
    the most important pieces of the Internet infrastructure to a world
    of coexistence of IPv4 & IPv6.

Goals and Milestones:

     Dec 2001 XXXX