2.4.15 IPv6 Operations (v6ops)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional V6OPS Web Page

Last Modified: 2005-01-24


Pekka Savola <pekkas@netcore.fi>
Jonne Soininen <jonne.Soininen@nokia.com>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Mailing Lists:

General Discussion: v6ops@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe v6ops
Archive: http://ops.ietf.org/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

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 identify and analyze
  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. Identify open operational or security issues with the deployment
  scenarios 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 operational
  or security issues that can be solved using widely-applicable
  transition mechanisms, such as dual-stack, tunneling or

  If the satisfactory resolution of an operational or security
  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.

7. Assume responsibility for advancing the basic IPv6 transition
  mechanism RFCs along the standards track, if their applicability
  to common deployment scenarios 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.

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:

Done  Publish Cellular Deployment Scenarios as a WG I-D
Done  Publish Unmanaged Network Deployment Scenarios as a WG I-D
Done  Publish Survey of IPv4 Addresses in IETF Standards as WG I-D
Done  Publish Cellular Deployment Solutions as a WG I-D
Done  Publish Unmanaged Network Deployment Solutions as a WG I-D
Done  Submit Cellular Deployment Scenarios to IESG for Info
Done  Submit Unmanaged Network Deployment Scenarios to IESG for Info
Done  Publish Enterprise Deployment Scenarios as a WG I-D
Done  Submit Survey of IPv4 Addresses in IETF Standards to IESG for Info
Done  Publish ISP Deployment & Solutions as a WG I-D
Done  Submit Cellular Deployment Solutions to IESG for Info
Done  Submit Transition Mechanisms to IESG for PS
Done  Submit IPv6 Neighbor Discovery On-Link Assumption to IESG for Info
Done  Submit Dual Stack IPv6 on by Default to IESG for Informational
Done  Submit Unmanaged Network Deployment Solutions to IESG for BCP
Done  Submit ISP Deployment Scenarios & Solutions to IESG for Info
Done  Submit Application Aspects of IPv6 Transition to IESG for Informational
Done  Submit 6to4 Security Analysis to IESG for Informational
Done  Submit Enterprise Deployment Scenarios to IESG for Info
Done  Submit Renumbering Procedures to IESG for Info
Aug 04  Submit Assisted Tunneling Requirements to IESG for Info
Sep 04  Publish Enterprise Deployment Solutions as a WG I-D
Dec 04  Submit IPv6-in-IPv4 Tunneling using IPsec to IESG for Info
Feb 05  Submit IPv6 Security Overview to IESG for Info
Feb 05  Submit Enterprise Deployment Solutions to IESG for BCP


  • draft-ietf-v6ops-3gpp-analysis-11.txt
  • draft-ietf-v6ops-mech-v2-06.txt
  • draft-ietf-v6ops-ent-scenarios-05.txt
  • draft-ietf-v6ops-v6onbydefault-03.txt
  • draft-ietf-v6ops-onlinkassumption-02.txt
  • draft-ietf-v6ops-isp-scenarios-analysis-03.txt
  • draft-ietf-v6ops-application-transition-03.txt
  • draft-ietf-v6ops-renumbering-procedure-04.txt
  • draft-ietf-v6ops-ent-analysis-01.txt
  • draft-ietf-v6ops-natpt-to-exprmntl-00.txt
  • draft-ietf-v6ops-bb-deployment-scenarios-00.txt

    Request For Comments:

    RFC3574 I Transition Scenarios for 3GPP Networks
    RFC3750 I Unmanaged Networks IPv6 Transition Scenarios
    RFC3789 I Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards
    RFC3790 I Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards
    RFC3791 I Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards
    RFC3792 I Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards
    RFC3793 I Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards
    RFC3794 I Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards
    RFC3795 I Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards
    RFC3796 I Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards
    RFC3904 I Evaluation of Transition Mechanisms for Unmanaged Networks
    RFC3964 I Security Considerations for 6to4

    Current Meeting Report

    Minutes of IPv6 Operations WG (v6ops)

    Wednesday, March 9 at 0900-1130

    CHAIRS: Pekka Savola <pekkas@netcore.fi>
    Soininen Jonne <jonne.soininen@nokia.com>
    - Scribes:
    Fred Baker
    Mikael Lind

    Introduction, agenda bashing, document status - 5 mins, Chairs/Savola
    - Scribes! (Jabber also?)

    no comments were logged against the agenda.

    The chair reviewed the status of a number of documents. This is displayed in the slides used during the meeting.

    Charter Discussion - 20 mins, Chairs/WG
    - discuss the pending charter update, if not finalized yet
    - GOAL: discuss the scope of v6ops WG work; gain consensus on the way forward

    Kurtis Lindqvist presented a discussion of the proposed working group charter. This is discussed in the slides used during the meeting.

    Work has a tendency to drag. A statement in the charter gives to opportunity for the chairs to get rid of a topic. Hopefully things will go faster. Kurtis thinks the charter is fine and should be sent to David Kessens for AD processing.

    The key charter change from the working group discussion makes individual submissions to the working group into working group charter items earlier, rather than going through several iterations as individual submissions, resubmission as a working group item, and immediate approval.

    Enterprise Analysis Discussion, 15 mins, Bound(?)
    - draft-ietf-v6ops-ent-analysis-01.txt (or a revision?)
    - GOAL: discuss issues and the path forward

    Jim Bound discussed the status of the Enterprise Analysis discussion. This is under review by the IESG and has been held up in that dialog.

    Key changes include limiting the discussion to dual stack networks and nodes, and updating the matrix of common use cases. Discussion is limited to enterprise needs within the coming 18 months (2005 and 2006). Discussion of transport and higher layers and of multihoming was removed, as the application layer scenarios became complex.

    The reason is that there are few if any networks that are not being run at least partially using IPv4. There are a number of dual stack networks, and a number of networks that are using IPv4 only for internal management, but none that are literally IPv6-only.

    There needs to be further discussion of sections 3 and 5 of the draft. Section 6 needs work discussing the difference between "IPv6 only" and "IPv6 dominant". Serious work needs to be done in section 7. Section 8 was dropped, as it recommended transition mechanisms; it may be rewritten in a manner that makes no recommendations.

    The question Jim placed before the house is whether this document remains of interest to the working group, or should be replaced by documents such as the Japan IPv6 Promotional Council IPv6 Deployment Guide? The sense of the room was that the working group would review the draft intended to be posted by 28 April and make a determination.

    A question was raised about the authorship - there are five authors, which may be excessive. Jim's sense is that all five authors have been important to the draft and deserve listing.

    In wireless networks, some issues are arising in neighbor discovery and autoconfiguration. This may become a separate draft.

    Reasons to classify NAT-PT to Experimental, 10 mins, Davies
    - draft-ietf-v6ops-natpt-to-exprmntl-00.txt
    - GOAL: discuss changes, solicit comments before going for WG LC

    Elwyn Davies discussed changes to the previous proposal, which was to deprecate NATPT, to become making the capability experimental and listing the issues in the algorithm. The key recommendation is to use protocol translators and encapsulators as appropriate. These will need to be discussed in a protocol development working group.

    draft-daniel-natpt-bis-00.txt discusses such a proposal (NAT-PT without DNS-ALG), but has not at this point been extensively discussed.

    ISP IPv6 Deployment Scenarios in Broadband Access Networks, 15 mins, Popoviciu(?)
    - draft-ietf-v6ops-bb-deployment-scenarios-00.txt
    - GOAL: discuss changes and future direction; prepare for WG LC after 1-2

    Adeel Ahmed (for Ciprian Popoviciu) discussed broadband deployment issues. Key changes that have occurred in the drafts related to cable deployment in access networks in the US: Time Warner and Comcast. Updates have related to QoS for encrypted traffic and bulk subscriber provisioning.

    Added discussion of Wireless LANs in the security section, related to host authentication.

    The authors solicit suggestions on how to combine or improve the sections on multicast, network management, QoS, and security. The working group is requested to post comments to the authors or to the list by 27 March 2005. The working group is expected to last-call the draft when posted.

    Updates on the IPv6 Fix Project, 5-10 mins, Jinmei
    - draft-v6fix-en">http://v6fix.net/wide-draft-v6fix-en
    - GOAL: share the results of recent experiments, discuss next steps

    This work is not presented as an internet draft, but as a web page, as it describes a project of the Japanese WIDE project. The objective is to address issues that obstruct transition from IPv4 to IPv6. Key activities include collecting incident reports, network measurement, implementation behavior analysis, and requesting updates from relevant vendors.

    Practically speaking, the *BSD, Linux, MacOS X, SOlaris, and Windows XP implementations were tested, and work-arounds developed for issues uncovered. The general finding is that implementations are "not bad". These results are summarized at the project site.

    DNS Misbehavior is being directly studies with JPRS, the JPNIC domain registry. Of domains implementing the AAAA proposal, an automated test of names of the form www.*.co.jp showed that 0.04% of the domains and 0.11% of the servers had detectable problems. These operators are being contacted and the issues addressed.

    Network quality is also being directly tested. This is based on ping RTT between key measurement points in Japan at WIDE and IIJ, and in Spain, and comparison between IPv6 and IPv4 route testing. Most sites are good for both IPv4 and IPv6. Issues that arise are further tested using traceroute and other tools. There is a plan for feedback to site administrators addressing issues noted.

    Next steps include firewall testing, working with vendors on improvements, and a public mailing list on issues.

    Suggestions from the floor included tying into RIPE network path testing, including tunnel detection and mutual ping RTT testing.

    Status and going forward with IPv6-on-by-Default work, 5-10 mins, Chairs/Savola
    - draft-ietf-v6ops-v6onbydefault-03.txt
    - draft-ietf-v6ops-onlinkassumption-02.txt
    - GOAL: discuss the options how to move forward

    Pekka Savola presented work relating to the "on-link assumption" and "on by default" work. This addresses a fundamental flaw in DNS lookup mechanisms, that have implementations try with IPv6 before attempting with IPv4. A key issue with this document is that it discusses work in progress, making that work normative for it. The documents were resubmitted removing those references, and the working groups were asked to light a fire under their proposed solutions.

    The on-link assumption draft will be published with draft-ietf-ipv6-rfc2461bis, which removes that assumption.

    other issues relate to
    - TCP soft errors (TCPM considering),
    - SCTP and SCCP soft-errors (no progress),
    - default address selection for unreachable destinations (no work done yet),
    - and application robustness (transition document done).

    There are three possible ways forward for draft-ietf-v6ops-v6onbydefault-03.txt. One is to leave the normative references, which we have chosen to not do. Another is to simply document the problems; another is to document fixes as they appear.

    There was quite a bit of discussion by the Chairs, Alain Durand, David Kessens, Jinmei, Tony Hain, and others regarding the working group process. In essence, the question was whether we need to document all the problems that had to be fixed in the process of getting something out, or could that discussion die as the problems were fixed? The sense of the AD was that this document need not be published at all if all the problems were fixed, and the working group was perhaps best served by a blog or website listing current open issues. The sense of others was that the discussion needed to occur, and drafts drove that. The upshot was essentially to punt the matter to the new chairs; David indicated that he would return both documents to the working group.

    The final question relates to the future of draft-ietf-v6ops-v6onbydefault-03.txt. It could be left as a living document listing the issues. A general suggestion is to use blogging or a web site to manage the temporary information and write an RFC descibing the general class of problem and general solutions.

    IPv6 Network Architecture Protection, 10-15 mins, Van de Velde(?)
    - draft-vandevelde-v6ops-nap-01.txt
    - GOAL: discuss changes and the approach; ask for WG item adoption

    Tony Hain presented a discussion of network technologies, notably stateful firewalls and similar middleware, designed to meet market needs currently addressed using NAT technology. The new version contains a list of such market requirements; if additional market requirements are known, the authors would like text describing them.

    The document also covers a gap analysis of issues - ULAs, renumbering, hiding subnet topology, multihoming, and traceability. It is not intended to be all-encompassing.

    There was wide support in the working group, with many volunteering to read and comment on the updated draft. It will be a working group document.

    How to secure draft-ietf-v6ops-mech-v2 tunnel with IPsec, 10 mins, Tschofenig(?)
    - draft-tschofenig-v6ops-secure-tunnels-03.txt (or revised)
    - GOAL: discuss changes, solicit feedback; ask for WG adoption

    This is discussion of how to carry out draft-ietf-v6ops-mech-v2-06.txt using IPsec tunnels. Commentary has been towards document clean-up, and the question whether all traffic should be encrypted or only the link-local traffic? It is simpler if one encrypts everything. However if the target is protection of traffic (authentication), then maybe authentication of control traffic makes sense.

    The new chairs will post a consensus call to v6ops on picking this work up; if consensus does not develop, the work will be allowed to continue as a personal submission.

    Things to think about when renumbering, 10 mins, Chown
    - draft-chown-v6ops-renumber-thinkabout-01.txt (to be submitted)
    - GOAL: introduce the draft, solicit feedback for next revision

    This draft represents observations and ruminations resulting from testing of the renumbering procedure document and general network practice. Many of these are site-specific issues. Scenarios include those with and without a flag day.

    Much of this relates to IPv6 features related to renumbering. This includes multi-addressing, multicast, mobile IPv6, and ULAs.

    The principal use of ULAs in renumbering is a semi-flag-day; one might use them to retain local application support while introducing a flag day outside of your network.

    Many administrative issues came up which need to be looked at. These relate to router advertisement lifetimes, filters (especially firewall/border filters), renumbering frequency, delay-related considerations, scaling features, and dual stack issues, and application issues.

    The authors feel that the content is fairly complete, and this will give operators and future workers information relevant to the topic.

    IPv6 Security Overview - 5-7 mins, Davies
    - draft-savola-v6ops-security-overview-03.txt
    - GOAL: talk about differences, solicit more feedback; ask for WG adoption

    Elwyn's slides pretty much indicate what he said...

    The folks in the room generally supported the work, and had comments on the floor.

    Two key discussions were had. One regarded moving the document work working group status. There was no opposition; there was also no comment. The other regarded the place of "privacy" addresses. The authors' comment was that while "security by obscurity" doesn't work well in the Internet, obscurity helps, and could be described as one of the principal functions of a firewall. On the other hand, obscurity only exists for systems that act only as clients; any system that must be addressed by another system must have a predictable address, whether by naming (DNS), announcement (a router), or a priori.

    This is intended to be a working group item.

    VLAN usage for transition, 5 mins, Chown
    - draft-chown-v6ops-vlan-usage-02.txt
    (this is already a WG item, just not resubmitted yet)
    - GOAL: discuss issues, if any; solicit feedback. Prepare for WG LC soon.

    The working group seems to have lost interest in the document. It may be appropriate to send it as a personal submission to the RFC Editor.

    IPv6 Distributed Security Problem statement, 5 mins, Palet
    - draft-vives-v6ops-ipv6-security-ps-03.txt
    - GOAL: alert the WG to the updated draft and solicit feedback

    Look at a firewall-based security (which it calls a network-based model), and proposes what it calls a host-based model (which centers on host-host exchange of policy and authentication). Key issues relate to the trust model between the network and the host and the complexity of security in the host.

    The document probably wants to move in the direction of the security area. It also needs a current threat analysis, and an analysis of current security models (including intrusion detection systems, mediation VLANs, the use of 802.1X, etc) in addition to the use of host-based security.

    The authors plan to update the document with any new comments received.


    v6ops Charter
    Enterprise IPv6 Transition Analysis IETF 62 IPv6 Operations Working Group
    Moving Nat-PT to Experimental
    ISP IPv6 Deployment Scenarios in Broadband Access Networks
    Updates on IPv6Fix
    Status and going forward with draft-ietf-v6ops-v6onbydefault-03 draft-ietf-v6ops-onlinkassumption-02
    Network Architecture Protection
    Securing draft-ietf-v6ops-mech-v2 tunnels using IPsec
    Things to think about when Renumbering an IPv6 network
    IPv6 Security Overview
    Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks
    IPv6 Distributed Security problem statement