V6OPS MINUTES final version of 24Mar04
==========================
IPv6 Operations WG (v6ops)
IETF-59, Seoul, Korea

Monday, March 1 at 1530-1730
Thursday, March 4 at 1530-1730

======
CHAIRS:

Pekka Savola <pekkas@netcore.fi>
Jonne Soininen <jonne.soininen@nokia.com>

The minutes were edited by Pekka Savola and Bob Fink from notes taken by
Juha Wiljakka (both sessions), Alain Baudot (1st session) and TJ Kniveton
(2nd session).

There were over ??? 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, 1st Mar: 1530-1730
==========================

Introduction and agenda bashing - 5 mins, Chairs/Jonne
    - Scribes! (Jabber also?)

Document status - 10 mins, Chairs/Pekka
    - What has happened with WG documents lately
    - GOAL: show the status of WG documents

Introducing IPv6 in MPLS Networks - 20 mins
   - Discuss the approaches: configured tunneling, signalling upgrade,
     BGP tunneling hacks, etc.?
   - GOAL: try to get closer to consensus on what's required to use
     IPv6 in MPLS-based networks.

"Zero-configured" & Opportunistic Tunneling (esp. NAT traversal) Discussion
- 40 mins, P. Savola
   - Do we agree that this is something we need in the first place?
      * And if so, in which specific scenarios?
   - What are the models for deploying relays (in-host, in-site vs network)?
     What are the implications?
   - GOAL: try to get closer to consensus on what's the right approach
     for opportunistic tunneling.

IPv6 Distributed Security Requirements - 10 mins, J. Palet
   - draft-palet-v6ops-ipv6security-00.txt
   - quick overview of new kind of security requirements
   - GOAL: introduce the issue

Thursday, 4th Mar: 1530-1730
============================

Tunneling Scenarios Analysis - 20 mins, Chairs
   - introduce issue, first discussion continue later

IPv6 Mobility Scenarios/Requirements in 3GPP - 10 mins, C. Williams
   - loosely based on draft-yamamoto-mipv6node-v4trav-00.txt
   - discuss 3GPP2 IPv6 mobility and transition issues
   - GOAL: understand the scenario and its requirements

Transition mechanisms update - 10 mins, Chairs/Pekka
   - draft-ietf-v6ops-mech-v2-02.txt
   - draft-savola-v6ops-mechv2-interop-impl-template-00.txt
   - should be already at the IESG, discuss issues if any
   - Discuss implementation reports / interop testing
   - GOAL: Iron out last-minute issues, and make it easier to go to DS

IPv6 Renumbering Procedures - 10 mins, F. Baker
   - draft-ietf-v6ops-ipv6-renumber-procedure-00.txt
   - discuss changes, solicit input
   - GOAL: prepare for WG last call

Statistics from a 6to4 Relay - 5 mins, P. Savola
   - (no draft)
   - quick presentation on the usage statistics from a public 6to4 relay
   - GOAL: give the WG an impression about the traffic on 6to4 relays

Tunneling Scenarios Analysis continued - 45 mins, Chairs

Quarantine Security Model - 10 mins, S. Kondo
   - draft-kondo-quarantine-overview-00.txt
   - quick overview of a possible security model for IPv6
   - GOAL: introduce the issue, to be fully discussed in security area


Skipped due to lack of time:

IPv6 Security Overview - 10 mins, P. Savola
   - draft-savola-v6ops-security-overview-02.txt
   - introduce the approach; discuss changes.
   - GOAL: discuss whether something like this is needed
     as WG item, adapt if so.

6to4 Security Considerations - 10 mins, P. Savola
   - draft-ietf-v6ops-6to4-security-01.txt
   - discuss changes, solicit input whether the substantial changes
     to the document layout helped.
   - GOAL: prepare the document for WG last call

========
Minutes:

======================================================
First Session:  Monday, March 1, 2004 at 1530-1730
======================================================
Introduction and agenda bashing - 5 mins, Chairs/Jonne
    - Scribes! (Jabber also?)

SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/v6ops-agenda.pdf>

Jonne introduced the session and presented the agenda.

===
Document status - 10 mins, Chairs/Pekka
    - 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-59-Seoul/v6ops-agenda.pdf>

Pekka presented current document status.

- ISP Scenarios-Analysis: wglc held
- Enterprise scenarios  at -01; feedback & revision needed -> wglc; No work
yet on enterprise analysis/solutions doc
- Appl. transition doc revised, English proofread, in wglc -> 20.3; sent to
IESG after that
- v6 on by default to wglc soon after Seoul, no presentation in Seoul
- Onlink assumption at -00, revision & wglc after Seoul
- 6to4sec at -01; one more revision before wglc?
- Renumbering procedures at -00, try to finish by IETF#60
- IPv4 surveys, all in RFC Editor's queue
- Other, very critical work: IPv6 in MPLS nws, tunneling service
resolution, opportunistic tunneling
- Some other interesting docs: transarch -03, IPv6 DNS issues and
considerations (2 dnsop wg docs), unique local IPv6 addr.,
    3GPP2 or other IPv6 mobility scenarios, guide to mapping IPv4 subnets
into IPv6

Document Status:

RFCs:
- Trans-mech PS, revision sent to IESG for PS, no IETF LC yet.
    Implementation & Interop report template proposed; To be discussed
- NAT-PT PS, NAT-PT applicability draft would require revision
- SIIT PS, NAT-PT applicability draft also includes SIIT
- 6TO4 PS, 6to4 security analysis is WG item, presented on Thu
- 6TO4 anycast PS, no activity
- 3GPP scenarios published as info RFC, analysis in IETF LC

WG Documents:
- 3GPP analysis IETF LC ended 1.3.04, UE tunneling to be considered
separately; minor issues raised by AD
- Unmanaged scenarios, at -03, in the final throes of the RFC-Editor process
- Unmanaged analysis, at -01; WG Last Call just ended; Will likely need
revision, then send to the IESG?
    Try to work on some consensus on the mechanisms proposed
