2.4.14 IPv6 Operations (v6ops)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.6bone.net/v6ops/index.htm -- Additional V6OPS Web Page
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-12

Pekka Savola <pekkas@netcore.fi>
Jonne Soininen <jonne.Soininen@nokia.com>
Operations and Management Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>
Operations and Management Area Advisor:
David Kessens <david.kessens@nokia.com>
Mailing Lists:
General Discussion: v6ops@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe v6ops
Archive: http://ops.ietf.org/lists/v6ops/
Description of Working Group:
The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring global addressing and connectivity for all IPv4 and IPv6 nodes.

The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides guidance for network operators on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations.

The v6ops working group will:

1. Solicit input from network operators and users to identify operational or security issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. This includes identifying standards work that is needed in other IETF WGs or areas and working with those groups/areas to begin appropriate work. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts.

For example, important pieces of the Internet infrastructure such as DNS, SMTP and SIP have specific operational issues when they operate in a shared IPv4/IPv6 network. The v6ops WG will cooperate with the relevant areas and WGs to document those issues, and find protocol or operational solutions to those problems.

2. Provide feedback to the IPv6 WG regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 WG to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs.

3. Publish Informational RFCs that help application developers (within and outside the IETF) understand how to develop IP version-independent applications. Work with the Applications area, and other areas, to ensure that these documents answer the real-world concerns of application developers. This includes helping to identify IPv4 dependencies in existing IETF application protocols and working with other areas and/or groups within the IETF to resolve them.

4. Publish Informational or BCP RFCs that identify potential security risks in the operation of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or working groups.

5. Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks), Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks.

These documents should serve as useful guides to network operators and users on how to deploy IPv6 within their existing IPv4 networks, as well as in new network installations.

6. Identify open operational or security issues with the deployment scenarios documented in (5) and fully document those open issues in Internet-Drafts or Informational RFCs. Work to find workarounds or solutions to basic, IP-level operational or security issues that can be solved using widely-applicable transition mechanisms, such as dual-stack, tunneling or translation.

If the satisfactory resolution of an operational or security issue requires the standardization of a new, widely-applicable transition mechanism that does not properly fit into any other IETF WG or area, the v6ops WG will standardize a transition mechanism to meet that need.

7. Assume responsibility for advancing the basic IPv6 transition mechanism RFCs along the standards track, if their applicability to common deployment scenarios is demonstrated in (5) above:

Transition Mechanisms (RFC 2893)

SIIT (RFC 2765)

NAT-PT (RFC 2766)

6to4 (RFC 3056 & 3068)

This includes updating these mechanisms, as needed, to resolve problems. In some cases, these mechanisms may be deprecated (i.e. moved to Historic), if they are not found to be applicable to the deployment solutions described in (5) or if serious flaws are encountered that lead us to recommend against their use.

IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops group will provide input to those areas/groups, as needed, and cooperate with those areas/groups in developing and reviewing solutions to IPv6 operational and deployment problems.

