[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
v6 considered operational
- To: firstname.lastname@example.org
- Subject: v6 considered operational
- From: Randy Bush <email@example.com>
- Date: Wed, 14 Aug 2002 08:23:41 -0700
- Delivery-date: Wed, 14 Aug 2002 08:23:51 -0700
- Envelope-to: firstname.lastname@example.org
[ for the record, reposted to v6ops ]
it is time for ngtrans to declare victory . 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  as ipv6 spreads through the ietf
culture. and it is high time it spread through our technology
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.
 - 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 . hence the use of the first
 - 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
 - see <http://www.cs.uni.edu/~wallingf/personal/bokonon.html>.
IPv6 Operations (v6ops)
Margaret Wasserman <email@example.com>
Jun-Ichiro itojun Hagino <firstname.lastname@example.org>
Operations and Management Area Director(s):
Randy Bush <email@example.com>
Bert Wijnen <firstname.lastname@example.org>
Operations and Management Area Advisor:
Randy Bush <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: Send mail to email@example.com, with "subscribe
v6ops" (no quotes) in the body of the message.
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
(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
(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
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>
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)