v6 considered operational

[Randy Bush <randy@psg.com>]

[ for the record, reposted to v6ops ]

it is time for ngtrans to declare victory [0].  ngtrans has come
up with many tools, even more than were expected.  but, as we saw
in yokohama, v6 is here.  wgs don't go on forever.  it is time to
declare victory for ngtrans and move forward.

we now have to operate the combined net.  this is a different job
than tool development, and should have a new, more operationally
oriented working group.  new tools that are found necessary by the
operational and user communities should be developed in the
appropriate protocol wgs [1] as ipv6 spreads through the ietf
culture.  and it is high time it spread through our technology
and culture.

hence it is planned for ngtrans be closed and a new group, v6ops,
be chartered.  i have appended a proposed charter for v6ops.  your
comments would be appreciated.

a number of high-order goals drove the decision to do it this way.

  o as we saw in yokohama, v6 is deploying today.  it has become a
    matter of operational concern, and not a guess as to what will
    be needed if it ever is deployed.  we need to think of it this
    way ourselves, and the world has to know it (think press, etc)

  o v6 has been hiding in a corner of the ietf.  with v6ops, we
    hope to drive problems and tasks out into the appropriate wgs,
    e.g. dns to dnsop and dnsext, mail to apps, etc.

  o we hope to make a sufficiently clean break that all documents
    would be evaluated on their technical and operational merit,
    without historical baggage good or bad.

ngtrans did a great job preparing for the future.  but the
combined v4/v6 network is no longer the future, it is today.  now
we need to move on to operate it compatibly with the v4 network.
welcome v6ops.

randy

---

[0] - while a number of other iesg members and non-i* folk have
      helped work this out, i an the area director and will take
      any resulting pool-pah [2].  hence the use of the first
      person.

[1] - iff the appropriate protocol wg can not be found, then v6ops
      may take on the work itself.  but this is not the preferred
      mode.  this does not imply spinning up new wgs to do new
      tool projects.

[2] - see <http://www.cs.uni.edu/~wallingf/personal/bokonon.html>.

---

IPv6 Operations (v6ops)  

Chair(s):
  Margaret Wasserman <mrw@windriver.com>
  Jun-Ichiro itojun Hagino <itojun@iijlab.net>

Operations and Management Area Director(s):
  Randy Bush <randy@psg.com>
  Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor: 
  Randy Bush <randy@psg.com>

Mailing Lists: 
  General Discussion: v6ops@ops.ietf.org
  To Subscribe: Send mail to majordomo@ops.ietf.org, with "subscribe
                v6ops" (no quotes) in the body of the message.
  Archive: <http://ops.ietf.org/lists/v6ops/>
           <ftp://ops.ietf.org/pub/lists/v6ops.*>

Description of Working Group: 

The global deployment of IPv6 is underway, creating an IPv4/IPv6
Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and
nodes.  This deployment must be properly handled to avoid the division
of the Internet into separate IPv4 and IPv6 networks while ensuring
global addressing and connectivity for all IPv4 and IPv6 nodes.

The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides guidance for
network operators on how to deploy IPv6 into existing IPv4-only
networks, as well as into new network installations.

The v6ops working group will:

(1) Solicit input from network operators and users to identify
    operational or security issues with the IPv4/IPv6 Internet, and
    determine solutions or workarounds to those issues.  This includes
    identifying standards work that is needed in the IPv6 WG or in other
    IETF WGs or areas and working with those groups/areas to begin
    appropriate work.  These issues will be documented in Informational
    or BCP RFCs, or in Internet-Drafts.

(2) Provide feedback to the IPv6 WG regarding portions of the IPv6
    specifications that cause, or are likely to cause, operational or
    security concerns, and work with the IPv6 WG to resolve those
    concerns.  This feedback will be published in Internet-Drafts or
    RFCs.

(3) Publish Informational RFCs that help application developers (within
    and outside the IETF) understand how to develop IP version-
    independent applications.  Work with the Applications area, and
    other areas, to ensure that these documents answer the real-world
    concerns of application developers.  This includes helping to
    identify IPv4 dependencies in existing IETF application protocols
    and working with other areas and/or groups within the IETF to
    resolve them.

