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/draft-ietf-v6ops-3gpp-analysis-02.txt>
UNMAN analysis draft - Christian Huitema, 15 mins
<ftp://www.ietf.org/internet-drafts/draft-huitema-ngtrans-unmaneval-01.txt>
ISP Scenarios - Mikael Lind, 5 mins
<http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-04.txt>
IPv4 Survey draft restructuring - Phil Nesser or chairs, 10 mins
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-00.txt>
Introduction
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-00.txt>
Application area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-gen-00.txt>
General area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-00.txt>
Operations & Management area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-int-00.txt>
Internet area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-00.txt>
Routing area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-00.txt>
Security area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-00.txt>
Sub-IP area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-00.txt>
Transport area
Mech draft - Erik Nordmark, 15 mins
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-00.txt>
Translation Issues - Suresh Satapati, 10 mins
<http://www.ietf.org/internet-drafts/draft-vanderpol-v6ops-translation-issues-00.txt>
Translation Issues - Alain Durand, 10 mins
<http://www.ietf.org/internet-drafts/draft-durand-v6ops-dualstack-vs-natpt-00.txt>
<http://www.ietf.org/internet-drafts/draft-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/draft-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/IETF-56-SanFrancisco/v6ops-status.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-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/draft-ietf-v6ops-3gpp-analysis-02.txt>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-56-SanFrancisco/3gpp-analysis.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-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/draft-huitema-ngtrans-unmaneval-01.txt>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-56-SanFrancisco/UNMAN-analysis.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-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/draft-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/IETF-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/draft-ietf-v6ops-ipv4survey-intro-00.txt>
Introduction
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-00.txt>
Application area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-gen-00.txt>
General area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-00.txt>
Operations & Management area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-int-00.txt>
Internet area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-00.txt>
Routing area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-00.txt>
Security area
<http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-00.txt>
Sub-IP area
<http://www.ietf.org/internet-drafts/draft-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/draft-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/draft-vanderpol-v6ops-translation-issues-00.txt>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-56-SanFrancisco/NATissues-Satapati.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-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/draft-durand-v6ops-dualstack-vs-natpt-00.txt>
<http://www.ietf.org/internet-drafts/draft-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/draft-roy-v6ops-v6onbydefault-00.txt>
===
Operational experience with Microsoft IPv6 based P2P application ("threedegrees")
- Huitema, 10 mins
<no draft>
-end