Goals and Milestones:
Done  Publish Cellular Deployment Scenarios as a WG I-D
Done  Publish Unmanaged Network Deployment Scenarios as a WG I-D
Done  Publish Survey of IPv4 Addresses in IETF Standards as WG I-D
Done  Publish Cellular Deployment Solutions as a WG I-D
Done  Publish Unmanaged Network Deployment Solutions as a WG I-D
Done  Submit Cellular Deployment Scenarios to IESG for Info
Done  Submit Unmanaged Network Deployment Scenarios to IESG for Info
Done  Submit Enterprise Deployment Scenarios to IESG for Info
Done  Publish Enterprise Deployment Scenarios as a WG I-D
Done  Submit Survey of IPv4 Addresses in IETF Standards to IESG for Info
Done  Publish ISP Deployment & Solutions as a WG I-D
Feb 04  Submit Cellular Deployment Solutions to IESG for BCP
Feb 04  Submit Transition Mechanisms to IESG for DS
Mar 04  Publish Enterprise Deployment Solutions as a WG I-D
Mar 04  Submit IPv6 Neighbor Discovery On-Link Assumption to IESG for BCP
Apr 04  Submit Unmanaged Network Deployment Solutions to IESG for BCP
Apr 04  Submit Dual Stack IPv6 on by Default to IESG for Informational
Apr 04  Submit ISP Deployment Scenarios & Solutions to IESG for BCP
Apr 04  Submit Application Aspects of IPv6 Transition to IESG for Informational
May 04  Submit 6to4 Security Analysis to IESG for Informational
Aug 04  Submit Enterprise Deployment Solutions to IESG for BCP
  • - draft-ietf-v6ops-3gpp-analysis-08.txt
  • - draft-ietf-v6ops-unman-scenarios-03.txt
  • - draft-ietf-v6ops-ipv4survey-apps-04.txt
  • - draft-ietf-v6ops-ipv4survey-ops-05.txt
  • - draft-ietf-v6ops-ipv4survey-int-03.txt
  • - draft-ietf-v6ops-ipv4survey-intro-06.txt
  • - draft-ietf-v6ops-ipv4survey-routing-03.txt
  • - draft-ietf-v6ops-ipv4survey-sec-04.txt
  • - draft-ietf-v6ops-ipv4survey-subip-04.txt
  • - draft-ietf-v6ops-ipv4survey-trans-05.txt
  • - draft-ietf-v6ops-mech-v2-02.txt
  • - draft-ietf-v6ops-unmaneval-01.txt
  • - draft-ietf-v6ops-6to4-security-01.txt
  • - draft-ietf-v6ops-ent-scenarios-01.txt
  • - draft-ietf-v6ops-v6onbydefault-01.txt
  • - draft-ietf-v6ops-onlinkassumption-00.txt
  • - draft-ietf-v6ops-isp-scenarios-analysis-01.txt
  • - draft-ietf-v6ops-application-transition-01.txt
  • - draft-ietf-v6ops-renumbering-procedure-00.txt
  • Request For Comments:
    RFC3574 I Transition Scenarios for 3GPP Networks

    Current Meeting Report

    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
    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:
    v6ops web site: <http://www.6bone.net/v6ops/>
    v6ops Project Status: <http://www.6bone.net/v6ops/v6ops_project-status.html>
    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
    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
    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:
    - 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
    - IPv6 DNS Issues and Considerations
    - Unique Local IPv6 Unicast Addresses
    - 3GPP2 or other IPv6 Mobility scenarios
        [several drafts]
    - Guide to mapping IPv4 subnets into IPv6
    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?
          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
    - 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 
    - The third is a simple option, and works very well
        However, if IPv6 is added on all the edge routers, setting these up is
    - 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
    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.
    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 
        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
          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 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
            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
    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
    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 
          Inside the 3GPP: depends on how much traffic between UEs; the IPv6 
          Inside the enterprise: in larger sites, possibly desirable (e.g., p2p
    "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
    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
    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
    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
    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
    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
    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
    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
    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 
    => Consensus: both are needed and will be standardized.
    Clarification: no consensus standardizing all of them, mechanisms will be 
    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.
    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.
    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
    Attack/threat: active or passive; security is protection and IPSEC is used;
    need policy management tool, policy decision point.
    Typical architectural scheme is shown.
    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:
    Tunneling Scenarios Analysis - 20 mins, Chairs
       - introduce issue, first discussion continue later
    Pekka presented Scenarios tunneling analysis.
    - 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: 
    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
    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 
    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
         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 
         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 - 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 
    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 
    Pekka: I got a feeling that a significant portion of the traffic is on 6to4 
    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
    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 
    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.


    Agenda 2nd session
    IPv6 in MPLS Networks
    "opportunistic" and zero-configured tunneling
    IPv6 Distributed Security Requirements
    Thoughts on IPv6 Transitionfor mobile nodes
    Quarantine Model Overview
    Basic Transition Mechanisms update
    Scenarios tunneling analysis - intro
    6to4 Relay Traffic Statistics and Observations
    Scenarios analysis
    Procedures for Renumbering an IPv6 Network without a Flag Day