(4) Produce Informational or BCP RFCs that help network operators
    understand and avoid common operational and security issues
    encountered in IPv6-only and shared IPv4/IPv6 networks.

(5) Publish Informational or BCP RFCs that identify potential security
    risks in the operation of shared IPv4/IPv6 networks, and document
    operational practices to eliminate or mitigate those risks.  This
    work will be done in cooperation with the Security area and other
    relevant areas or working groups.

(6) Publish Informational or BCP RFCs that provide viable solutions for
    deploying IPv6 within common network environments, such as ISP
    Networks (including Core, HFC/Cable, DSL & Dial-up networks),
    Enterprise Networks, Unmanaged Networks (Home/Small Office), and
    Cellular Networks.

    These documents should serve as useful guides to network operators
    and users on how to deploy IPv6 within their existing IPv4 networks,
    as well as in new network installations.

(7) Assume responsibility for advancing the basic IPv6 transition
    mechanism RFCs along the standards track, if their applicability to
    common deployment solutions is demonstrated in (6) above:

    Transition Mechanisms (RFC 2893)
    SIIT (RFC 2765)
    NAT-PT (RFC 2766)
    6to4 (RFC 3056 & 3068)

    This includes updating these mechanisms, as needed, to resolve
    problems.  In some cases, these mechanisms may be deprecated
    (i.e. moved to Historic), if they are not found to be applicable to
    the deployment solutions described in (6) or if serious flaws are
    encountered that lead us to recommend against their use.
        
(8) Identify open operational or security issues with the deployment
    solutions documented in (6) and fully document those open issues in
    Internet-Drafts or Informational RFCs.  The v6ops group will also
    work to find workarounds or solutions to basic, IP-level deployment
    issues that can be solved using widely-applicable transition
    mechanisms, such as dual-stack, tunneling or translation.

    In the event that resolution of an open issue requires the
    standardization of an additional, widely-applicable transition
    mechanism, the v6ops group will work with our ADs to determine
    whether to undertake that work within v6ops.

IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
the groups or areas responsible for those protocols or technologies.
However, the v6ops group will provide input to those areas/groups, as
needed, and cooperate with those areas/groups in developing and
reviewing solutions to IPv6 operational and deployment problems.


Goals and Milestones:

Aug 02   Publish Cellular Deployment Scenarios as a WG I-D
Aug 02   Publish Unmanaged Network Deployment Scenarios as a WG I-D
Aug 02   Publish ISP Deployment Scenarios as a WG I-D
Aug 02   Publish Cellular Deployment Solutions as a WG I-D
Sep 02   Publish Unmanaged Network Deployment Solutions as a WG I-D
Sep 02   Publish Enterprise Deployment Scenarios as a WG I-D
Oct 02   Publish ISP Deployment Solutions as a WG I-D
Oct 02   Submit Transition Mechanisms (Dual Stack & 6over4) to IESG for DS
Nov 02   Publish Enterprise Deployment Solutions as a WG I-D
Dec 02   Submit Cellular Deployment Scenarios to IESG for Info
Dec 02   Submit Cellular Deployment Solutions to IESG for Info
Feb 03   Submit Unmanaged Network Deployment Scenarios to IESG for Info
Feb 03   Submit Unmanaged Network Deployment Solutions to IESG for Info
Mar 03   Submit ISP Deployment Scenarios to IESG for Info
Mar 03   Submit ISP Deployment Solutions to IESG for Info
Apr 03   Submit Enterprise Deployment Scenarios to IESG for Info
Apr 03   Submit Enterprise Deployment Solutions to IESG for Info 

<More goals need to be added after consultation with authors/others>

Internet-Drafts: 

Request For Comments: 

Network Address Translation-Protocol Translation (NAT-PT) (RFC 2766)
Stateless IP/ICMP Translation Algorithm (SIIT) (RFC 2765)
Transition Mechanisms for IPv6 Hosts and Routers (RFC 2893) 
Connection of IPv6 Domains via IPv4 Clouds (RFC 3056)
An anycast prefix for 6to4 relay routers (RFC 3068)

-30-