- ISP Scenarios & Analysis, at -01; WG Last Call just ended; Need to
resolve MPLS networks recommendation
    If possible, send it to the IESG in Mar/Apr
- Enterprise scenarios, at -01; Waiting for feedback, revision after Seoul;
WG Last Call after that
- Enterprise solutions; No current work -- feel free to write something;
Sooner rather than later!
- Trans-mech update, at -02; Status: sent to the IESG for PS, not reviewed
by AD yet
    Implementation & Interop report template proposed; To be discussed
- Application Transition, at -01; Revised, and English proofread; in WG
Last Call
    To be sent off to the IESG after that.
- IPv6-on-by-Default, at -01; To be WG last called after Seoul
    Presentation dropped because of last-minute cancellation
- Onlink assumption, at -00; To be revised and WG LC'ed after Seoul
- 6to4 security, at -01; Solicit feedback on -01; presentation on Thursday;
Revise once? before WG LC.
- Renumbering procedures, at -00; Solicit feedback; Try to finish just
before/around San Diego IETF?
- IPv4 surveys; All done -- being edited by RFC editor

Other work to be done:
* Very critical work:
- IPv6 in MPLS networks resolution
- "Tunneling service" resolution
- "Opportunistic" tunneling resolution
* Follow-up work
- Protocol work; Either here or in other WGs
* Potential new work
- IPv6 Security Overview?

Some other interesting documents:
- A view of transition architecture
    draft-savola-v6ops-transarch-03.txt
- IPv6 DNS Issues and Considerations
    draft-ietf-dnsop-ipv6-dns-issues-04.txt
    draft-ietf-dnsop-misbehaviour-against-aaaa-00.txt
    etc.
- Unique Local IPv6 Unicast Addresses
    draft-ietf-ipv6-unique-local-addr-03.txt
- 3GPP2 or other IPv6 Mobility scenarios
    [several drafts]
- Guide to mapping IPv4 subnets into IPv6
    draft-schild-v6ops-guide-v4mapping-00.txt

===
Introducing IPv6 in MPLS Networks - 20 mins, P. Savola
   - Discuss the approaches: configured tunneling, signalling upgrade,
     BGP tunneling hacks, etc.?
   - GOAL: try to get closer to consensus on what's required to use
     IPv6 in MPLS-based networks.

SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/v6-in-mpls.pdf>

Pekka presented IPv6 in MPLS networks.

IPv6 in MPLS networks
- The biggest unresolved issue in the ISP analysis
- How to deploy IPv6 in the MPLS networks?
    Options
      Require deploying native IPv6 support
      Require MPLS network to support setting up IPv6 LSPs
      Use IPv6-over-IPv4 configured tunneling
      Use an automatic tunneling mechanism to set up v6-in-v4 tunnels in the
network
- The first and second are longer-term options
    Well, could be done in the short term as well..
    The exact details what is required for the control plane upgrade are 
unclear
- The third is a simple option, and works very well
    However, if IPv6 is added on all the edge routers, setting these up is
cumbersome..
- The fourth is the "lazy man's solution" to configured tunneling
    More on this in the next slide

Automatic tunneling in MPLS
- Automatic tunneling =~ "BGPTUNNEL"
    Cisco has claimed IPR on this, not clear which parts of the spec
    Its relation to Cisco's "6PE" is a bit unclear
      Some say they're the same
      Some think BGPTUNNEL has cruft in it, and would need a clean-up
    Other implementations, do they interoperate?
- Vendor has sold hardware which doesn't do v6, needs workaround
    Or doesn't do v6 well enough
    Is it IETF's problem work around such "reasons" ?
- What's wrong with IPv6 LSP set-up deployment?
    Takes time to implement and/or upgrade?
    Folks don't want to upgrade their MPLS signalling plane
      Not sure if a valid reason, as upgrades happen in any case..
- Why not configured tunneling?
    Want to set up large IPv6 networks with "featureless" hardware

Discussion:

Xiaobao Chen / Orange: large mobile operator with experience on MPLS.
Commenting why not configured tunneling: static MPLS tunneling has much
drawbacks (performance, QoS, lacks in traffic engineering).
Pekka: I don't think we're talking about the same thing.
Static IP Tunnels vs. Static LSPs.

Jonne rephrased the question to clarify.

itojun: he says they already have traffic engineering capability in MPLS,
and they do not want to have to do it again.

Dan Williston (?) from Cisco (that has 6PE experience): 6PE is marketing
name for BGP tunneling in Cisco.
Pekka: A Cisco guy has commented that it  isn't.
Cisco guy: Commenting why not dual stack deployment instead: Benefit
of 6PE is that it allows ISP to put IPv6 only in PE nodes, it also makes
IPv6 deployment easy. What about IPv6 LSPs - it is much more complicated.
Why not  manually configured tunneling: It is harder to maintain,
conf. tunnels may be ok in smaller networks.

Tony Hain: why does IETF mandate people to run networks the same way.
Different networks have different problems, different approaches need to be
taken into account.

Mat Ford (BT): A document telling benefits and drawbacks of different
solutions would be useful.

Showing hands:
1) BGP tunneling or similar is needed? => Quite many hands up (rather many)
2) No need for BGP type of tunneling => (a couple)  hands
=> rough consensus: work on BGP tunneling for providing IPv6 over MPLS.

===
"Zero-configured" & Opportunistic Tunneling (esp. NAT traversal) Discussion
- 40 mins, P. Savola
   - Do we agree that this is something we need in the first place?
      * And if so, in which specific scenarios?
   - What are the models for deploying relays (in-host, in-site vs network)?
     What are the implications?
   - GOAL: try to get closer to consensus on what's the right approach
     for opportunistic tunneling.

SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/opportunistic-zeroconf-tunneling.pdf>

Pekka presented "Zero-configured" & Opportunistic Tunneling, work that he
and Jonne prepared.

"Opportunistic" vs zero-configured
The concepts
- "Opportunistic" in Internet domain
    Minimal or zero infrastructure
    Connectivity between peers set up in an "ad-hoc" fashion
    Required if assuming "vendor-driven" deployment
      When the vendor requires IPv6 for enhancing its functions (e.g.,
peer-to-peer libraries)
      In contrast to user installing a new shiny application which requires 
