Subject: It's a WG!

From: Margaret Wasserman <[email-masked]>
Date: Sun, 08 Sep 2002 20:18:35 -0400

Hi All,

Our WG was chartered by the IESG last Thursday.  The official announcement
will probably go to the ietf-announce list on Monday.

So, we are now officially a working group.  I have appended the approved
charter below.

Thanks to all who provided input during the charter process!

Margaret

IPv6 Operations (v6ops)  

Chair(s):
Jun-Ichiro itojun Hagino <[email-masked]>
Margaret Wasserman <[email-masked]>

Operations and Management Area Director(s):
Randy Bush <[email-masked]>
Bert Wijnen <[email-masked]>

Operations and Management Area Advisor: 
Randy Bush <[email-masked]>

Mailing List: 
General Discussion:  [email-masked]
To Subscribe:        Send mail to [email-masked], 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 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.

	For example, important pieces of the Internet infrastructure 
	such as DNS, SMTP and SIP have specific operational issues when 
	they operate in a shared IPv4/IPv6 network. The v6ops WG will 
	cooperate with the relevant areas and WGs to document those 
	issues, and find protocol or operational solutions to those 
	problems.

(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) 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.

(5) 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.

(6) Assume responsibility for advancing the basic IPv6 transition 
	mechanism RFCs along the standards track, if their applicability 
	to common deployment solutions is demonstrated in (5) 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 (5) or if serious flaws 
	are encountered that lead us to recommend against their use.
	
(7) Identify open operational or security issues with the deployment 
	solutions documented in (5) and fully document those open 
	issues in Internet-Drafts or Informational RFCs.  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.

	If the satisfactory resolution of a deployment issue requires
	the standardization of a new, widely-applicable transition
	mechanism that does not properly fit into any other IETF WG or
	area, the v6ops WG will standardize a transition mechanism
	to meet that need.

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:

OCT 02   Publish Cellular Deployment Scenarios as a WG I-D
OCT 02   Publish Unmanaged Network Deployment Scenarios as a WG I-D
OCT 02   Publish ISP Deployment Scenarios as a WG I-D
OCT 02   Publish Cellular Deployment Solutions as a WG I-D
OCT 02   Publish Survey of IPv4 Addresses in IETF Standards as WG I-D
DEC 02   Submit Transition Mechanisms to IESG for DS
DEC 02   Publish Unmanaged Network Deployment Solutions as a WG I-D
DEC 02   Publish Enterprise Deployment Scenarios as a WG I-D
DEC 02   Publish ISP 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 BCP
FEB 03   Submit Survey of IPv4 Addresses in IETF Standards to IESG for Info
APR 03   Publish Enterprise Deployment Solutions as a WG I-D
APR 03   Submit Unmanaged Network Deployment Scenarios to IESG for Info
APR 03   Submit Unmanaged Network Deployment Solutions to IESG for BCP
APR 03   Submit ISP Deployment Scenarios to IESG for Info
APR 03   Submit ISP Deployment Solutions to IESG for BCP
AUG 03   Submit Enterprise Deployment Scenarios to IESG for Info
AUG 03   Submit Enterprise Deployment Solutions to IESG for BCP 

Internet-Drafts: 

Request For Comments: 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Sep 2002 09:28:15 +0200

As I noted earlier, some 6to4 related drafts need to be
transferred over:

> There's work in progress on 6to4 DNS, 6to4 multicast,
> and 6to4 security that needs to be picked up...

> draft-ietf-ngtrans-6to4-dns-01.txt (expired, but something's needed)
> draft-ietf-ngtrans-6to4-multicast-01.txt
> draft-savola-ngtrans-6to4-security-01.txt (no consensus yet, but needed)

    Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 09 Sep 2002 08:44:30 -0400

Hi Brian,

Thanks for the reminder.  I must have forgotten to reply to this
the first time...

To accept any draft as a v6ops WG work item will be a two-step process.
First, itojun and I need to decide whether the draft fits into the
v6ops charter.  If so, the WG will then need to decide whether or not
to accept the draft as a work item.

I am sure that several ngtrans drafts (possibly including the ones
you've listed) will be accepted as v6ops WG items.  But, it may take
a week or two to go through the process.

Margaret