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>