IPv6
    E.g., 6to4, Teredo
    Applicability: when the direct ISP doesn't offer service
      Tunnel broker typically not available close by, or easy enough to set up
- "Zero-configured"
    "Configured tunnel" or similar but not configured manually
    Tunnel-end -point discovered automatically
      E.g., STEP or ISATAP; TSP with some discovery mechanisms
    Applicability
      3GPP networks, direct ISP offering tunnel, enterprise -internal tunneling

"Opportunistic" vs zero-configured
- What's so special about opportunistic?
    There was a long threat on the list
    Not sure if it resolved much of anything..
    Some (many?) see there is no purely "vendor-driven" approach
      Or if there is, we should not be recommending it
    If so, automatic tunneling maybe not be a strict requirement
- Critical point of opportunistic vs others
    Whether infrastructureless, even partial, deployment is desirable
      And how critical that infrastructure is
    How much to weight in the favor of "less infrastructure"
    Economics of deployment is also a factor - against both approaches
    Anonymous services are better for 3rd party service providers
      6to4 relay with 192.88.99.1 vs Tunnel broker with native addresses

The different scenarios
- Unmanaged user wants to do p2p with another
    Direct "short-cut" connectivity very important
    If no support from the direct ISP
      Automatic tunneling works automatically: Teredo requires "Server" with
low b/w reqs
      Tunnel broker would help, if the users could find a free broker nearby
      If there would be incentive for broker deployment, a "nearest broker
discovery"
        process would also help
      Unless the user is really determined, the user is lost without
automatic tunneling
    If there is support from the direct ISP
      Dual-stack or; tunnel broker or a simple configured tunneling system
      If only one supports, still OK without infrastructure if "local" relays
- Enterprise internal network wants to deploy v6
    Zero-configured tunneling, configured tunneling, or dual-stack
- 3GPP user wants to use v6
    Zero-configured tunneling or dual-stack
      The operator should provide a service, and if doesn't, similar to
"unmanaged"

Opportunistic relay deployment
- Relay deployment
    Native to 6to4
      All dual-stack sites could have a relay, just turn on 6to4 pseudo-i/f
      But currently don't..
      Would place the "burden" of deployment on native users
    6to4 to Native
      Very difficult, but not worse than Tunnel Broker..?
    Native to Teredo
      All the sites could have a relay
      But currently don't, and not sure if a good idea..
      Would place the "burden" of deployment on native users
    Teredo to Native
      Very difficult, similar to 6to4..?
    6to4 to Teredo
      Sites could have an internal Teredo relay
    Teredo to 6to4
      Nodes could have an internal 6to4 relay
        But some NATs might block proto-41 at egress

"Zero-configured"
Teasing out "Zero-configured"
- Critical questions are at least
    How important is 3rd party ISP tunneling? Are solutions required?
      If yes, who would want to provide *production* service using their
IPv6 addresses?
      Would imply long tunnels, bad quality and bad IPv6 experience.. like
today's 6bone
    How much should we use existing tools/mechanisms, if available?
      NAT traversal, authentication, prefix delegation, DNS discovery, etc.
      Should be generic so that a node that is used in unmanaged or
enterprise, with native or
        tunneling, doesn't have to multiple methods?
      Implement from scratch ("short term fix"), develop good tools ("long
term solution")?
    How desirable is "opportunism" inside the ISP/3GPP or site?
      The tradeoff: if the traffic grows too much, it's time to enable
native IPv6?
      Inside the ISP: (the neighbors wanting to talk p2p): probably not 
critical
      Inside the 3GPP: depends on how much traffic between UEs; the IPv6 
status?
      Inside the enterprise: in larger sites, possibly desirable (e.g., p2p
videoconferencing)

"Zero-configured" solutions
"Zero-configured" solution properties
- Direct connectivity between (some) peers
    ISATAP: yes
    Others: no
- Use of existing tools
    TSP: reinvents all discovery/config functions
    ISATAP: mostly new
    STEP: client - only little new; server - a bit
    L2TP architecture: uses only existing tools
- 3rd party tunneling (critical: authentication)
    TSP and L2TP: no problem if 3rd party ISPs exist ;-)
    STEP and ISATAP: out of scope or not applicable

Discussion:

Xiaobao Chen asked a clarifying question on why tunneling needed in 3GPP
networks at all.
Jonne answered: noticed that some operators have problems, because current
SGSNs do not support IPv6. Best way is deploying native IPv6 support
(IPv6 PDP contexts), but UE tunneling may be needed in some cases,
especially in roaming cases.
Chen: Are you talking about user IP layer or transport IP layer in 3GPP
networks?
Jonne: This discussion is not about MPLS, this is user a layer issue.

- What is so special about opportunistic / long thread on the mailing list,
not sure if it resolved anything... Some see there is "vendor-driven"
approach. If so, automatic tunneling maybe not be a strict requirement
- Critical point of opportunistic vs. others: infraless deployment is
desirable, how much in favor of less infrastructure; economics of
deployment is also a factor - against both approaches; anonymous services
are better for 3rd party service providers.

Spencer Dawkins: discussion on the mailing list specifying source address
specification.
Pekka: I don't remember this discussion lately...

Pekka: We have run a public 6to4 relay for 2.5 years for third parties;
wouldn't do that with our own IPv6 addresses, w/ tunnel server.
Erik Nordmark comments: IPv4 and IPv6 addresses... [question related to
operational problems and DNS? -- was not recorded]

