2.4.17 IPv6 Operations (v6ops)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC 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: 2004-09-22


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-6to4-security-04.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-01.txt
  • draft-ietf-v6ops-assisted-tunneling-requirements-01.txt
  • draft-ietf-v6ops-ent-analysis-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

    Current Meeting Report

    v6ops WG Minutes of IETF61

    Wednesday 10th November -- 0900-1130

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

    The minutes were edited by Pekka Savola from notes taken by
    Florent Parent, Juha Wiljakka and Steve Silverman.
    Tim Chown provided Jabber transcript.

    There were over ??? folk in attendance.

    Introduction, doc status, agenda bashing, 5 mins, Chairs
    Enterprise Analysis Discussion, 15 mins, Bound
    Discussion of the way forward - 30 mins, Chairs/WG

    IPv6 Network Architecture Protection, 10 mins, Van de Velde
    Reason to Deprecate NAT-PT, 15 mins, Davies
    ISP IPv6 Deployment Scenarios in Broadband, 15 mins, Popoviciu
    IPv6 Fix: an activity to solve barriers to IPv6 transition, 7-10 mins, Tatuya

    Discussion of Teredo IETF LC comments, 5 mins, Huitema
    IPv6 Security Overview - 5-7 mins, Davies
    Things to think about when renumbering, 5-7 mins, Thompson
    IP Mobility Scenarios discussion, 5 mins, Gustafsson

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

    SLIDES: <00_v6ops-agenda.pdf>

    * Enterprise Analysis Discussion, 15 mins, Bound
    - draft-ietf-v6ops-ent-analysis-00.txt
    - GOAL: discuss issues, so that the revision can be WGLC'ed

    SLIDES: <01-ent-analysis.pdf>

    Tim Chown: Why isn't 6to4 being used.
    Jim Bound: because of the 6to4 prefix.
    Brian Carpenter: Would be delighted if we did not need 6to4: Then IPv6 is being used.
    Dave Green: using 6to4 for experimentation. Most what to use current address Using translation. Will need ALG for v4 only - v6 only

    Alain Durand: What is the case of IPv6 application communicating with IPv4 application (except for IPv6 SIP node talking to IPv4 SIP node)?
    Dave Green: No.

    Remi Despres: Main reason for NAT-PT is handling IPv6 <-> IPv4 applications. Legacy host with only IPv4 address cannot reply to IPv6 node.
    Pekka Savola: this scenario has not been discussed so much in the wg - needs to be clarified, but seems to be out of scope.
    Jim Bound: Don't want to go there in ent scenarios. Stay dual-stack.
    Remi Despres: But will get to point when v4 address no longer assigned
    Bernard Tuy: DSTM is the right solution.
    Brian Carpenter: I am also a NAT-PT hater, but there are applications where performance critical. ALG will not scale. (eg. iSCSI).
    Brian Carpenter: Focusing document good. Agrees with first statement in presentation
    Jim Bound: Comments on DSTM: we have not promoted DHCPv4 to do the IPv4 address allocation.
    Tim Chown: analysis on what is missing (tools) in ent scenario. Will that be taken elsewhere?
    Jim Bound: non-normative references can be used as input (tunnel broker, TEP discovery, etc.)
    Jonne Soininen: Let's talk that during the "way forward" discussion.

    * Discussion of the way forward - 30 mins, Chairs/WG

    SLIDES: <02-way-forward.pdf>

    David Kessens: Real important thing for this wg is the v6ops charter. Protocol work in INT area. This WG not right forum to decide that. Want to have quick progress.

    Hesham Soliman: Mobility: will this go under OPS or INT?
    Jonne Soininen: new WG will work on new protocol only. Analysis should be done in mobility issue.
    Hesham Soliman: mobility issue is not OPS issue. 2-3 different documents looking at this. Where to adopt this stuff? here? new WG?
    Pekka Savola: new WG specifically focused. V6ops could only take a document on scenarios.
    Hesham Soliman: suggest if new WG created around known solution only, doesn't make sense.

    Kurtis Lindqvist: 1st part (tunneling wg) makes sense, 2nd part (v6ops) is quite weak. "Provide a forum for IPv6 ops" -- is this the NANOG IPv6 group? Need to keep v6ops open?
    Alain Durand: is v6ops going to be a nursary of new WG spinoffs?
    David Kessens: don't ask questions, propose what you want it to be. :)
    Alain Durand: v6ops more effective if focused on deliverables, issues found in protocol, document them. ex: campus deployment
    TJ Kniveton: concered if already a vision on new protocol. Need to look at current mechs. If this is envisioning one solution to fit all, other wg that need such mech will come up with their own.
    Jonne Soininen: but v6ops not the place for that. (protocols)
    Jim Bound: v6ops started about scenarios/analysis. Fine. ...
    Jonne Soininen: We did analysis. Now know what we need.
    Pekka Savola: We know about at least one need.
    Jonne Soininen: Some solutions are already in advanced stage, don't need wg. (Teredo, 6PE). Maybe new wg need for mobility issue. Maybe, maybe not.
    Jim Bound: If someone has good idea on mechanism, no place in IETF to work on this. Unacceptable.

    David Kessens: hard to reach concensus in wg. Conclude that milestones are reached and move on to work on other stuff.
    Jim Bound: Some people have have vendor agenda and have won
    Jonne Soininen: we don't want to work on analysis anymore, but focused WG to work on protocols. Aim is to move forward.
    Jim Bound: "dishonored" 2 times.
    Christian Huitema: Understand where Jim comes from. v6ops experiment. IESG has used the process to slow down transition development. Have to learn from that. Cannot turn clock back.

    Tony Hain: If new WG created and individual don't have fair hearing, not moving forward. Will additional WGs be approved to work mechanisms?
    David Kessens: No Internet AD here? The problem is that we are going to do this in Internet area, not my area.
    Margaret Wasserman: (walks in) point is to create appropriate WG or move into existing ones. If WG decide that tunneling work is required, no problem. Can avoid BOF if possible.

    SLIDES: <03_v6ops-dow-diff.html>

    Remi Despres: Difference between describing the problem and solution, but less difference between identifying the solution and describing it. Goals is restricting too much the WG.
    Pekka Savola: comments received that we could not go forward since current charter too broad.

    Tim Chown: Multicast operation. Where does it fit?

    Margaret Wasserman: Supports idea of new charter. More we could do in application advise. Don't like putting hard rules (don't work on foo). Too restrictive. Used to be: have a problem, lets do a mechanism. Need analyse first.

    Dave Thaler: Reword the IPsec usage with IPv6-in-IPv4 tunneling. Making v6ops like a mini-bof for new WG. Will this be a precedent?
    Margaret Wasserman: Impossible to say. Case by case basis. BoF not required so not bypassing anything.

    David Kessens: good idea to get v6ops out of the way. Should spend more time on tunneling charter. Have Margaret input on it.

    Tony Hain: Where will all work go? Things dropped off charter should be taken by all other WG (very wg should be considering IPv6). Not sure that IESG is supporting that.
    Pekka Savola: Pushing work to some other wgs has been happening already.
    Tim Chown: other wg may come up with their own method for tunneling. One way is better than 6-7 different ones. Need to take care of that.
    Pekka Savola: I created mailing list for mobility issues.

    Kurtis Lindqvist: Why not give IPv6 tunnels using IPsec to IPsec wg? Why is "v6" in wg titles. The longer we keep this "boundary"... Look in other WG if many work could be move over there.
    David Kessens: agrees. Should no do other WGs' work for them.

    Jordi: Have good work that has been ignored by security group.
    Pekka: difficult to tell why no feedback from sec. folks. Can't tell whether there's no time or whether it's a bad idea. Having a BoF might help.

    SLIDES: <04_v6tc-charter.txt>

    Karen Nielsen: what to do with all the tunneling requirements?
    Pekka Savola: we'll get to asking that later.

    Brian Carpenter: first paragraph clumsy. Make it more clear based on input.

    Showing hands, is the proposal for the way forward clear enough?
    YES: many hands
    Few hands raised on "somewhat confused"

    Jim Bound: Not clear on how to add things.
    David Kessens: Can be done. Room for change.

    Alexandru Petrescu: not clear how mobility is handled.
    Jonne Soininen: confusion on how to start new work. AD should clarify that if work needed, new Bof can be started.
    Margaret Wasserman: This wg cannot make a new wg, but I am interested to hear the opinion of this wg.
    Margaret Wasserman: don't want v6ops as mechanism to start new WGs. Talk to chairs, ADs on how to start new WG. Nothing in this WG change any of that.
    Jonne Soininen: Don't need justification from v6ops to start new work.

    After this, the WG was asked again whether the plan was clearer now. Only a couple of hands indicated that it was still unclear, so it was considered clear enough.

    Alain Durand: We want to ask separately about refocusing and new WG.

    Showing hands, do we want to create new focused WG for tunnel server? Only a couple of people against, very large majority for.

    Jordi: Create new WG *if* it can be done quickly
    Christian Huitema: question of trust on WG and AD. Restrict v6ops to do ops only and block possibility to do protocol work. Otherwise, if new WG don't work, v6ops charter restricted. Were stuck.
    Margaret: Don't do work when no consensus. Community decide if work will be done or not. No problem to create new tunneling wg.
    Perry Metzger: pathetic that we argue on such administrative item for the past hour.
    Alain Durand: good that "ban" on existing protocol work is lifted.

    Jordi Palet: Change way were managing the WG, not fair, serialized.
    David Kessens: the proposal now is about this, the WG is too big, this gets it more focused.

    Jonne Soininen: should we recharter v6ops? limit only on operational issues.
    Remi Despres: Question should be "restricting more that just removing tunneling protocol work"
    Brian Carpenter: lets just vote.

    Show of hands, a very large number for yes, only a couple for no.

    Showing hands: should we recharter v6ops to do only operational issues?
    - rough consensus to start rechartering, <5 persons were against

    Jonne Soininen: (from the last slide) What to do with the tunneling requirements?
    Alain Durand: the new WG, obviously.
    Margaret Wasserman: Takes over 2 weeks. So what? Create mailing list and start work now .
    Alain Durand: let's trust and move on from analysis paralysis
    Jonne Soininen: (Not decided here, let's move on.)

    * Goals for Zero-Configuration Tunneling in 3GPP, 1 min, Nielsen
    * Generic Zero-Configuration Tunneling, 10 mins, Palet

    These two items were skipped because there was already been sufficient discussion on the topic.

    * IPv6 Network Architecture Protection, 10 mins, Van de Velde
    - draft-vandevelde-v6ops-nap-00.txt
    - GOAL: introduce and start the discussion about v4 NAT alternatives in IPv6

    SLIDES: <05_v6ops-nap.pdf>

    Alain Durand: unclear on the topology hinding using routing.
    Pascal Thubert: MIPv6 and ULA for care of address so only home address visible.
    Tim Chown: good work. Should be part of this wg.

    Show of hands for the interest in the WG. Very significant interest, no opposition. WG adoption to be asked later.

    * Reason to Deprecate NAT-PT, 15 mins, Davies
    - draft-aoun-v6ops-natpt-deprecate-00.txt
    - GOAL: 5 mins presentation, 10 mins trying to decide next steps

    SLIDES: <06-natpt-deprecate.pdf>

    Pekka Savola: IMS case not clear.
    Jonne Soininen: 3GPP has not identified need for NAT-PT. Some ALG probably.
    Alain Duranda: People have impression that want to deprecate all translation. Be careful in wording. Deprecate 2766.
    Tony Hain: Lack of scenario doesn't mean it is not being built. Reality is that people are building it. Suggest separating scenarios discussion from the issues discussion.

    Elwyn Davies: do you have specific scenarios?
    Tony Hain: yes, to be taken offline. Clients are forced work a particular path which is not ideal.

    Christian Huitema: Good argument that 2677 is not good. Move to experimental. Finding this in customer procurements.
    Pekka Savola: support that.
    Senthil Sivakumar: Using 2766 without DNS-alg and it works well.
    Pekka Savola: but many scenarios, where this is also being deployed, require dns-alg.
    Tony Hain: But other tools are stuck, so no alternative.

    Remi Despres: where will the tools be discussed?
    Pekka Savola: not this wg. If sufficient community support, can discussed and a BoF could be done.

    Show of hands, should we move NAT-PT to experimental?
    Yes: a very larger numbery, no: one.

    * ISP IPv6 Deployment Scenarios in Broadband Access Networks, 15 mins,
    - draft-asadullah-v6ops-bb-deployment-scenarios-01.txt
    - GOAL: get feedback; gauge interest and the direction

    SLIDES: <09_bbdeploy.pdf>

    Show of hands who read draft. Less than half a dozen. Will need more review.
    Show of hands if this is the right approach? Some, none against.

    * IPv6 Fix: an activity to solve barriers to IPv6 transition, 7-10 mins,
    - A new WIDE project to fix practical IPv6 deployment issues
    - GOAL: inform the WG of activities, solicit the interested people

    SLIDES: <08_v6fix.pdf>

    Pekka Savola: Very important work for IPv6 deployment, contact Jinmei
    and their project.

    Discussion of Teredo IETF LC comments, 5 mins, Huitema
    - draft-huitema-v6ops-teredo-02.txt
    - GOAL: describe and discuss the important IETF LC comments

    SLIDES: <09_teredo-lc.pdf>

    (The slides didn't show due to computer problems.)

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

    Ran out of time, not presented.

    Things to think about when renumbering, 5-7 mins, Thompson
    - draft-chown-v6ops-renumber-thinkabout-00.txt
    - GOAL: introduce the draft, solicit feedback for next revision

    Ran out of time, not presented.

    IP Mobility Scenarios discussion, 5 mins, Gustafsson
    - draft-larsson-v6ops-mip-scenarios-00.txt
    - GOAL: update from the IP mobility scenarios/requirements discussion

    Ran out of time, not presented.



    Enterprise IPv6 Transition Analysis
    The way forward in v6ops
    the most important changes:
    IPv6 Tunneling Configuration (v6tc) WG
    Network Architecture Protection
    Reasons to Deprecate Nat-PT
    ISP IPv6 Deployment Scenarios in Broadband Access Networks
    IPv6Fix: an activity to solve barriers to IPv6 transition
    IETF-61 V6OPS Teredo last call comments