Last Modified: 2003-01-20
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.
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 version 1.0 7 April 2003 ======================================= IPv6 Operations (v6ops) Meeting 19 March 2002 IETF-56, San Francisco, CA ====== CHAIRS 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: <http://ops.ietf.org/lists/v6ops/> v6ops web site: <http://www.6bone.net/v6ops/> v6ops Project Status: <http://www.6bone.net/v6ops/ v6ops_project-status.html> ====== Agenda ------------------------- Wednesday, March 19th Status of v6ops projects - Margaret Wasserman, 20 mins <no document> 3GPP Analysis draft - Juha Wiljakka, 10 mins <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-3gpp-analysis-02.txt> UNMAN analysis draft - Christian Huitema, 15 mins <ftp://www.ietf.org/internet-drafts/dra ft-huitema-ngtrans-unmaneval-01.txt> ISP Scenarios - Mikael Lind, 5 mins <http://www.ietf.org/internet-drafts/dr aft-mickles-v6ops-isp-cases-04.txt> IPv4 Survey draft restructuring - Phil Nesser or chairs, 10 mins <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-intro-00.txt> Introduction <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-apps-00.txt> Application area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-gen-00.txt> General area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-ops-00.txt> Operations & Management area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-int-00.txt> Internet area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-routing-00.txt> Routing area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-sec-00.txt> Security area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-subip-00.txt> Sub-IP area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-trans-00.txt> Transport area Mech draft - Erik Nordmark, 15 mins <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-mech-v2-00.txt> Translation Issues - Suresh Satapati, 10 mins <http://www.ietf.org/internet-drafts/dr aft-vanderpol-v6ops-translation-issues-00.txt> Translation Issues - Alain Durand, 10 mins <http://www.ietf.org/internet-drafts/dr aft-durand-v6ops-dualstack-vs-natpt-00.txt> <http://www.ietf.org/internet-drafts/dr aft-durand-v6ops-natpt-dns-alg-issues-00.txt> 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 mins <http://www.ietf.org/internet-drafts/dr aft-roy-v6ops-v6onbydefault-00.txt> 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> SLIDES: <http://www.6bone.net/v6ops/minutes/IET F-56-SanFrancisco/v6ops-status.pdf> <http://www.6bone.net/v6ops/minutes/IET F-56-SanFrancisco/v6ops-status.ppt> 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 equipment. 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 first. 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 item. 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. Unanimous. 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 <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-3gpp-analysis-02.txt> SLIDES: <http://www.6bone.net/v6ops/minutes/IET F-56-SanFrancisco/3gpp-analysis.pdf> <http://www.6bone.net/v6ops/minutes/IET F-56-SanFrancisco/3gpp-analysis.ppt> 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 document. There were no comments. === UNMAN analysis draft - Christian Huitema <http://www.ietf.org/internet-drafts/dr aft-huitema-ngtrans-unmaneval-01.txt> SLIDES: <http://www.6bone.net/v6ops/minutes/IET F-56-SanFrancisco/UNMAN-analysis.pdf> <http://www.6bone.net/v6ops/minutes/IET F-56-SanFrancisco/UNMAN-analysis.ppt> 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 conclusion. 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 draft. 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 table. 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 was. 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 <http://www.ietf.org/internet-drafts/dr aft-mickles-v6ops-isp-cases-04.txt> SLIDES: <http://www.6bone.net/v6ops/minutes /IETF-56-SanFrancisco/ISP-report.pdf <http://www.6bone.net/v6ops/minutes/IET F-56-SanFrancisco/ISP-report.ppt> 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 <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-intro-00.txt> Introduction <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-apps-00.txt> Application area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-gen-00.txt> General area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-ops-00.txt> Operations & Management area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-int-00.txt> Internet area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-routing-00.txt> Routing area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-sec-00.txt> Security area <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-ipv4survey-subip-00.txt> Sub-IP area <http://www.ietf.org/internet-drafts/dr 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 introduction. 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 help? 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 <http://www.ietf.org/internet-drafts/dr aft-ietf-v6ops-mech-v2-00.txt> SLIDES: <http://www.6bone.net/v6ops/minutes /IETF-56-SanFrancisco/mech-v2.pdf> 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 analysis. 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 <http://www.ietf.org/internet-drafts/dr aft-vanderpol-v6ops-translation-issues-00.txt> SLIDES: <http://www.6bone.net/v6ops/minutes/IET F-56-SanFrancisco/NATissues-Satapati.pdf> <http://www.6bone.net/v6ops/minutes/IET F-56-SanFrancisco/NATissues-Satapati.ppt> 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 encourage. Margaret delayed more comments until the discussion later in the meeting. === Translation Issues - Alain Durand <http://www.ietf.org/internet-drafts/dr aft-durand-v6ops-dualstack-vs-natpt-00.txt> <http://www.ietf.org/internet-drafts/dr aft-durand-v6ops-natpt-dns-alg-issues-00.txt> SLIDES: <http://www.6bone.net/v6ops/minutes /IETF-56-SanFrancisco/NATissues-Durand.pdf> 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 statements. 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 down. 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 needed. 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 preserved. 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 NAT-PT. 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 NAT-PT. 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 <http://www.ietf.org/internet-drafts/dr aft-roy-v6ops-v6onbydefault-00.txt> === Operational experience with Microsoft IPv6 based P2P application ("threedegrees") - Huitema, 10 mins <no draft> |