different scenarios:
- unmanaged users wanting to do peer-to-peer with another: direct short-cut
connectivity very important; if no support from the direct ISP (automatic
tunnels work automatically, Teredo requires serve, tunnel broker would
help; unless the user really is determined, the user is lost w/o automatic
tunneling); if there is support from the direct ISP (ds or tunnel broker or
a simple configured tunneling system; if only one supports still ok without
infra if "local" relays)
- Enterprise internal nws want to deploy IPv6: zeroconf, configured, dual stack
- 3GPP user wants to use IPv6: zeroconf tunneling or dual stack (the
operator should provide a tunneling service and if not, the case is similar
to unmanaged case

Chen: what do you mean with operator service provision?
Pekka: 3GPP operators should provide native IPv6 service, but if not,
then tunneling is needed.

- Relay deployment: native to 6to4, 6to4 to native, Native to Teredo,
Teredo to native, 6to4 to Teredo, Teredo to 6to4
- Teasing out zeroconf / critical questions: how important is 3rd party ISP
tunneling / are solutions required?; how much should we use existing tools
/ mechs, if available?; how desirable is "opportunism" inside the ISP/3GPP
or site?  (the tradeoff: growing traffic->start to use native v6; inside
the ISP; inside the 3GPP (depends on how much traffic between UEs, the IPv6
status?; inside the enterprise: in larger sites possibly desirable (p2p
videoconf., etc.)
- Zeroconf: direct connectivity between the peers: ISATAP yes, others no
- Use of existing tools: TSP, ISATAP (mostly new), STEP, L2TP
- 3rd party tunneling (critical: authentication) TSP and L2TP

Tony Hain: Does not figure out what zeroconf and opportunistic is?
Scenarios docs are describing problems; solve generic problems here?
Should analyze issues and then pick up appropriate mechanism(s).
Jonne: Analysis has been done, we check are the tools that have been proposed
useful?
Pekka: we're trying to look at the mechanisms according to
scenarios/analysis context, but having done so, we have identified some
generic issues.
Hain: doesn't see distinction between two types of mechanisms; one might
apply in some cases, the other in others; must be answered based on the
applicability area.

Itojun: Does not get the difference between vendor driven and user driven.
All techniques have different target customers; how to make consensus call?
He has difficulties to see the distinction between the concepts. Mechanisms
like ISATAP, Teredo, etc. are separate and they all have different target
audiences.

Jonne: will ask about consensus at the the need for these mechanisms.

Hesham Soliman: in the scenarios work, we left out discussion on the
mechanisms; now we get back to discussing the mechanisms.

Jonne: actually we're following up the scenarios work.
Hesham: OK, but the presentation is not connected to scenarios.
Pekka: many mechanisms (up to 4) mayb be used for the same case, so
mechanisms have to be evaluated.
Hesham: Then discussion should not be generic, but on precise scenarios.

Chen: When thinking about solutions, you also have to consider downsides.
Is MPLS over IP considered in scenarios and analyses?
Jonne: Not discussing  MPLS tunneling in this slot, certainly no MPLS
in the 3GPP UEs. Core networks are separate.
Chen: practical problems need to be considered.

Thaler: drivers beyond v6 are direct peer-to-peer communication,
whether with high bandwidth requirement or something like VoIP; this goes
together with direct connectivity.

Nordmark: Does not understand vendor / user driven separation

Hinden: understands the distinction, but thinks such distinction is not
useful.  All mechanisms are useful anyway.

Wiljakka: From cellular (3GPP, 3GPP2) networks point of view configured
tunneling in the mobile terminal does not look like a feasible alternative.
Especially in 3GPP networks that have large number of hosts, addressing is
dynamic and typically also private IPv4 addressing. In that  case,
automatic tunneling looks feasible and ISATAP is one alternative that looks
positive. (Pekka commented that now we talk about zeroconf tunneling). Juha
really recommends that this wg makes real work and specifies also automatic
tunneling mechanisms. Finally, Juha said that he agrees on the conclusions
on needed tunneling mechanisms in Unmanaged networks evaluation doc.

Jordi: The point is much simpler that we are going to figure out... A
way to automatically make sure that every client has IPv6 connectivity
available even when moving thru different networks. I'm having this
problem when traveling and I can sort it out most of the time because
have the expertise, but this is not the case for regular users. We
need a kind of auto-transition feature that choose the right protocol
from a set, no needed user intervention, but ensure connectivity even
if this is bad (worst case, for example, IPv6 over HTTP, of course I
will not suggest it, only in very extreme cases).

Hesham: Does not understand what does user-centric mean. People start using
IPv6, but the user is not asked about that...

Tony Hain: vendor that chooses to [push IPv6 to the users?]...
Pekka: I don't say that vendor-driven mode is bad, but it's a different
approach with different assumptions.

Tony: the problem is to get the list of mechanisms to become standard
Pekka: maybe we don't want to standardize all the mechanisms

Hain: you haven't got back to the scenarios in context.
Hain: Internet is not one tiny network, it is a big bunch of networks

Nordmark: users want to use net for different applications: email, chat,
... The users are the entity using the services. Classification is not
useful -- if the user doesn't want to do something, vendor should not force
him. To Tony: cutting down is useful; should we have standardized different
flavors of TCP and UDP to fill different roles, instead of two basic
mechanisms?

Mohsen Souissi: One of the best things in this wg is that we have identified
different scenarios and tools. Do we want to deploy real networks with NAT
traversal etc. In the production networks we need best tools and best
security.

Jordi: we want to deploy IPv6 - if we make tools perfect, it takes so
long that we will miss the train. Not so sure how many mechanisms must
be specified. There are many possible networks, many possible
scenarios, I insist that we must ensure that the client can have IPv6
connectivity in any case, automatically, a kind of auto-transition, of
course, trying to use the best possible solution.

Chairs suggest to post-pone discussion to next session on Thursday.

Bob Hinden: Just ask the question, don't wait any more. We have fooled around
for 3 years already.

What to ask?

Tony Hain: We do not understand bullets?

Jonne: 6to4 is out from this discussion.

David: Lots of people in this room are ready to answer; go on and ask the
question.

Consensus call (raising hands):
   1) Is opportunistic tunneling needed => many hands; a few hands against.
   2) Is zeroconf tunnel needed to be standardized => many hands; nobody 
against.

=> Consensus: both are needed and will be standardized.

Clarification: no consensus standardizing all of them, mechanisms will be 
selected.
Implementation and deployment is a pro for mechanisms that will be forwarded.

More detailed questiosn to be asked on Thursday.

Dave Thaler: still confused what zeroconf menas, voted for it, but not sure
what it meant.

David K: We need the opinion of the people. Selection of mechs need to be
done based on scenarios.

Jonne: we have to analysze the different solutions with scenarios to
identify the best ones.

Droms: opportunistic/zeroconf is not a realistic division

===
IPv6 Distributed Security Requirements - 10 mins, J. Palet
   - draft-palet-v6ops-ipv6security-00.txt
   - quick overview of new kind of security requirements
   - GOAL: introduce the issue

SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/ipv6-security.pdf>

Jordi Palet presented IPv6 Distributed Security Requirements.

Motivation:
Border firewall is a bottle neck and does not enable end to end security.
Many users and devices are nomadic, so static model does not apply.
Different visited network have different security policies.
Devices have extra power to process bigger security processes.

Solution:
Use of personal firewalls, which should be enabled by default; should look
at security policy of visited network; could deal with IDS; may cope with
virus and spam

Concept:
Attack/threat: active or passive; security is protection and IPSEC is used;
need policy management tool, policy decision point.
Typical architectural scheme is shown.

Discussion:

Unknown: suggest to have a look at netconf or sipping WG where they are
also dealing with the same kind of things.


======================================================
Second Session:  Thursday, March 4, 2004 at 1530-1730
======================================================
Modified agenda for 2nd day:

<http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/v6ops-agenda2.pdf>

===
Tunneling Scenarios Analysis - 20 mins, Chairs
   - introduce issue, first discussion continue later

SLIDES: 
<http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/scenarios-tunneling-analysis.pdf>

Pekka presented Scenarios tunneling analysis.

Introduction
- First
   Check scenarios defined in the scenarios/analysis in more detail
   Try to tease out the subcases of the scenarios
   .. to understand the real cases better.
- After that
   Look at the properties of the solutions compared to scenarios
   Find one or more (as few as possible) recommended mechanisms
     Find consensus on the mechsnism(s) today, or very soon
     Reach consensus, be sent for PS before San Diego (hopefully)
   Publish the specs describing current implementations
     Informational/Experimental through RFC-editor
     With an applicability statement or IESG note
     After consensus which mechanism(s) for PS

Scenarios tunneling analysis 1/3
- 3GPP Networks
   Need v6-in-v4 tunneling when roaming to IPv4-only 3GPP network
   May need v6-in-v4 tunneling where the 3GPP operator has not yet
   deployed IPv6 PDP context support at all
     But would support some IPv6 through a transition mechanism
   Support for no 3GPP support at all out of scope
     If appropriate, Unmanaged transition mechanisms can be used
- Issues
   Is node-to-node direct tunneling required inside the network?
     At least "nice to have"..

Scenarios tunneling analysis 2/3
- Unmanaged networks
   The ISP doesn't support any IPv6, user must get IPv6 automatically
     a) with little infrastructure, and without contracts, or signups
     b) with a contract, signup, for higher security/manageability, etc.
        -- explicitly from another ISP out there
     Long tunnels are bad and don't make much sense -- is b) a real 
