2.4.20 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 60th IETF Meeting in San Diego, California USA. It may now be out-of-date.

Last Modified: 2004-07-23

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  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
Done  Submit Cellular Deployment Solutions to IESG for BCP
Done  Submit Transition Mechanisms to IESG for PS
Done  Submit IPv6 Neighbor Discovery On-Link Assumption to IESG for BCP
Done  Submit Dual Stack IPv6 on by Default to IESG for Informational
Done  Submit Unmanaged Network Deployment Solutions to IESG for BCP
Done  Submit ISP Deployment Scenarios & Solutions to IESG for BCP
Done  Submit Application Aspects of IPv6 Transition to IESG for Informational
Done  Submit 6to4 Security Analysis to IESG for Informational
Done  Submit Enterprise Deployment Scenarios to IESG for Info
Done  Submit Renumbering Procedures to IESG for BCP
Aug 04  Submit Assisted Tunneling Requirements to IESG for Info
Sep 04  Publish Enterprise Deployment Solutions as a WG I-D
Dec 04  Submit IPv6-in-IPv4 Tunneling using IPsec to IESG for Info
Feb 05  Submit IPv6 Security Overview to IESG for Info
Feb 05  Submit Enterprise Deployment Solutions to IESG for BCP
  • - draft-ietf-v6ops-3gpp-analysis-10.txt
  • - draft-ietf-v6ops-mech-v2-04.txt
  • - draft-ietf-v6ops-unmaneval-03.txt
  • - draft-ietf-v6ops-6to4-security-04.txt
  • - draft-ietf-v6ops-ent-scenarios-05.txt
  • - draft-ietf-v6ops-v6onbydefault-03.txt
  • - draft-ietf-v6ops-onlinkassumption-02.txt
  • - draft-ietf-v6ops-isp-scenarios-analysis-03.txt
  • - draft-ietf-v6ops-application-transition-03.txt
  • - draft-ietf-v6ops-renumbering-procedure-01.txt
  • - draft-ietf-v6ops-assisted-tunneling-requirements-00.txt
  • Request For Comments:
    RFC3574 I Transition Scenarios for 3GPP Networks
    RFC3750 I Unmanaged Networks IPv6 Transition Scenarios
    RFC3793 I Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards
    RFC3796 I Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards
    RFC3795 I Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards
    RFC3794 I Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards
    RFC3792 I Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards
    RFC3791 I Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards
    RFC3790 I Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards
    RFC3789 I Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards

    Current Meeting Report

    IPv6 Operations WG (v6ops) minutes of IETF60
    Monday, August 2 at 1930-2200
    Thursday, August 5 at 0900-1130
    CHAIRS: Pekka Savola <pekkas@netcore.fi>
            Jonne Soininen <jonne.soininen@nokia.com>
    The minutes were edited by Pekka Savola notes taken by
    Juha Wiljakka (both sessions) and Florent Parent (both sessions).
    Tim Chown provided Jabber transcript.
    There were over ??? folk in attendance.
    Monday 2nd Aug, 1930-2200
      Introduction and agenda bashing - 5 mins, Chairs/Soininen
      Document status - 15 mins, Chairs/Savola
      VLAN Usage for IPv6 Transition - 5 mins, Chown
      Enterprise solution case study - 20 mins, Chown
      Assisted Tunneling Requirements - 15 mins, Durand
      Moving forward with Mechanisms - 45 mins, Chairs/ADs
      Secure IPv6 Tunneling - 10 mins, Graveman
      IPv6 Security Overview - 10 mins, Savola
      Tunnel-endpoint discovery - 10 mins, Palet
      What to do with NAT-PT applicability statement - 5 mins, Chairs/Savola
    Thursday 5th Aug 0900-1130
      Agenda bashing - 5 mins, Chairs
      IETF IPR policy recap/discussion - 5 mins, Chairs
         Summary: IETF takes no stance; read RFC3668
      Enterprise analysis, first look - 10 mins, Bound
      Zero-conf requirements report - 20 mins, Nielsen
      Assisted tunneling analysis - 20 mins, Durand
      Transition mechanisms update - 5 mins, Chairs/Savola
      "Auto-transition" - 10 mins, Palet
      IPv6 Mobility Scenarios - 10 mins, Williams
      Distributed v6 security reqs etc. - 10 mins, Palet
      Advanced L3 IPv6 Exchange Model - 10 mins, Palet
    Monday, August 2 at 1930-2200
    *  Introduction and agenda bashing - 5 mins, Chairs/Soininen
    *  Document status - 15 mins, Chairs/Savola
      SLIDES: <00_v6ops-agenda.pdf>
      Pekka presented current document status.
    Bernard Tuy: What is the status of the ISP scenarios?
    Pekka: Past the IESG evaluation, waiting to go to RFC editor.
    * VLAN Usage for IPv6 transition - 5 mins, Chown
      SLIDES: <01_vlan-usage-01.pdf>
      Tim Chown presented, and asked whether it is worth documenting, complete
      enough, or ready for WG adoption.
    Jonne Soininen: We'll discuss way forward in v6ops later, postponing the
    issue of WG adoption.
    Bernard Tuy: Agree that this is worth documenting.
    Bernand Tuy: Just say a router instead of PC-based router.
    Fred Templin: How is VLAN tagging done?
    Tim: Using VLAN framing in the Ethernet frames.
    Fred Templin: Is it like ISATAP and doesn't go through NATs?
    Tim: no, it's independent of NATs.
    Christian Huitema: <made a comment>
    * Enterprise solution case study: Campus Transition - 20 mins, Chown
      SLIDES: <02_campus-transition.pdf>
      Tim Chown presented, and asked whether this was useful, and whether there
      was potential for WG item.
    Alain Durand: Thanks for writing the document. NFSv6 is shipping since couple of years.
      Network discussion in document ok. But application version specifics are not
      as useful.
    Christian Huitema: Stick to exact/specific descriptions.
    Jim Bound: Good job. Should be work on in this WG.  Would like to see 
      examples of VLAN in appendix.
    Alain Durand: This is exactly the kind of doc that the WG needs to do;
      we should focus on documenting real deployments.
    Eric ?: In scenario 3, describe difference between IPv6 only deployment
      and v4/v6 as documented?
    * Assisted Tunneling Requirements - 15 mins, Durand
      SLIDES: <03_assisted-tunneling.pdf>
      Alain Durand presented.
    (In the context of prefix length for tunnel link)
    Christian Huitema: Tunnel link is a link. assign /64.
    Bernard Tuy: Use first /64 from the /48 to assign tunnel 
    Alain Durand: Will change to /64.
    (In the context of securing the tunnel link)
    Christian Huitema: Should be a way to provide authenticated and encrypted
      service, in an interoperable fashion.
    Pekka Savola: We need to stick to the basics.  This is no less secure than
      configured tunneling.  IPv6-in-IPv4 w/ IPsec is described in another
    Eric ?: IPv6 gives many advantages. Need secure mechanism specifically
      outlined. Agrees with Christian.
    Pekka Savola: Useful to document. Operationally, many tunnels are not using
      IPsec. Be realistic.
    Christian Huitema: Secure VPN.
    Jonne Soininen: Sometimes you use double layer encryption as well.
    (In the context of the Requirements word)
    Thomas Narten: Wording somewhat offensive (IESG of the day).
      Requirement documents should not have uppercase imperatives.
      Should be more of a goal.
    Brian Carpenter: Requirement document has to be a self consistent document;
      either you must be able to fill all the requirements (in one solution),
      or the text needs to be more flexible.  Removing the uppercase removes
      that contraint.
    (In the context of DNS considerations)
    Christian Huitema: DNS considerations should be removed if we use /64.
    (General commentary)
    Karen Nielsen: the document refers to 3GPP analysis, but does 3GPP refer to
    this?  If not, this is incorrect.
    Thomas Narten: Does 3gpp identify assisted tunneling as required?
    Pekka Savola: assisted tunneling can be applied to address 3GPP.
    Christian Huitema: Looks good on whiteboard. Which customer demand drives
      the each requirements?
    Pekka Savola: we have too few operators in the IETF..
    Christian Huitema: Requirements appear to be based on developing a
      protocol. Need direct link with ISP/... demand.
    Alain Durand: requirements not specific enough?
    Christian: ground goal on specific scenarios/requirements.
    Xiaobao Chen: What is the justification for requiring assisted tunneling
      for 3GPP?
    Jonne Soininen: This doesn't give any requirements for 3GPP networks.
    Karen Nielsen: (re-stating) I have the problem that this claims to solve
      issues in 3GPP networks, I understand that it is coming from scenarios,
      much from ISP, but does it really apply to 3GPP?
    Thomas Narten: if refering to 3GPP requirements but doesn't apply,
      remove reference.
    * Moving forward with Mechanisms - 45 mins, Chairs/ADs
      SLIDES: <04_v6ops-way-forwardv2.pdf>
      Jonne Soininen presented, proposing aggressive deadlines, e.g.:
    Enterprise analysis
      - first version in 2 weeks
      - in WG last call by sept 7th
    Finish assisted tunneling req doc
      - deadline aug 20
    List the zeroconf requirements
      - dealline: proposal Thursday
      - requirement by sept 1st
    Lets keep the new WG items on hold until these are done.
    Erik Nordmark: IPv4 over IPv6: do we need nore details, how they configured,
      traffic optimization, etc.
    Pekka Savola:
      No requirements for path optimization. Need discovery. Cross domain (ISP).
      Manually configured tunneling with automatic discovery is sufficient.
    Alain Durand: IPv4 in IPv6 in assisted tunneling. Also NAT traversal.
      There was a "or else.." in the slides -- if we don't get this done,
      then what?  Closing the WG?
    Jonne Soininen: Not closing.  If not done in a suitable timeframe, we don't
      have it; we won't provide a solution to those scenarios.
    David Kessens: some progress is going on. E.g., Teredo moving to PS.
    Margaret Wasserman: Credit to current chairs for moving things forward.
      Holes have been identified. A lot of effort have been made. Hopes
      that people will see hope on this. You have done good job, guys!
    Jim Bound: 2 weeks is not realistic, 4 weeks closer to it.
    Jonne Soininen: We need just the first version, i.e., showing that somebody
      is willing to make the 1st version in 2 weeks, we need to see commitment.
      Can be extended, but we need to see commitment.
    Jim Bound: make it 3 weeks for enterprise analysis.  I Will deliver it.
      If folks want to give input, send TEXT!
    Jordi Palet: What do you mean with zero-conf tunneling?
    Jonne Soininen: identified in 3GPP. Doesn't mean something specific.
      Requirements only.
    Tim Chown: Have deadlines working both ways: for IESG as well.
    David Kessens: First slot for IESG is 2 weeks after IETF.
    Tim Chown: that is same time as deadline: impossible.
    Thomas Narten: No room for iterations in the current deadlines. Good progess
      would be to have review every month.
    Jonne Soininen: First enterprise analysis in 3 weeks, then iterate every
      month. What is a realistic last call date?
    Pekka Savola: by the end of September?
    David Kessens: for next IETF too late. Next IETF should be about
      discussion of the future of this WG.
    Jim Bound: Will this wg die? I don't want this work to be killed like
      Ngtrans. It is time that the drafts are put in public.
    David Kessens: We are making progress, milestones almost done. There are
      no rumors, rechartering is normal practice in the IETF.  There has
      been discussion that a wg standardizing tunneling mechs is needed.
    Jim Bound: doesn't know what assisted tunneling does. 
    Pekka Savola: TSP falls in this category
    Karen Nielsen: Would like to know which scenario map into assisted
      tunneling/zero conf/etc..
    Christian Huitema:  Is ISATAP missing?
    Jonne Soininen: It is not missing, but it is missing... Jonne's personal
      opinion is that ISATAP fits in zeroconf.  Chair hat on: We have to see
      requirements before we can say. Fred has sent ISATAP to be published as an
      Experimental RFC, but thinking that ISATAP fits in zeroconf..
    Fred Templin: moved in experimental. But would like to have it on standard track.
    Christian Huitema: may revise the ISATAP document later. Need to document what
      is on the market in RFC document.
    Christian Huitema: I have a lot of sympathy for Jim: we'repending lots of time
      in analysing/requirements.
    Jim Bound: Fred should not have to go to experimental for ISATAP 
    Jonne Soininen: he doesn't have to, we're not forcing him.  But he has the
      right to do so.
    Brian Carpenter: ID-tracker says on ISATAP work: waiting for v6ops scenarios
    Thomas Narten: Old text, gone to RFC Editor.  The ID-tracker needs to be
    Jonne Soininen: We have a plan, we can move forward quickly.  Interested
      people coming to Jonne so that we have something done by Thursday.
    * Secure IPv6 Tunneling - 10 mins, Graveman
      SLIDES: <05_v6ops-secure-tunnels.pdf>
      Richard Graveman presented.
    Brian Carpenter: running code in router-router mode using older IPsec
      specs. The fact that this has been through security review, good to
      document here.
    Jim Bound: good document. Worried with the end-to-end problem with transport
      mode for router-router scenario.
    Jonne Soininen: not considering it now for WG item, due to the agreed
    * IPv6 Security Overview - 10 mins, Savola
      SLIDES: <06_v6ops-sec.pdf>
      Pekka Savola presented, stating that this is referred to by a couple of
      documents and we need something like this.  He wanted new
      editors/co-authors for the work, inviting to come and talk to him
    * Tunnel-endpoint Discovery, 10 mins, Palet
      SLIDES: <07_v6ops-tun-auto-disc.pdf>
      Jordi Palet presented.
    Xiaobao Chen: Applicability in 3GPP?
    Jordi Palet: There's another doc "auto transition"..
    Jonne Soininen: Let's discuss that off-line.
    Tim Chown: How evaluate all these solutions to decide how to pick?
    Jordi Palet: preparing document on this.
    * What do we want to do with NAT-PT? (Pekka)
      SLIDES: <08_v6ops-natpt.pdf>
      Pekka Savola presented.
    Bernard Tuy: NAT-PT is just another kind of NAT, should drop NAT-PT.
    Christian Huitema: if we do nothing, NAT-PT will endup being in RFP and
      implementors will be required to implement.
    Remi Depre(?): Depre: NAT-PT essential piece when no IPv4 address available
    (Lot's of people in the room): NO!!!
    Remi Depre(?): ok, I have things to learn :).
    Tony Hain: v6-only app <-> v4-only app needs a translation yes. This can be
      at different level.  NAT-PT not necessarly the solution. We need a crisp doc
      that says that IPv6 deployment does not require NAT-PT.
    Alain Durand: Change status of NAT-PT (PS) to something else.
    Pekka Savola: maybe -- but we'd still to document it.
    Xiaobao Chen: NAT-PT would save payload size compared to tunneling.
    Tony Hain: Amount of battery costs you more than the overhead..
    Brian Carpenter: Need to find volunteer to document why we reclassify NAT-PT.
    Bernard Tuy: What About SIIT?
    Pekka Savola: already covered in the document.
    Pekka Savola: there seems to be significant interest to work on this.  Come
      see the chairs after the meeting.
    Thursday, August 5 at 0900-1130
    * Introduction / Agenda Bashing
      SLIDES: <10_v6ops-agenda2.pdf>
    * IETF IPR policy recap (Chairs/Pekka)
      The subject had come up on the list, so Pekka Savola just reminded of the
      policy; up to WG participants to make decision on what to do.
    * Enterprise analysis (Jim Bound)
      SLIDES: <11_ent_scen.pdf>
    Pekka Savola: personal observations: always when I see huge matrix, I get
    concerned...but it is good that you can pick the most relevant, real
    scenarios. This looks promising.
    Alain Durand: Are you going to focus on L3 or Applications in enterprise?
    Jim Bound: 00 draft more focused on L3, some apps.
    Alain Durand: L3 easy to fix. app issues more difficult
    Jim Bound: don't agree, L3 more important.
    Alain Durand: final document should have L7 considerations (apps)
    Jim Bound: sure. Don't feel that should handle all possible DNS config, for example.
      Done elsewhere.
    Jonne Soininen: let's take this off-list.
    Fred Templin: I offered text on the mailing list. why not there?
    Jim Bound: not seen text. will look
    Pekka Savola: What is "some form of translation", does it include proxying? 
    Jim Bound: Yes.
    Tim Chown: Campus draft looking at apps/L7. can be used in scenario.
    * Goals of Zero-conf tunneling (Karen Neilsen)
      SLIDES: <12_zeroconfig-reqs.pdf>
      Karen Nielsen presented.
    Alain Durand: How many IPv6 addresses are you considering, what if there are
      devices behind the terminal?
    Karen Nielsen: at least one address..
    Alain Durand: Sounds nice, but a little bit restrictive.
    Fred Templin: OK with the goals. But non-goals not appropriate for this
      document. Limits future growth.
    Pekka Savola: how will nodes behind the tunnel get IPv6?
    Karen Nielsen: one tunnel is setup, can do some mechanism
    Pekka Savola: not sure of answer. Laptop behind the UE?
    Jonne Soininen: use the same way as with IPv4, i.e. not using
      a shared PDP context, but using 2 PDP contexts: one for the UE and one
      for the laptop (PPP PDP context).
    Tim Chown: Compare the differences of assisted tunneling vs zero-conf.
    Karen Nielsen: non-goal is to differentiate with assisted tunneling
    Fred Templin: (Disagrees)
    David Kessens: happy with current draft. not trying to solve everything
    Alain Durand: a lot of common stuff with assisted tunneling.
      Does it make sense to explore 2 parallel?  From vendor perspective, just
      one would be good.
    David Kessens: too early to answer this question.
    Jordi Palet: trying to keep as simple as possible; /64 must not add extra
      complexity compared to /128. No configuration.
    Jim Bound: Response to Alain. Assisted tunneling is nothing more than an
      informational document. Asking for more wasted time.
    Jordi Palet: We only have an RFC on a generic idea, but not a
      complete protocol description, so no interoperability among
    Alain Durand: Assisted tunneling will answer some of your questions
    * Assisted tunneling
      SLIDES: <13_asst-tun-analysis.pdf>
      Alain Durand presented, reminding that tunnel broker implementations are not
      interoperable since no formal *protocol* definition.
    (On the context of ISATAP)
    Fred Templin: could also use out of band for prefix delegation.
    Alain Durand: breaks the security model, all routers would have to be in
    Fred Templin: let's go off-line on this.
    (On the context of L2TP + IPsec)
    Dave Thaler: IPsec could be added to all the scenarios, and it would make
      it more challenging to deploy.
    David Kessens: Every slides show "pass most requirements". not useful.
    Alain Durand: sorry for being unclear. That means they pass all the
      requirements *except* endpoint discovery, but no mechanism passes this.
    Bob Hinden: TCP tunneling has serious issues w/ packet loss.
    Jim Bound: Good to define a setup protocol. How do you discover where the
      tunnel. Would be valuable part of this work.
    Jonne Soininen: after the exact reqs, need a doc mapping the solutions.
    * Moving forward (as needed)
      (No presentation.)
    David Kessens: work was done quickly. Keep pace.
    Jonne Soininen: thanked for these productive 2 days, hopefully people
      will also work hard after IETF60.
    * Final trans-mech-bis issue
      SLIDES: <14_transmech.pdf>
      Pekka Savola presented.  There were no comments from participants.
    * "Auto-transition": picking the right mechanism - 10 mins, Palet
      SLIDES: <15_auto-trans.pdf>
      Jordi Palet presented, and at the end also noted that this
      is being implemented.
    Dave Thaler: 1) you may need to use longest match for tie-breaker for
      preference of mechanisms; 2) dynamic updates based on performance is a bad
      idea -- May fall into synchronization, everyone switch, congestion, fallback,
      congestion, etc.
    Jordi Palet: The performance estimates could be enabled by the user, not
    Pekka Savola: IETF rejected PBN some years ago. Are ISP still using this?
    Jordi Palet: agrees, should be host centric, but need to get input from the
    Pekka Savola: Just to be clear, no objection to getting input from the
      network, just that PBNs are not the way to do so.
    Alain Durand: Network debugging. Applicability important. 
    * IPv6 Mobility Scenarios/Requirements update, 10 mins, Williams
      SLIDES: <16_mipv6-trans.pdf>
      Carl Williams presented.
    Karen Nielsen: any new requirement for MIP movement detection. Which
      requirements are used for movement detection?
    Henrik Levkowetz: movement detection is orthogonal to this. Part of this is
      describe in MIP documents, but a lot is not. That is where DNA work
      comes in.
    Jim Bound: Don't care about mip4. Should not tie to 3gpp, as MIPv6 will be
      used by all kinds of devices. Should focus on mip6.
    Carl Williams: Agree. Need to do some analysis on current transition scenarios.
    George Tsirtsis: MIP4 is deployed today. Used. Would like to do mip6. What are
      we going to do? deploy both mip4 and mip6?
    Jim Bound: MIPv4 is only done inside the enterprises or inside the sites,
      not globally.
    Henrik Levkowetz: Comment coming from wrong direction. If you have existing
      mip4, not talking about getting new addresses, but adding IPv6 within
      mip4 network.
    George Tsirtsis: Similar to IPv4 private network. We have mechanisms to
      transition to Ipv6. Same is required for MIP4 networks.
    Jonne Soininen: let's continue off-list.
    * Distributed v6 security requirements/problem statement - 10 mins, Palet
      SLIDES: <17_distributed.pdf>
      Jordi Palet presented.
    Mr. X (?): You have a solution. You decided on host based solution. 
      This work should not be happening here.
    Pekka Savola: Agreed, this is not a place for developing a security
    Mr. X: This looks like a product, not requirements.
    Jordi Palet: read the draft. Not sure if this work should be
      continued here but I'm also sure this is an operational issue,
      so v6ops. Anyway I also asked from inputs to SAAG and other previous
      attempts for this kind of work, and nothing until now, no any single
    ?: Good paper presented at Nanog.
    Jordi: already working on implementation.
    * Status update of quarantine security model
      SLIDES: <18_quarantine.pdf>
      Satoshi Kondo presented.
      There were no comments.
    * Advanced L3 IPv6 Exchange Model - 10 mins, Morelli
      SLIDES: <19_l3-ix.pdf>
      Mario Morelli Presented.
    Bernard Tuy: Why would an IX provide IPv6 addresses to customers?
    Mario Morelli: On our model, we provide addresses.
    Bernard Tuy: in real world, this is not so.
    Kurt Lindqvist: Don't think this model will work. This makes IX as ISP.
    Simon Leinen: Find it confusing this is called an IX. 
    Mario Morelli: agree, need to find another name.
    * Any other Business?
    Tim Chown: wg on other lists are doing assited tunneling stuff. EX: nemo are
      defining their own tunneling method.
    David Kessens: Reason why need to define requirement precisely because this
      need is in WG in INT area.
    * NON official part of the meeting
     The WG meeting was closed, but because the room was empty, Alain Durand and
     Fred Templin took the chance and presented.



    Agenda for 2nd day
    VLAN Usage for IPv6 transition
    Enterprise solution case study: Campus Transition
    Assisted Tunneling Requirements
    Moving forward with Mechanisms
    Secure IPv6 Tunneling
    IPv6 Security Overview
    Tunnel-endpoint Discovery
    What do we want to do with NAT-PT?
    Enterprise analysis
    Goals of Zero-conf tunneling
    Assisted tunneling
    Final trans-mech-bis issue
    "Auto-transition": picking the right mechanism
    IPv6 Mobility Scenarios/Requirements update
    Distributed v6 security requirements/problem statement
    Status update of quarantine security model
    Advanced L3 IPv6 Exchange Model