2.4.8 IPv6 Operations (v6ops)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-20

Robert Fink <bob@thefinks.com>
Margaret Wasserman <mrw@windriver.com>
Jun-ichiro 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: 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 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 identify and analyze 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. 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 translation.

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
NOV 02  Publish Unmanaged Network Deployment Scenarios as a WG I-D
NOV 02  Publish ISP Deployment Scenarios as a WG I-D
NOV 02  Publish Survey of IPv4 Addresses in IETF Standards as WG I-D
NOV 02  Publish Cellular Deployment Solutions as a 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
  • - draft-ietf-v6ops-3gpp-cases-02.txt
  • - draft-ietf-v6ops-3gpp-analysis-02.txt
  • - draft-ietf-v6ops-unman-scenarios-00.txt
  • - draft-ietf-v6ops-ipv4survey-apps-00.txt
  • - draft-ietf-v6ops-ipv4survey-gen-00.txt
  • - draft-ietf-v6ops-ipv4survey-ops-00.txt
  • - draft-ietf-v6ops-ipv4survey-int-00.txt
  • - draft-ietf-v6ops-ipv4survey-intro-00.txt
  • - draft-ietf-v6ops-ipv4survey-routing-00.txt
  • - draft-ietf-v6ops-ipv4survey-sec-00.txt
  • - draft-ietf-v6ops-ipv4survey-subip-00.txt
  • - draft-ietf-v6ops-ipv4survey-trans-00.txt
  • - draft-ietf-v6ops-entnet-scenarios-00.txt
  • - draft-ietf-v6ops-mech-v2-00.txt
  • No Request For Comments

    Current Meeting Report

    DRAFT version 1.0  7 April 2003
    IPv6 Operations (v6ops) Meeting
    19 March 2002
    IETF-56, San Francisco, CA
    Jun-Ichiro itojun Hagino <itojun@iijlab.net>
    Margaret Wasserman <mrw@windriver.com>
    Robert Fink <bob@thefinks.com>
    Attendance was more than several hundered folk.
    Margaret chaired the meeting; the minutes were taken by Bob Fink.
    Administrative information:
    v6ops discussion: <v6ops@ops.ietf.org>
    Subscribe to v6ops mail list: <majordomo@ops.ietf.org> "subscribe v6ops"
    v6ops mail archive: 
    v6ops web site: <http://www.6bone.net/v6ops/>
    v6ops Project Status: 
    Wednesday, March 19th
    Status of v6ops projects - Margaret Wasserman, 20 mins
    <no document>
    3GPP Analysis draft - Juha Wiljakka, 10 mins
    UNMAN analysis draft - Christian Huitema, 15 mins
    ISP Scenarios - Mikael Lind, 5 mins
    IPv4 Survey draft restructuring - Phil Nesser or chairs, 10 mins
    aft-ietf-v6ops-ipv4survey-intro-00.txt> Introduction
    aft-ietf-v6ops-ipv4survey-apps-00.txt> Application area
    aft-ietf-v6ops-ipv4survey-gen-00.txt> General area
    aft-ietf-v6ops-ipv4survey-ops-00.txt> Operations & Management area
    aft-ietf-v6ops-ipv4survey-int-00.txt> Internet area
    aft-ietf-v6ops-ipv4survey-routing-00.txt> Routing area
    aft-ietf-v6ops-ipv4survey-sec-00.txt> Security area
    aft-ietf-v6ops-ipv4survey-subip-00.txt> Sub-IP area
    aft-ietf-v6ops-ipv4survey-trans-00.txt> Transport area
    Mech draft - Erik Nordmark, 15 mins
    Translation Issues - Suresh Satapati, 10 mins
    Translation Issues - Alain Durand, 10 mins
    Discussion of what to do with NAT-PT - Margaret Wasserman, 15 mins
    <no document>
    Operational experience with turning IPv6 on by default - Alain Durand, 10 
    Operational experience with Microsoft IPv6 based P2P application 
    ("threedegrees") - Christian Huitema, 10 mins
    <no draft>
    Meeting Minutes
    Status of v6ops projects - Margaret Wasserman
    <no document>
    Margaret introduced the meeting and gave a status report of v6ops 
    projects/documents. Only the principal topics discussed are reported here. 
    For the rest of the report, please refer to the slides above.
    Margaret asked if ENT Scenarios is on correct track?
    Alain Durand noted good progress getting to this point. Concern over the 
    overall directions. Scenarios should be articulated differently. One is ENT 
    to deploy same as v4, same things need to exist in v6 as in v4. Another is 
    existing net decides there is a new app that requires v6 so need to do 
    minimum to make net work, i.e., just this v6 app. Third, ENT strategy to 
    deploy a completely new network with v6. Not bound by v4 legacy 
    There was a comment that it was difficult to see how team will move ahead to 
    completion as so much solution is hinted at.
    Split consensus on doc taking correct direction.
    Split consensus on accepting, slight lean to not.
    Still too few who have read the doc.  More folk need to read it and 
    document their opinions.
    Brian Haberman asked if maybe it should become a wg doc so wg can have 
    input to it.
    Thomas believes their is lack of consensus so need to fix that problem 
    Jim Bound said that he wants to resign as editor as he is upset on how this 
    is progressing. He wants to take the effort to industry.
    Tim Chown feels this is a very hard effort to do. Need to progress it as a wg 
    Brian Carpenter noted why he abstained: there are bits missing. These bits 
    should be fixed and would prefer Jim continue to work on it. Question 
    should be different. Do we want to make progress on this doc.
    Jim Bound asked if the wg wanted to do this work.
    Margaret asked if folks felt it should go ahead and in this general form. 
    Alain said he will frame his concerns on doc to the group and list.
    Margaret noted that we have had trouble getting folks to review docs. Too 
    little effort going in to progress our work. Need better review. 
    Margaret had proposed to list a doc review team. Some pushback on this. 
    Margaret wants to have this review team so she can enlist outsiders to 
    help, e.g., experts on specific areas. What is the opinion of the group.
    Someone asked how would this be done? Margaret replied that it would be an 
    open list of folks, hopefully credible and qualified people, but with no 
    special power. All comments to list.
    Someone felt it not needed. Don't think it needs an explicit team. The 
    chairs can appoint folks per doc.
    Jim Bound agrees it is necessary. Belief is that reality is in IETF we have 
    problem with process. Chairs need ways to move forward. A group 
    volunteering or being selected to review docs are enlisting to do work and 
    thus have a deliverable. It is a good idea.
    Tim Chown concerned that a problem is that wg folk will not work if a team is 
    supposed to do work.
    Hesham Soliman noted that on various scenarios docs we missed some 
    issues, especially on mobility. Margaret felt that issues need to be 
    raised to the list.
    Thomas Narten felt that getting reviews a good idea. Shared Tim's 
    concern over folk not doing any work if others supposed to do it.
    Chairs want to form a team with wg support. Will you support it. Strong 
    consensus to allow chairs to form a review team (2/3 to 1/3).
    3GPP Analysis draft - Juha Wiljakka
    Juha gave a review of progress on the 3GPP scenarios draft and the newer 
    analysis draft. He asked the wg to consider starting wg last call for this 
    There were no comments.
    UNMAN analysis draft - Christian Huitema
    Christian presented the status of the UNMAN analysis draft.
    Pekka Savola disagreed that nodes connecting to the Internet (e.g., via PPP 
    and DSL) is most important and normal. Christian is not saying it isn't 
    interesting, and that it is part of point C.
    Alain Durand noted there is a gap here. Things it doesn't cover need to be 
    somehow, like the UDP tunnel. Margaret noted this could be in analysis as a 
    Alain doesn't want a result that says must take a particular solution. 
    Christian said it doesn't.
    Rob Austein, a co-author of Christian, commented that given comments he has 
    seen some elaborations need to be made. Rob and Christian agreed there 
    needs to be some elaboration.
    Marc Blanchet noted that their is a UDP tunnel they have that isn't 
    Teredo and this should be noted. Christian agreed.
    Pekka Savola felt some work needed on UDP tunnel differentiation in the 
    Itojun thinks could defer case D to another draft for timing. Margaret felt 
    it was ok to leave as scenario but say in analysis we can't handle yet.
    Bob Hinden felt their is a little experience with this.
    Christian felt that it is important to keep the 4 over 6 tunneling on the 
    Christian closed noting that we have a new problem that people are 
    stacking NATs, e.g., a wireless NAT box on top of a DSL NAT, simply 
    because of the way boxes are designed and provided in the market place. We 
    need a multi-link subnet approach to cover this.
    Margaret asked if draft was taking the right direction: consensus is that it 
    Margaret asked if this draft should be accepted as a wg item: 
    consensus was that it should be.
    Will take this to the list for consensus.
    ISP Scenarios - Mikael Lind
    Mikael presented on his new effort as the new editor/lead of the ISP 
    effort (this change occurred just 3 weeks before the meeting).
    There is now a mail list and a few extra folk on team. Scope and Goals are 
    being developed. Docs will be revised under a new outline.
    First, scenarios will be focused on scenarios and migration paths as 
    supposed to how networks are built up. Thus only a short description on 
    network types.
    So active work is settling on a new outline.
    IPv4 Survey draft restructuring - Phil Nesser or chairs
    aft-ietf-v6ops-ipv4survey-intro-00.txt> Introduction
    aft-ietf-v6ops-ipv4survey-apps-00.txt> Application area
    aft-ietf-v6ops-ipv4survey-gen-00.txt> General area
    aft-ietf-v6ops-ipv4survey-ops-00.txt> Operations & Management area
    aft-ietf-v6ops-ipv4survey-int-00.txt> Internet area
    aft-ietf-v6ops-ipv4survey-routing-00.txt> Routing area
    aft-ietf-v6ops-ipv4survey-sec-00.txt> Security area
    aft-ietf-v6ops-ipv4survey-subip-00.txt> Sub-IP area
    aft-ietf-v6ops-ipv4survey-trans-00.txt> Transport area
    SLIDES: none used
    Phil didn't show up, so Margaret explained the work that had gone on. How 
    the overly long original work was divided up by IETF Area, with an 
    overview draft. It is intended to take these per Area drafts to each Area to 
    solicit the preferred approach for each, to address the approach to use. 
    There isn't much to really to do until the Areas get this into shape.
    Pekka Savola asked if the areas are stable. Margaret felt that it is and the 
    way to get review.
    Rob Austein felt that it is a good idea, but it is hard to get through the 
    Brian Haberman also felt that it was hard to look at the original. There 
    isn't anything that notes where there is an equivalent v6 approach for one of 
    these old v4-based RFCs. What will the due date be when we ask the ADs for 
    Margaret doesn't know but we need to progress this to Areas to get the 
    effort moving.
    Marc Blanchet feels this is a good way to go, but has a concern that some 
    corrections are not included yet.
    Bob Fink asked for any outstanding comments to be resubmitted.
    Someone asked about what should be included in the APPS area. Margaret 
    noted that the specific Areas must decide what to do. These drafts will 
    remain a to do list for changing IETF standards to accommodate IPv6.
    Rob Austein noted that tracking lists are a good thing.
    Christian Huitema said to not lose track of the goal of the exercise, 
    i.e., to shake up the Areas to get work done. Make sure we have one 
    reviewer for each document and then ship it.
    Brian Haberman echoed Christian, and asked if a good approach is to ask for a 
    volunteer from each Area to be responsible for each draft. Margaret 
    thought this might be a good idea and took this under advisement.
    It was noted that wg last call will not be done until after a response from 
    the respective Area occurs.
    Mech draft - Erik Nordmark
    Erik presented on issues for MECH v2 to move it forward.
    Erik asked if we want to develop a better MTU warning. Fred Templin had 
    comments on this.
    Itojun doesn't think there is a need for warning on manually 
    configuring large tunnels.
    Fred commented on MTU size. Dave Thaler noted his studies and that there are 
    links with a 1400 byte size. He thinks 1380 is largest you can go.
    Perry Metzger noted that the history of the 1280 byte packet size was a 
    long discussion and that no one should decide on this without a reread of 
    the archive of these discussions.
    Erik noted this is the minimal MTU size; not the tunnel size. He asked for an 
    Erik closed stating he would reissue the draft and the wg chairs need to 
    decide if it goes to DS or PS.
    No further comments.
    Translation Issues - Suresh Satapati
    Suresh Satapati presented on Translation Issues.
    Someone asked about the synchronization issue and what it is. Someone 
    explained it.
    Rob Austein asked about dual stack to v4-only noting that things are more 
    complex as some things don't translate easily, like ICMP. There are 
    messages that can be expressed in one dialect and not in the other.
    Perry Metzger said that encouraging v6-only is something we want to 
    Margaret delayed more comments until the discussion later in the 
    Translation Issues - Alain Durand
    Alain Durand presented on his concerns about NAT-PT and related issues.
    Bob Hinden noted it isn't a tradeoff between NAT and no NAT, that dual 
    stack would be preferable when you can get the addresses you need. So the 
    issue is when you have to have a v4 NAT in the path due to no 
    addresses. Alain felt he covered this in his first draft.
    Pekka Savola noted that is might be best to simply rely on the fact there 
    are v4 NATs that need to be worked with.
    Comments occurred under the following discussion item.
    Discussion of what to do with NAT-PT - Wasserman, 15 mins
    <no document>
    SLIDES: none used
    Margaret outlined her goal, which is to decide whether NAT-PT is needed and 
    whether to move it to DS, or if it needs to be improved, or if it is bad but 
    needs to be used so may need some fixes and/or applicability 
    Christian noted that he did analyze some NAT-PT issues. It boils down to 
    what you need in v6-only devices, which these days is a very specific 
    decision made only when no v4 connectivity needed.
    Someone noted that the 3GPP drafts say there is a need for NAT-PT. Maybe 
    NAT-PT should be kept alive.
    Rob Austein firmly feels we need an applicability statement. 
    Everywhere else we need state in end nodes.
    Pyda Srisuresh felt we should leave it alone.
    Marc Blanchet asked how this affects the current scenarios work. If folks 
    feel we need an upgrade of the document we should wait until scenarios and 
    anlysis are done so we know what we need.
    Jonne commented on NAT-PT in 3GPP and noted that it might not be NAT-PT as it 
    could be done differently. But there is a need for some kind of 
    translation with an applicability statement.
    Tim Chown seconded Marc's comments.
    Jim Bound agreed with Marc. That is, leave it for now.
    Brian Haberman asked if they are willing to accept NAT-PT for Unicast how 
    about for Multicast. There have been some proposals to do this. Some folks in 
    the mbone group could take this on but thinks it a dangerous path to go 
    Bob Hinden thought this a good question and that he and Steve Deering felt 
    this was too hard and don't do it.
    Brian Haberman agreed with Bob, too many dangers in translating the 
    functionality between the two suites (v4 and v6).
    Margaret asked what folks want to do.
    What do we want to do with the current draft. Historic? As is for now? 
    Update to address some concerns? Move to DS?
    Do we think it is necessary to document the applicability of NAT-PT?
    Erik thinks there are is overlap between the questions.
    Randy Bush agreed with Erik, there are multiple paths so enumerate. Some 
    folks are betting on NAT-PT. We should fix it were we can and restrict its 
    use to where is is really needed.
    Marc Blanchet ok with questions, but how tp process if we change it.
    Itojun feels there are confusions over orignail NAT-PT and an update is 
    Suresh we shouldn't deprecate at this time.
    Erik felt folks don't always know what they mean when they say they need 
    NAT-PT. Issue is what is general applicability of NAT-PT.
    Jonne re-stated again that 3GPP needs some translator not 
    necessarily NAT-PT. Randy noted that this in conflict with some 3GPP 
    liaison statements.
    Erik thinks NAT-PT is three things and some parts need to be 
    Jim Bound doesn't want to edit NAT-PT. Leave it at PS, talk to 3GPP, no 
    more work. Work on scenarios/analysis.
    Alain Durand suggested an analysis of where and how it is needed first, 
    then consider these questions. That is, do applicability first.
    Shouldn't we also be talking of SIIT as well.
    Randy feels we need to converge on what 3GPP requirements really are for 
    Thomas, speaking as IETF 3GPP liaison, NAT-PT not what is 
    necessarily needed.
    Jonne suggested waiting for 3GPP efforts done to decided to address these 
    NAT-PT questions.
    Randy concerned with not doing something as others may want to misuse 
    Erik feels question is muddled. 3GPP needs to decide on this use.
    Bob Hinden thinks it premature to have this discussion without a draft 
    addressing this.
    Margaret asked: Historic? 9. Left alone for now: 25. Opened up for 
    corrections: 10.
    Then Margaret asked: Applicability statement need: consensus to do it. How 
    many willing to do work on it: many.
    The meeting was adjourned as it there was no time left and there was no 
    time for the last two presentations listed below.
    Operational experience with turning IPv6 on by default - Durand, 10 mins
    Operational experience with Microsoft IPv6 based P2P application 
    ("threedegrees") - Huitema, 10 mins
    <no draft>


    None received.