scenario worth solving?
   The ISP wants to support IPv6, but AR/link/gateway can't do v6
     3 cases: tunneling from the gateway, separate v6 gateway, or the host(s)
     Solution to b) would work here as well -- but not necessarily the 
other way around
- Issues
   NAT and dynamic IPv4 must always be supported
   Direct tunneling and low amount of infrastructure is required when there
   is no ISP support
   Is node-to-node direct tunneling inside the same ISP required?
     it might "come free" by the use of 6to4/Teredo
     note: this gets VERY difficult when NAT is in the path!

Scenarios tunneling analysis 3/3
- ISP scenarios
   ISPs want to support unman/enterprise, nothing else
- Enterprise networks ????
   Scenarios work not gives no help on this yet..
   The enterprise wants to deploy IPv6 using internal tunneling.
     Does this need to be direct? "would be nice.."?
- Optional additional scenarios
   IP mobility (mainly 3GPP2) - node mobile, not stationary
     requires that time required for roaming signalling is low
     there may be a need for v4-in-v6 tunneling at least in some timeframe

Solution Summary
- Two tables: 
<http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/scenarios-analysis.pdf>

Solution Summary Obtained by combining the matrices
- Unman 1a) requires Teredo
- Unman 1b) and 2) require STEP or TSP (ISATAP is out)
- 3GPP 1) can be filled by STEP or ISATAP; no ISATAP if sec. req'd
- 3GPP 2) can be filled by STEP or ISATAP
   Only ISATAP if direct connectivity is a MUST requirement
- Teredo and STEP the [lowest] common denominator
   With Teredo + TSP coming a bit behind ?

Questions to the WG
- Does the proposal about Informational/Experimental
   publication make sense?
   Describing current implementations
- Is the analysis going to the right direction?
- Unman 1a) requires Teredo.
   Is there WG consensus for adopting that?
- Does WG feel that we have to find only one solution?
   (Except for Unman 1a) if decided already)
   Whether an existing one or a hybrid?
- If 1, can we choose between TSP, STEP and ISATAP?
   Or should an optimal combination proposal be made?

Bob Hinden: I still believe that the wg can move forward with these also 
forwarding the mechanisms that have been deployed already. If people are 
using a mechanism, we have to specify it.  We can work in parallel, no need
to delay until the next IETF.

Pekka: No indication of delaying the work until next IETF.

Bob: When woul dit start?

Jonne: Proposal from our ADs to go experimental with items which have been
on the table for some time, with a statement that v6ops 
wg will be working on a preferred solution.

Bob: Are we going to talk about the process today? It's not on these slides. 
After all this time, we should.

Pekka: it is on the first slide, so yes.

- publish the specs describing current implementations
   - info/exp through RFC-editor
   - with an applicability statement / IESG note
   - after consensus mechs for PS

Bert Wijnen: Current policy is not allowing experimental personal RFCs,
because that would be an end run around WG.  Now individual documents can go
forward, with disclaimer that  IETF is working on a standardizxed solution. 
Bob says OK.  That's a question you should propose to WG, but first
questions about analysis.

