DRAFT version 0.6 8 December 2003
=======================================
IPv6 Operations WG (v6ops)
IETF-58, Minneapolis
Monday, November 10 at 1300-1500
Wednesday, November 12 at 1530-1730
======
CHAIRS:
Bob Fink <bob@thefinks.com>
Pekka Savola <pekkas@netcore.fi>
Jonne Soininen <jonne.soininen@nokia.com>
The minutes were edited by Bob Fink from notes taken by Juha Wiljakka and
Itojun.
There were over 300 folk in attendance.
===========================
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 IETF Charter web page: <http://www.ietf.org/html.charters/v6ops-charter.html>
v6ops web site: <http://www.6bone.net/v6ops/>
v6ops Project Status: <http://www.6bone.net/v6ops/v6ops_project-status.html>
=======
Agenda:
Monday session
--------------
Introduction and agenda bashing - 5 mins, Chairs/Pekka
Process Issues for the working group - 10-15 mins, Chairs/Jonne
- Introduce the changes/enhancements to the WG process.
- How to move forward with Unmanaged, Enterprise and ISP
- GOAL: enable WG to work more effectively
Document status - 5-10 mins, Chairs/Pekka
- What has happened with WG documents lately
- GOAL: show the status of WG documents
3GPP Analysis Issues discussion, 15 mins, J. Wiljakka
- draft-ietf-v6ops-3gpp-analysis-07.txt
- Go through the open issues raised before and during the last call,
try to solicit comments from the WG.
- GOAL: try to gain some form of consensus on the issues, to be ready
to ship the document to the IESG after revision in Dec 2003.
ISP Scenarios/Solutions, 30 mins, M. Lind, V. Ksinant
- draft-lind-v6ops-isp-scenarios-01.txt
- draft-ksinant-v6ops-isp-analysis-00.txt
- present changes, solicit discussion on the ISP scenarios/solutions
- try to get meta discussion what the WG actually wants to do in ISP space
- GOAL: Show the latest developments in ISP space, get WG to discuss what
to do to move forward. Adapt both as WG documents.
Unmanaged Connectivity Tradeoffs discussion, 30 mins, T. Chown
- draft-chown-v6ops-unmanaged-connectivity-00.txt
- 10 mins presentation, 20 mins discussion
- describe the connectivity issues currently blocking the
unmanaged solutions document, discuss tradeoffs
- GOAL: try to get useful discussion on the tradeoffs of connectivity. Get
input whether this is the right direction to go to solve these issues.
IPv6-on-by-Default/On-link-bydefault tradeoffs - 25 mins, Sebastien Roy
- draft-ietf-v6ops-v6onbydefault-00.txt
- draft-ietf-v6ops-onlinkassumption-00.txt
- 5-10 minutes presentation/changes
- 15 minutes discussion
- GOAL: discuss changes since the last version, first time as WG document
- GOAL: make clear how to proceed with the onlinkassumption document.
Wednesday Session
-----------------
Unmanaged connectivity deployment model, 20 mins, C. Huitema
-status update from Monday + discussion
Transition mechanisms update, 10 mins, Erik Nordmark
- draft-ietf-v6ops-mech-v2-01.txt
- present the changes, 2 mins; discussion of issues, 8 mins
- GOAL: Discuss open issues and comments received during the
beginning of WG Last Call (if any).
Enterprise Scenarios discussion, 5 mins, Y. Pouffary, J. Bound
- draft-ietf-v6ops-ent-scenarios-00.txt
- 5-10 mins presentation, the rest discussion
- bring up the points where WG input would be useful, discuss those
- GOAL: allow the WG to go give input on the document, and help it go
forward.
SIIT/NAT-PT Applicability Statement - 15 mins, Suresh Satapati
- draft-satapati-v6ops-natpt-applicability-00.txt
- 5 minutes presentation, 10 minutes discussion especially the major issues
where the DT was divided
- GOAL: provoke discussion on NAT-PT/SIIT and generic translation, see
how the WG likes the document
IPv6 Applications Transition - 15 mins, Myung-Ki Shin
- draft-shin-v6ops-application-transition-02.txt
- 5 minutes presentation, 15 mins discussion
- GOAL: adopt as WG document, provoke discussion on application porting
guidelines
IPv6 Renumbering Procedures, 20 mins, Fred Baker
- draft-baker-ipv6-renumber-procedure-01.txt
- 5-10 mins presentation, 10 mins discussion of the issues
- GOAL: adapt as WG document, discuss how to make renumbering easier.
Forwarding Protocol 41 in NAT Boxes - 5-10 mins, Jordi Palet
- draft-palet-v6ops-proto41-nat-03.txt
- 2-3 minutes changes/presentation
- 5 minutes discussion on how to move forward, whether this is the right
approach
- GOAL: get WG feedback whether this is neutral enough, for
documentation purposes. Not being considered as WG item at this point.
IPv6 Firewalling Considerations, 10 mins, Pekka Savola
- draft-savola-v6ops-firewalling-02.txt
- 5 minutes presentation/changes, 5 minutes discussion
- GOAL: see whether the WG wants to adapt as WG item for Informational RFC.
Experiences with Dual Stack Service - 10-15 mins, Yasuhiro Shirasaki
- draft-shirasaki-dualstack-service-02.txt
- 5-10 minutes presentation
- 5 minutes discussion
- GOAL: disseminate how dual-stack access service has been deployed already.
(Authors pursue the individual Informational RFC path.)
========
Minutes:
======================================================
First Session: Monday, November 10, 2003 at 1300-1500
======================================================
Introduction and agenda bashing - Pekka Savola
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/agenda-status.pdf>
Pekka introduced the session and presented the agenda.
===
Document status - 5-10 mins, Chairs/Pekka Savola
- What has happened with WG documents lately
- GOAL: show the status of WG documents
<http://www.6bone.net/v6ops/v6ops_project-status.html>
<http://www.ietf.org/html.charters/v6ops-charter.html>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/agenda-status.pdf>
Pekka presented the current document status, including documents under
consideration as well as wg drafts.
-trans-mech - PS, review underway for DS/PS
-nat-pt - PS, applicability draft out, presentation Wed
-siit - PS, nat-pt applicability includes siit
-3gpp senarios - already RFC
-3gpp analysis 07 - need more feedback
-unmanaged scenarios 03 - just approved for info
-unmanaged analysis at 00 - will be revised
-enterprise solutions 00 - need to move forward, more discussions
-trans-mech at 01 - status at WG LC, considering DS/PS
goal: revise after LC, send to IESG if PS
-ipv6-on-by-default at 00
- get feedback an revise
-onlink assumption at 00 - get feedback and revise
-6to4 security at 00 - new editor added, under revision
-ipv4 surveys - Wg LC completed for every document, feedback solicited
-docs under consideration
ISP scenarios/solutions
unmanaged connectivity traeoffs
application transition
renumbering procedures
nat-pt applicability statement
firewalling considerations
some other documents
protocol-41 forwarding in NAT boxes
an example of dual-stack service
ipv6 using vlans in enterprises
ipv6 port-scanning implications
a view of transition architecture
many others, probably outside of *v6ops*
===
Process issues for the working group, 10-15 mins, Chairs/Jonne Soininen
- Introduce the changes/enhancements to the WG process.
- How to move forward with Unmanaged, Enterprise and ISP
- GOAL: enable WG to work more effectively
Jonne introduced the Issue Tracker concept. The Issue Tracker makes our
lives simpler, opens the wg process, scopes discussion and probably revitalizes
the wg. All wg docs (except those that are almost completed) go under issue
tracker control <http://rt.psg.com>. Issues are submitted on the wg mailing list
using a template and the wg chairs update the issue tracker. Document editor
then proposes an action: accept, accept with modification, or reject. Issues are
discussed on the list. Jonne showed the template based on the template used in
AAA wg and he also showed some examples.
- Chown: Can we combine comments, or send separate mails on all issues? Jonne:
to be considered case by case, e.g. minor comments can be combined.
- Carpenter: Simplifying the template would be nice.
- itojun: What about issues raised early October or November, do we have to
resubmit those? Jonne: Already discussed and handled issues need not be
resubmitted.
(other points were also raised, but weren't recorded; please send
corrections/additions)
Some WG participants felt that the
use of issue tracker would make their life more complex, due to requiring to
fill a template. The issue tracker was also discussed at the end of the first
session.
===
3GPP Analysis Issues discussion, 15 mins, Juha Wiljakka
- draft-ietf-v6ops-3gpp-analysis-07.txt
- Go through the open issues raised before and during the last call,
try to solicit comments from the WG.
- GOAL: try to gain some form of consensus on the issues, to be ready
to ship the document to the IESG after revision in Dec 2003.
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/3gpp-analysis.ppt>
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/3gpp-analysis.pdf>
Juha presented the document status and five remaining issues. No comments
were given after the presentation. Jonne Soininen asked, how many people had
read the latest document and how many people support moving forward with this
document. About 20 hands were raised for both questions.
===
ISP Scenarios/Solutions, 30 mins, Mikael Lind, V. Ksinant
- draft-lind-v6ops-isp-scenarios-01.txt
- draft-ksinant-v6ops-isp-analysis-00.txt
- present changes, solicit discussion on the ISP scenarios/solutions
- try to get meta discussion what the WG actually wants to do in ISP space
- GOAL: Show the latest developments in ISP space, get WG to discuss what
to do to move forward. Adapt both as WG documents.
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/ISP.ppt>
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/ISP.pdf>
Mikael briefly described generic ISP network, transition scenarios, future
stages and example networks. A generic view has been found and 4 concrete
examples are given in current documents. Scenarios have been updated and wg
comments have been taken into account. The documents are based on generic
approach on IPv6 transition.
Mikael asked whether more details, examples, or background information on current
IPv4 techniques are needed in scenarios document? The current draft has a loose
"core-access-exchange" separation. He asked whether improving this is needed
(reasons: restricting, not valid, too vague)?
The approach: going through generic issues, looking at ways of migrating core and
access separately, pointing out possible solutions and steps needed to be taken,
and not pointing out the "best" solution for a case. Analysis document generic
issues are core transition actions and access transition actions in analysis
doc.
Mikael asked
whether this is the right approach, or should we go deeper in details? He also
asked, whether there are other important issues to cover, such as addressing?
Way forward: continue working on the docs to reflect the wg consensus; getting
wg doc status.
About 20 people had read the scenarios doc and about the same
number of people thought that the scenarios doc is good enough to become a wg
doc. About 10 people had read the analysis doc. Pekka Savola wanted more people
to read the docs. There were no objections to the ISP Scenarios draft becoming a
wg draft.
Someone commented that the Analysis doc more useful for real life than scenarios doc, but more
details are needed.
===
Unmanaged Connectivity Tradeoffs discussion, 30 mins, Tim Chown
- draft-chown-v6ops-unmanaged-connectivity-00.txt
- 10 mins presentation, 20 mins discussion
- describe the connectivity issues currently blocking the
unmanaged solutions document, discuss tradeoffs
- GOAL: try to get useful discussion on the tradeoffs of connectivity. Get
input whether this is the right direction to go to solve these issues.
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/unman-nets-tunnels.ppt>
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/unman-nets-tunnels.pdf>
Tim presented Unmanaged Connectivity Tradeoffs.
There are many tunneling mechanisms defined for use by small end sites. Goals are
to identify desirable properties for tunneling mechanisms, and determining the
general tradeoffs to be made in transition mechanism selection. This draft does
not look at specific tunneling solutions for small end sites. Draft includes:
motivations for tunneling, tunneling architectures, and desirable properties of
tunneling mechanisms. Desirable properties are: security, simplicity, ease of
management, handling dynamic IPv4 addresses, support for hosts or sites,
scalability, NAT traversal, can be used behind one or more NATs, tunnel service
ownership, tunnel service discovery, support for special services, route
optimization, reverse DNS lookups available, and accountability.
Tim asked whether the document is useful, are any considerations missing, or
are any considerations irrelevant? He asked how to proceed with tradeoff analysis?
He noted that there are only four comments on the list so far.
Brian Carpenter: this is useful work; considerations: AAA is important and
security issues need to be looked at. Nordmark: comments on interactions between
considerations.
Savola: that's why we call them desirable features, not
requirements.
Huitema: comments on tradeoffs; unless all the mechanisms fulfill the same
requirements, you'll have to make a decision which requirements to leave
unfulfilled or whether you need more mechanisms to fulfill all the requirements.
Jonne: How to go forward? Tim: This will continue as a document of its own.
Pekka: tradeoff discussion is interesting and we must continue it on the list.
Huitema: concern here that there is too much on analysis and too little on real life
implementations.
Bob Hinden: Transition mechanisms should be produced, and we
should move on from making analysis documents. Transition mechanisms are already
in products and they must be standardized. We must not "overanalyze" things.
Pekka: we are chartered to make analysis work. We cannot move forward until
we're done.
Jonne: this document was originally meant to give input to Christian's work.
Jonne was worried about making this another analysis document.
Tim and Christian
will get together and figure out the way forward by Wednesday. One approach
could be combining the documents.
===
IPv6-on-by-Default/On-link-by-default tradeoffs - 25 mins, Sebastien Roy
- draft-ietf-v6ops-v6onbydefault-00.txt
- draft-ietf-v6ops-onlinkassumption-00.txt
- 5-10 minutes presentation/changes
- 15 minutes discussion
- GOAL: discuss changes since the last version, first time as WG document
- GOAL: make clear how to proceed with the onlinkassumption document.
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/IPv6onbydefault.pdf>
Sebastien presented IPv6-on-by-Default and On-link-by-default tradeoffs.
-
Introduction:
What happens when an IPv6 enabled dualstack host is placed in an
environment with less than adequate IPv6 connectivity?
Previous Presentation <http://playground.sun.com/ipv6/IPv6ONbyDefault.pdf>
This presentation will focus on outstanding issues and "what's new"
-
No IPv6 Router Scenario:
Problems with Default Address Selection's destination address ordering
– on-link assumption could defeat Rule 1
. Addressed by draft-ietf-v6ops-onlinkassumption-00.txt and
rfc2461bis work happening in IPv6 Working Group
– Rule 2 isn't sufficient in at least one case.
. Global destinations, site-local IPv4 src, link-local IPv6
src
. Rule 2.5 is suggested (avoid non link-local dst with
link-local src)
-
Transport Layer Robustness:
rfc1122's requirements for TCP's
handling of "soft errors"
– Soft errors are ICMPv6 Type 1 Codes 0 (No Route To Destination) and 3
(Address Unreachable).
– Cause connection delays if a better destination could be used.
– Possible solutions
. Abort connection attempt in SYN-SENT or SYNRECVD when
receiving a "soft error".
. Could attempt connections to all (or some?) destinations
simultaneously...
-
AI_ADDRCONFIG:
Only link-local address
configured.
Should getaddrinfo() query for IPv6 addresses when AI_ADDRCONFIG is
specified in this case?
Should this document address this?
---
Discussion:
Jinmei: what do you mean by "syn-sent or syn-recvd..."? there are multiple
variety of implementation for this part.
Rob Austein: past assumption: core network is crappy
Erik Nordmark: want to know background for tcp behavior.
someone: it is a historical limitation.
itojun: tcpm wg established; tcp is not the only problem.
---
Continuing on with the on-link-by-default slides:
-
What's new in
onlinkassumption:
Draft was born from
v6onbydefault to address specific problem and suggest a solution.
Background
– Manually configured hosts with different prefixes can communicate
on-link using this assumption
. Security
vulnerabilities
– Default router is "killed"
. Suggests removing
the assumption from the ND host sending algorithm.
-
What's next for onlinkassumption:
The draft's suggested ND changes may be
included in the rfc2461bis work happening inthe IPv6 Working Group.
If this occurs, should we move
this draft along to document the problem with the original rfc2461?
---
Discussion:
This will also be discussed in v6wg mtg.
Pekka and Dave Thaler: having separate document for 2461bis reasons is useful.
===
Discussion on how to develop the work done in the v6ops wg
As there was ample extra time at the end of the first session due to the small
number of comments on the first agenda items, an "open mike" session was held,
in particular about how we could get more out of the WG, and how to ensure the
work gets done.
Brian Carpenter: Range of topics in this wg and docs are difficult to read; it's
hard for people to read all the drafts. We need to be more aggressive when using
design teams; this many people cannot be organized to work on this number of
drafts. Anyway, the work is quite complex.
Tony Hain: Comments on how networks are operated; lots of operational history,
complex topics. There are segmented area of documents.
Someone: Priorize the work and make design teams for the low priority work ?
Randy Bush: Scenarios must be got ready and we must get back to work. Jonne:
Comments are needed.
Tom Petch: using the tracker was a lot of extra work, some of which I do not
know how to do (eg put in a URL for the e-mail which started the issue), much of
which could be done automatically.
Pekka: you can still comment on the list, but the most important issues must be
fed in to the issue tracker.
Jonne: if the template is not good, let's discuss that on the mailing list.
Jordi Palet : agrees with Randy. It is important to get scenarios & analysis
done, market is looking for real solutions. If we wait for this work to be finished,
then it probably is too late. Pekka: does Randy have good vision on work about
parallel issues?
Pete Barany: what about ngtrans mechanisms, 6to4, etc. Is there interest also for
e.g. ISATAP. Pekka: ISATAP has not been identified to be needed in current
analysis docs.
A conclusion: need to move forward with scenarios/analysis work, because they
are blocking other work / specifying transition mechanisms.
===
end of first session
==========================================================
Second Session: Wednesday, November 12, 2003 at 1530-1730
==========================================================
Introduction to session - Pekka
SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/agenda-wakeup.pdf>
Pekka presented the day's agenda and a wake up call to the wg participants:
wake-up call:
Perhaps it hasn’t been clear.. Scenarios/analysis is blocking work.
There will NOT be ANY protocol activity until we’re done!
At least for the area of the analysis document in question
Operational etc. documents are a separate subject
Worried that we miss a market window etc.? I worry about that as
well!
But the ONLY thing we can DO is FINISH scenarios/analysis
They’re not going to be finished sooner by waiting for someone else to
finish them!
Summary: we need YOU to finish the analysis!
Don’t look at the guy sitting next to you, we mean you!
===
Unmanaged connectivity (a continuation of the first sessions discussion) - Christian Huitema:
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/Unmanaged-Networks-tunnels.ppt>
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/Unmanaged-Networks-tunnels.pdf>
Christian presented more on discussion from Monday's session.
-
Unmanaged networks, tunnels, etc. (Huitema, Chown, Palet, Satapati, van der Pol):
automatic vs. configured tunneling
- automatic tunnels allow for automatic deployment (which applications like);
tend to work better between users of same technology, require relays towards
native IPv6, or other technologies
- configuration or brokered tunnels allow for more controlled service, often
better service (economics of providing tunnel services mostly make sense if
provided within single ISP; and it is not automatic)
-
Tunnel configuration needs work: current tunnel broker RFC is "conceptual" in
nature. We need to nail at least 1 scenario (provided by ISP. ISP customer
easily gets the parameters and tunneling mechanism works through NAT.
Discussion:
itojun: A proposal was sent previously, but that was blocked.
Christian: need to get a wg item of such mechanism .
Pekka: the mechanism does not have an RFC status.
Bob Hinden: I think we've already long since passed the market window.
Jim Bound: it has a hundred thousands users.
Bob Hinden: it is not Christian's fault that it has not moved forward.
-
Issue: Teredo relays
native -> Teredo communication needs relays
issue: no Teredo relays in the network, every native host has to implement a
Teredo relay, this creates a lock-in
Solution: implement Teredo relays in the network and run them until Teredo is
retired?
-
Do we have a consensus:
tentative algorithm: if native connection, use it; if tunnel service is
available, use it; if 6to4 is available, use it; if everything else fails, use
Teredo
Some people (incl. Savola) would rather never see people using 6to4 or Teredo
(but then, they should be provided native IPv6 or tunnel service!)
-
Incentives to "move forward":
stable addresses (native and tunnel solutions provide stable addresses,
adequate for entry in DNS, usage in web servers, etc.)
better performance (native IPv6 has lower overhead, does not involve relays)
multicast (6to4 or Teredo does not support multicast, configured tunnels
could, native IPv6 should)
-
=> Next steps:
update Unmaneval -00;
incorporate the tunnel consideration txt
revise the current text to reflect the consensus
recommend work on configured and opportunistic (e.g., 6to4) tunnels over IP
and UDP (e.g., Teredo)
Discussion:
itojun: multicast is supported over a tunnel.
Christian: yes, but as mbone showed, the encapsulation causes a bottleneck if
there are lots of tunnels on the same router, as the packet is duplicated at
egress. Multicast works better with native layer 2 support.
Pekka: point was that opportunistic mechanisms do not provide multicast support.
Christian: there is an easy way to learn tunnel parameters (DHCP, BGP, web page,
..)
Presented worries: end users run IPv6 over ISP networks without ISPs being
involved / know about it
Pekka: concern is that architecture built on using relays that needs to be in
place for >10 years
Bob
Hinden: agree on recommendation to work on these.
Tim
Chown: ISP needs to deploy IPv6, not only the customer! We should talk with the ISP people, making sure not having any gaps in
our document.
Jonne: new version, consensus, and wg last call is needed.
====
Work on Generic Transiition Issues documents
While waiting for the next speaker to step up, Pekka stated that there has been
a request to work on generic transition related topics such as: DNS,
Applications and Security. Please provide input if you think some other area
needs to be discussed, and input to the work being started.
===
Transition mechanisms update - 10 mins, Erik Nordmark
- draft-ietf-v6ops-mech-v2-01.txt
- present the changes, 2 mins; discussion of issues, 8 mins
- GOAL: Discuss open issues and comments received during the
beginning of WG Last Call (if any).
SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/basic-trans-mech.pdf>
Erik presented editorial changes (such as MTU changes, DNS changes, misc.
changes) and open issues (text talks about unidirectional tunneling, which has
some special issues regarding ingress filtering and ND usage: should we remove
this text or make IPv4 source addr text more accurate?)
Tim
Chown presented a clarifying comment on the open issue.
Dave
Thaler commented that we could remove the text.
Issues:
- formation of link-local address
Some comments were presented on this (itojun and others). Soininen proposed to
continue this discussion offline.
- Templin's tunnel MTU doc?
Fred gave comments on about fragmentation problem. Savola commented that we need
to move on and Fred can send text suggestions on the mailing list.
- State that dynamic tunnel MTU causes multiple losses when MTU drops...
- ND link-layer address option? (currently SHOULD NOT send; MUST ignore if
received)
- DNS: don't add AAAA until services on node support IPv6
- Make clearer that MTU of 1280 doesn't imply that MRU is 1280
- verify IPv6 source is ok before decapsulating
- site GRE w/ key field or AH/ESP for more secure
Pekka: IPsec over v6 over v4 tunnels; any implementations?
itojun: IPv4 transport mode IPsec can be used with RFC2893 tunnels.
Jim
Bound: IPsec router to router encapsulation.
Dave Thaler: a comment on static MTU case. Will be sent on the list.
===
Enterprise Scenarios discussion, 5 mins, Yanick Pouffary/Jim Bound
- draft-ietf-v6ops-ent-scenarios-00.txt
- 5-10 mins presentation, the rest discussion
- bring up the points where WG input would be useful, discuss those
- GOAL: allow the WG to go give input on the document, and help it go
forward.
SLIDES: <none used>
Jim reported that a new scenario draft had been issued, and that more comments needed;
specificall, there are questions included in
the draft that the authors need guidance on.
===
SIIT/NAT-PT Applicability Statement - 15 mins, Suresh Satapati
- draft-satapati-v6ops-natpt-applicability-00.txt
- 5 minutes presentation, 10 minutes discussion especially the major issues
where the DT was divided
- GOAL: provoke discussion on NAT-PT/SIIT and generic translation, see
how the WG likes the document
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/NAT-PT-applicability.ppt>
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/NAT-PT-applicability.pdf>
Suresh presented a report on the SIIT/NAT-PT Applicability Statement.
-
Goals:
To document the applicability of
• SIIT (RFC 2765)
• NAT-PT (RFC 2766)
-
SIIT Limitations:
• Usage of IPv4-mapped addresses
• Translation Semantics – ICMP error messages (embedded headers),
parameter problem
• Multicast will not work
• Limited support for IPsec ESP Transport mode (doesn’t support ICMP)
• IPsec ESP tunnel mode, AH doesn’t work
-
NAT-PT Limitations
• Difficult to cope up with ALG model to support applications
• All SIIT limitations + IPsec ESP transport mode doesn’t work
• DNS-ALG
– Failure modes for AAAA queries in IPv6->IPv4 direction
-
Applicability:
• SIIT
– header conversion algorithm is useful
– IPv6 hosts are *really* not IPv6-only
• RSIP style
• NAT-PT
– Legacy v4 nodes
– Special purpose networks – 3gpp
• 3GPP hosts, running SIP-based IMS applications
over IPv6, must be able to communicate with IPv4 SIP hosts
• For IMS media translation
– a proxy supplies the mapping as
opposed to SIP-ALG
-
Next steps
• WG item ?
---
Discussion:
Comments on IPv6-only networks: IETF does not mandate what kind of nodes shall
be built.
itojun: what comes to translation technology, RFC 3142 should also be looked at.
Randy Bush: What comes to communication of IPv6-only nodes to legacy IPv4 nodes;
if we are lucky, that could happen in 10-15 years. So this is not needed in this
document. 3GPP is a "single application" and a single translator is needed [that
is not necessarily NAT-PT].
After that, there was some discussion on IPv4-only deployment (e.g. Fred Baker
and Jim Bound). There also was a comment that China Mobile is deploying
IPv6-only.
Rob Austein asked who has implemented NAT-PT? Only a few hands were raised. He
said that is not so easy a thing to implement and he also listed properties that
makes NAT-PT broken. He further commented that the document should be more mean
and say the bad things about NAT-PT.
Satapati said that the text has been
improved already and some changes to wordings can still be made.
Christian
Huitema: IPv6-only networks = networks that only manage v6 routing tables.
The chairs asked for a showing of hands:
Capable of making decision now: 2 / not capable: ~7 => cannot be decided yet
.
Brian
Carpenter asked an extra question: is this important work to adopt in the
future? Many people "voted" for that.
Conclusion was to continue work on this document, but not yet giving it wg draft status.
===
IPv6 Applications Transition - 15 mins, Myung-Ki Shin
- draft-shin-v6ops-application-transition-02.txt
- 5 minutes presentation, 15 mins discussion
- GOAL: adopt as WG document, provoke discussion on application porting
guidelines
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/app-aspects.ppt>
<http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/app-aspects.pdf>
Myung-Ki introduced technical and editorial changes for IPv6 Applications
Transition from revision -01
-> -02.
Discussion & next steps:
- general points (disc. on application aspect, application development
guidelines);
- open issues (4.2., 6.2, 7, 8);
- adopt as a wg item (get feedback from app area; coordinate GGF IPv6 WG)?
Discussion:
Tim Chown: very good work, recommend it going forward.
Brian Carpenter: GGF document has a bit different scope.
Jonne: maybe we need not to liaison GGF? Carpenter said that there is
liaison already.
The IPv6 Applications Transition draft was adopted as a wg draft.
===
IPv6 Renumbering Procedures, 20 mins, Fred Baker
- draft-baker-ipv6-renumber-procedure-01.txt
- 5-10 mins presentation, 10 mins discussion of the issues
- GOAL: adapt as WG document, discuss how to make renumbering easier.
SLIDES: <none submitted>
Fred presented IPv6 Renumbering Procedures.\
Points in Fred's presentation:
- we would like to be able to be without renumbering networks
- Not trivial: applications use hard-coded addresses and router configurations
do too
- stepwise approach: deploying a new prefix in routers -> wait until routing of
new prefix is stable -> let applications start using the prefix -> wait -> have
applications to stop use the old prefix -> wait -> remove the old prefix ->
done.
- similar changeover required in applications; servers have to be running the
new prefix before their clients can rely on them.
Haberman: recommendations on what kind of automatic tools / fixes should be
used?
Baker: a number of recommendations can be given, but not sure putting
those in the doc. When starting to work on this, Baker got many suggestions.
When showing hands, many people thought that
- this is useful work
- this is correct wg for this work
- this document is ready to become a wg doc
The document was taken as WG work item, pending the no objections are raised on
the list.
===
Forwarding Protocol 41 in NAT Boxes - 5-10 mins, Jordi Palet
- draft-palet-v6ops-proto41-nat-03.txt
- 2-3 minutes changes/presentation
- 5 minutes discussion on how to move forward, whether this is the right
approach
- GOAL: get WG feedback whether this is neutral enough, for
documentation purposes. Not being considered as WG item at this point.
SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/proto41-nat.pdf>
Jordi presented Forwarding Protocol 41 in NAT Boxes.
The document gives operational guidelines how to use IPv6 traffic over NAT boxes
using regular tunnels.
- used only when native IPv6 and 6to4 not available
- address translation performed by NAT are session
- Applicability : clarified how it work
NAT and Tunnel Broker considerations; indicative figures from on-going survey;
can coexist with 6to4. Security considerations are the same as in Savola's
draft.
Further feedback needed; will continue the survey as a personal document.
===
IPv6 Firewalling Considerations, 10 mins, Pekka Savola
- draft-savola-v6ops-firewalling-02.txt
- 5 minutes presentation/changes, 5 minutes discussion
- GOAL: see whether the WG wants to adapt as WG item for Informational RFC.
SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/firewalling.pdf>
Pekka presented
IPv6 Firewalling Considerations.
The document describes firewalling issues related to IPv6; 3 types of issues:
issues in IPv6 specs, issues related to e2e nature of IPv6, and other issues.
Actions needed elsewhere were discussed.
Future steps: input received from firewall vendors, consider adopting as wg item
as informational?
Discussion:
Bob
Hinden: Any feedback from firewall industry? Pekka: Yes.
Greg Lebovitz: What is the target audience: firewall vendors, operators or what?
Pekka does not look at requirements, mainly collecting issues related on
firewalls in the document.
In the meeting, many people found the area interesting. Interesting & worth
proceeding: not so many.
Christian: concerned if more and more work is taken in this wg. Is it IETF's
role to explain how firewalls work; this is a bit out of scope.
Pekka: Charter lists security issues regarding to IPv6.
Jonne asked question: does this fall in the scope of this wg: 10 hands; 3
people thought that this does not fit in this wg.
Bob
Hinden: there's value to document the things that are different in IPv6 compared
to IPv4. Maybe it is useful to complete & publish this.
Jonne: Encouraging Pekka to continue work, but not yet making a wg item.
===
Experiences with Dual Stack Service - 10-15 mins, Yasuhiro Shirasaki
- draft-shirasaki-dualstack-service-02.txt
- 5-10 minutes presentation
- 5 minutes discussion
- GOAL: disseminate how dual-stack access service has been deployed already.
(Authors pursue the individual Informational RFC path.)
SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-58-Minneapolis/dualstack-service.pdf>
Yasuhiro presented Experiences with Dual Stack Service.
- Shirasaki told about NTT Communications' IPv6/IPV4 dual stack service
- simple selection and combination of proposed protocols and test of them
- Autoconfiguration parameters: site addr prefix / host address; DNS recursive
name server address, etc.
Experiences: works well since summer 2002; no impact on IPv4 single stack CPE
(IPv6CP initiated from CPE side is a trigger); nation wide service via L2TP;
other ISPs in Japan are using same spec (1000+customers).
Discussion:
Tim
Chown: Checking this with unmanaged team?
Pekka: Authors of this document are going to continue on individual submission
path.
===
Final notes before adjourning
After all the presentations, Pekka commented that the ISP documents will be
combined, i.e. there will only be one ISP document, to make the problem easier
to tackle and speed it up.
Soininen commented that IPv6-only discussion on the list is a good thing.
===
Meeting adjourned.
-end