Tony Hain commented: It took 2,5 years getting to second last point, it is 
time to get it done.

Jonne: Analysis documents are stable now.  We are starting to develop
mechanisms that suit those analyses.  in parallel to that, we will allow
people to post as individual submissions those solutions that are already in
the market.

Erik Nordmark: Slide says current implementations.  Drafts describe
potential extensions to things that haven't been implemented yet.

Pekka: Exactly, we would encourage people submitting those drafts
describe current implementations, not what they could be.

Dave Thaler: Clarifying question on ISP bullet point #2, Pekka replied.
(what "not the other way around" meant)

Dave Thaler: As the slide says, enterprise scenarios document doesn't yet
give much help in what's required.  But Enterprises want v6 with little
overhead in any case.
Jonne: not discussing enterprise today, Dave should contribute to
Enterprise work.

Fred Templin: Experimental describes the implementations that are there. 
What about advanced features?
Jonne: We should document those implementations.
Pekka: The point is that someone can implement it and interoperate.
Documenting only the current implementations.

Fred Templin: Can extensions and improvements be proposed as work items?
Pekka: that would be input to the mechanism selection process.

Le Faucheur?: Comment on cross-referencing... Recommend referencing these 
docs? E.g. ISP scenarios - recommend that we reference for these docs there?

Pekka: Are you asking about how we should capture this presentation we are
having here?  We would integrate the ideas in the presentation with the
analysis documents.

Jonne: This document is what we think that the WG thinks.

Pekka: (When waiting for the next presentation to start)
No time to present application transition doc today, it's in WGLC,
send input on the list.

===
IPv6 Mobility Scenarios/Requirements in 3GPP - 10 mins, C. Williams
   - loosely based on draft-yamamoto-mipv6node-v4trav-00.txt
   - discuss 3GPP2 IPv6 mobility and transition issues
   - GOAL: understand the scenario and its requirements

SLIDES: 
<http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/ipv6mobility-trans.pdf>

Carl Williams presented Thoughts on IPv6 Transition for Mobile Nodes.

A number of us are looking at Mobile IPv6 deployment. We have an issue of 
not having ubiquitous IPv6 access to networks. Broader picture is that we 
have 2 mobility protocols, Mobile IPv4 and Mobile IPv6. Discussion in MIPv6 
and drafts; Henrik Levkowetz organized Bar BOF on Monday evening to talk 
about this.

Looking at mobility from transition perspective, how do we transition for 
MIPv4 users to MIPv6? Support for IPv4 seamless roaming for MIPv6 users?

Transition implications in choosing an approach - MIPv4 and MIPv6 are 
different protocols with different features.
There is an appendix in slides, with scenarios we have identified as important.

We were looking at providing only what base spec provides, in terms of 
performance.

Pekka: Any Internet ADs present that want to comment about this?

Jonne: Dave, you aren't an AD yet. Thomas?

Thomas: Wasn't paying attention.

Jonne: Question is where this discussion should go -- mobile IP working 
groups? here? somewhere else? Pekka asked if you can give us guidance now, 
or do you want to discuss further and coordinate between WGs?

Thomas: defer. v6ops is where we've been doing transition work and other 
groups not set up to do this yet.

Dave Thaler: Not clear to me what the distinction is as opposed to laptop 
doing existing transition mechanisms?

Henrik Levkowetz: MIPv4 and MIPv6 are designed to minimize overhead and 
signaling in movement. If you use current transition mechanism, you will 
have existing transition mechanism signaling, and then MIP signaling. So 
VoIP may be slow and painful. We have to analyze this to see what 
performance we get.

Erik Nordmark: Hard to balance what is the existing complexity vs. 
performance gains you could get. Complexity would be significantly higher 
than just layering on top of each other.

Henrik: We have implemented 1 scenario, and it required one more MIP 
extension and nothing else, the complexity was not great.

TJ Kniveton: In designing IPv6, mobility is an important factor. So mobility 
should be considered in looking at transition scenarios by this group or 
any group looking at it.

===
Transition mechanisms update - 10 mins, Chairs/Pekka
   - draft-ietf-v6ops-mech-v2-02.txt
   - draft-savola-v6ops-mechv2-interop-impl-template-00.txt
   - should be already at the IESG, discuss issues if any
   - Discuss implementation reports / interop testing
   - GOAL: Iron out last-minute issues, and make it easier to go to DS

SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/transmech-update.pdf>

Pekka presented an update on the Basic Transition Mechanism work.

Transmech status and steps forward
- Until now
   Updated -01 to -02
   No issues raised at the second WG LC
   Sent to the IESG, for Proposed Standard
- Next steps
   Wait for IETF Last Call comments (if any)
   Wait for IESG feedback and resolve
   Get consensus on implementation and interoperability reports
     Draft out, but no comments yet
- Next 6 months
   Wait for the implementations to be revised?
   Get the implementation & interop reports
   Revise the specification if needed
   Submit as Draft Standard

Transmech changes between 01 and 02
- Functional changes (at least)
   Unidirectional tunnels removed
   Remove DNS operational guidance, refer to another document
   Remove SHOULD req on link-locals being based on IPv4
   Add SHOULD requirement for setting source address of tunnel
   Add MUST checks for source addresses
   Should be possible to choose either static/dynamic MTU on per-tunnel
   basis if both implemented
   Static MTU can now default to anything between 1280 and 1480 bytes
     But if not 1280, knobs to set it MUST be in place
   Add minimal MUST rules for IPv4 reassembly and IPv6 MRU
   Summary
     Previous implementations should interoperate, but are non-compliant
- Editorial changes
   A lot..

Implementation & Interoperability
- Implementation status must be verified before DS
   Each feature
   In the draft, done in excruciating detail
- Interoperability of specific features must be tested
   Each feature must interoperate
   Also done in detail
   Organizing the actual testing it out of scope
     Does anyone want to volunteer to do something?
- Questions to ask
   Is using a detailed template a good idea?
   Should the template be returned separately for implementation and 
interoperability?
     The former is easier to fill, so we might get feedback faster..
   Other issues? Thoughts?


Question: is using a detailed template a good idea?
 - No hands for or against the template, but almost all just wanted to
   "get on with it", didn't care how.

Bob Hinden: I'm a little confused - you talked about requirements for 
implementation for draft standard, but we were just talking about 
publishing for experimental.

Pekka: This is about the basic transitions document that describes 
configured tunneling.

Bob: OK, didn't understand context.

===
IPv6 Renumbering Procedures - 10 mins, F. Baker
   - draft-ietf-v6ops-ipv6-renumber-procedure-00.txt
   - discuss changes, solicit input
   - GOAL: prepare for WG last call

SLIDES: <none submitted?>

Fred Baker presented IPv6 Renumbering Procedures.

- wg document, few changes
- the users may require tools or notifications...
- next steps: further review still appreciated (comments to authors or the 
v6ops list)

Erik Nordmark: What are the constraints on consistency of reverse vs
forward zones?

Rob Austein: I agree it would be good but if someone does make them
consistent, it would be the first time in recorded history.

Ralph Droms: more difficult than additional steps. There is a problem with 
authority of owning reverse zone, especially for mobiles roaming to 
different administrative domain.

Erik: Sure, but the site has authority to do this, whether it's an 
individual host or site.

===
Statistics from a 6to4 Relay - 5 mins, P. Savola
   - (no draft)
   - quick presentation on the usage statistics from a public 6to4 relay
   - GOAL: give the WG an impression about the traffic on 6to4 relays

SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/6to4-stats.pdf>

Pekka presented Statistics for a 6to4 Relay.

- We (AS1741) have been running public 6to4 relay since Nov 2001
- PC platform, highly programmable
- average kbit/s or pps is not too high; 15min estimate typically around 
20-100 kbit/s
- admin issues: only few users from their own nw (ds / tunneling for 
the  customers, i.e. a bit difficult to justify the service)
- no abuse has been reported; haven't detected any DoS attacks (the system 
can handle a lot of traffic so this is not a problem)
- Weird things: MS Windows probing a lot (a Win host sends a proto-41 
"probe" to 192.88.99.1) - ICMPv6 Echo Request with Hop Limit 1
- Windows probing - 500000 and growing. Clear raise from Apr 2004
- Some spikes that are difficult to PIN down
- 6to4 usage 01/2004: no clear conclusions on the picture
- Interesting to note: very low amount of apps at the moment; UDP/DNS 
actively used by many; ICMP still is an important IPv6 application;
- Conclusions: 6to4 is out there but not yet really in an active use (or if 
it is, it is between 6to4 nodes, not through the relay)

Erik Nordmark: were these DoS attacks on relay service, or attacks that 
went through the relay?
Pekka: Through relay.

Erik: You have some asymmetry. Are you attracting this traffic over IPv4 or 
because you're advertising the 2002:: ? Asymmetry - can it tell you 
something interesting about users and their location?
Pekka: We advertise both, but haven't looked into the details.

Tony Hain: 6to4 is in active use; I'm using it in the back of the room 
right now. You're probably missing a sequencing issue. If nodes are behind 
NAT, they'll use Teredo until they get past NAT. Nodes that are doing it 
are doing it between each other.

Jordi Palet: I totally disagree that there is traffic only between nodes. I 
use lots of networks and I am surprised that 80% of the time I get access 
via a 6to4 relay. There are not enough relays to be effective, but it's 
working.

Pekka: You are commenting that 6to4 can be used behind a NAT that does 
protocol 41 forwarding?

Jordi: No, when you attach to network and get public v4 address, you can 
reach 6to4 relay without configuring anything, depending on OS operating.

Pekka: 6to4 anycast relays being advertised but it might.

Robert Elz(?): When you look at TCP traffic through 6to4 relays, are 
connections being initiated by 6to4 hosts, or people trying to contact 6to4 
hosts?

Pekka: I got a feeling that a significant portion of the traffic is on 6to4 
hosts.

Rob Austein: I've seen traffic patterns lately. For anything involving bulk 
transfer of data that I have to sit there and watch, I use ssh over v4, 
because it's faster than v6. Daemons may use it more.

===
Tunneling Scenarios Analysis continued - 45 mins, Chairs

SLIDES: 
<http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/scenarios-analysis.pdf>

Pekka and Jonne continued the tunneling scenarios analysis discussion.

Jonne: We came up with a table about which scenarios should be supported. 
(see slides)
Pekka:to reiterate, to get ISPs to deploy something, it has to be very simple.
We did same thing for mechanisms that are on the table (see slides).
Any questions?

Florent Parent: What does secure mean, exactly?
Pekka: Good question. We were mainly looking at how the protocol has been 
specified, and whether it's open to abuse or attacks of mechanism user
Florent: The only one that supports user authentication is TSP.
Pekka: Authentication applies only to what prefixes you give. Doesn't 
secure data plane. Also, widely deployed means multiple vendors.

Erik Nordmark: notion of authenticated tunneling? Split apart secure thing 
into finer grain.

Pekka: Authenticates the tunnel could be done automatically with some IPsec 
implementations. Some implementations support transferring v6 over 
v4-IPsec. Users probably can't deploy that.

Erik: I was thinking about notion of sending credentials.

Erik: on scenario analysis slide, unmanaged 2 says it doesn't require 
direct connect.

Pekka: nice to have, within ISP site. It would be difficult because you 
have to cross NATs, so you would have to do unmanaged 1a if it's a strict 
requirement.

Tony Hain: Matrix is good; this should be sent to the list.

Solution summary

Pekka commented that the summary obtained by combining the matrices.

Dave Thaler: I agree with conclusion, but 2nd bullet says require STEP or 
TSP. Teredo fits as another alternative, but requires private server relay 
inside ISP.

Pekka: in this case (unman 2), Teredo doesn't fulfill simplicity requirement.

Fred Templin: What version of ISATAP were you considering?
Pekka: version 20.
Fred: NAT traversal covered in 20.
Pekka: it's covered but doesn't work.
Fred: let's make it work.
Pekka: The only way to make it work within a site would make it Teredo.
They are pretty close in NAT traversal at first, ...
Fred: From what you've said, you're looking at a subset at what's in 
current draft.

Dave Thaler: Graph is correct, and I'm happy with it.

Questions to WG:

Does the proposal about Informational / Experimental make sense?

"Does the proposal to publish them as experimental or informational now, 
describing current implementations, continue work on working group solution 
at the same time, does this make sense?"

Tony Hain: I don't believe we need to go to experimental to go to standards 
track document. We can replace the documents later.

Spencer Dawkins: I was confused earlier in the session, individual drafts 
match current deployment or contain proposals for additions/enhancements.

Jonne: I would personally like to have it documented what is out there now, 
which might be other drafts besides what's there now.

Show of hands - is that acceptable to go to experimental to document what is 
out there today? For - about 20-30. Against - 3. Rough consensus to go 
ahead with this proposal.

2nd question: is the analysis going in the right direction? Is it worth 
pursuing this, write it in draft format and get comments? Yes - 15-20. 
Against - None.

3rd question: Unmanaged 1a requires Teredo. Is there WG consensus for 
adopting that?

Jordi: I think it's interesting to see all the questions before deciding.

Jonne: These are the questions that we have. If you don't like them, we 
have others.

Dave Thaler: It's incomplete because the enterprise scenarios are missing. 
It's going in the right direction though.
Jonne: And you just volunteered to help with enterprise scenarios.
Thank you.

Question "Is there WG consensus for adapting Teredo?"

Erik: We have the lunch menu here, but it doesn't have prices. I don't know 
what we have to pay to do this. If we do this with 6to4 that's already out 
there, what's the price tag?

Pekka: That's a valid concern that's been reflected in analysis document. 
We will try to put significant health warnings in that and recommend local 
relay deployment to mitigate.

Jonne: Adopt Teredo means that the WG will work on it further, not just 
stamp it.

Tony Hain: Doing it in this room is probably not the right place. There's 
enough complication that it should probably be done on the list. Some 
people don't think it will be possible to get down to one solution.

Pekka: If the working group is unanimous about doing everything, then it's 
a signal to us. Or it can get down to one.

Tony: When you take it down to one, what are you giving up?

David Kessens: Making the final decision on the mailing list is where it 
should happen, but we can still see what the feeling of the group is now.

Jonne: Yes, it's just informative here.

David K: And you might want to start by asking these final questions now, 
but we can discuss it later on.

Jonne: Do we think there is enough basis on the preliminary work to adopt 
Teredo now? Yes - about 9. No - about 11.

Pekka: Seems roughly equal.

David K: Who don't want to adopt it - because they first want to have 
discussion on mailing list? or other reasons?

Jonne: Because it's too early? - 1 Or because there are other reasons? - 0

Erik: Hard to extract that info from room without having people state 
opinions. My opinion is that I don't have the prices on the menu. 
Practically, it might be the right thing to do here, but do we know that we 
can minimize risk of partitioning IPv6 network?

Tony: I believe we do need to know the price, but we could start down the 
path and back out with Historical.

Jonne: Let's take it to the list.

Pekka: working group consensus on teredo? yes - 9 (no not taken).

David K: I don't think we should ask this now, let's go on.

Shawn Ch( ? from Mitre: we are looking at transition mechanisms for US 
government. Literature is not very extensive with regard to cost and 
complexity as Erik said. I would request more time to go through costs of 
solutions as suggested.

Pekka: After going through this, I think we have to pay the price anyway,
but just later? I have a gut feeling that we will just be delaying the
paying up.

Jonne: I think it's fair to ask of the working group whether we need one 
solution or more

Pekka: It could be a hybrid

Jordi: I want to insist that when you are moving between networks, one 
solution may not be enough.

David K: ADs certainly have preference for a minimum amount of solutions. 
There's always a big cost to implement multiple solutions, so if we can 
minimize that, it's better.

Jordi: We are putting on the table 4 solutions, but maybe it's 6 or 7. 
There may not be a real life solution for all situations. That's what I 
experience when traveling.

Jonne: One solution would be one, not all four.

Jordi: If you give me one solutions that survives any network, that's 
perfect. But that would be difficult to happen.

Fred: If the question is must we have one solution, then I am cautious. but 
can we find one solution, I would say yes.

Someone yelled out from the floor: "Do it on the list!"

Jonne: Now you have seen the questions, and you can talk about it at home.

Question: Do we have someone signed up to do the cost analysis? At least 
two people have said what's it going to cost us.

Jonne:If there is someone who asked that would be interested in preparing 
this,..Erik, don't go away...

Erik: We should do it in parallel; you can't come up with a quick answer. 
Keep the cost question in the back of our minds, and have sensible 
deployment advice for relays.

Jonne: I agree and we can discuss the details on the list.

===
Quarantine Security Model - 10 mins, S. Kondo
   - draft-kondo-quarantine-overview-00.txt
   - quick overview of a possible security model for IPv6
   - GOAL: introduce the issue, to be fully discussed in security area

SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/quarantine-model.pdf>

Satoshi Kondo presented a Quarantine Security Model.

In the real world when we deploy IPv6, we are facing conflict with existing 
firewalls or border defense models. Usually the admin doesn't care about 
security on v6, or just copies rules from IPv4 forwarding to IPv6. But we 
are dropping some of the benefits of IPv6 technologies.

Three-step quarantine model described on 3rd slide. Requests network entity 
to check security level.

Draft describes high level overview, but does not specify protocols or 
technologies. I have to do an experimental implementation to check whether 
the model really works in the real world.

Let's discuss on mailing list or you can send email to give your comments.

Jordi Palet: It seems the idea is quite close to what I presented on 
Monday. We have been working together during IETF and we believe there is a 
lot of commonalities of what we're doing. It's an operational problem of 
IPv6 deployment, so the analysis work should be done in this WG. We would 
like to create a small design team to work on this. It's interesting to 
work on and necessary for deployment.

Pekka: since this is moving toward the protocol side instead of analysis 
side, we need to see how the proposals go forward, but I encourage you to 
continue working on this.

===
Meeting adjourned.

-end