2.4.12 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:

       Additional V6OPS Web Page

Last Modified: 2003-08-26

Robert Fink <bob@thefinks.com>
Margaret Wasserman <mrw@windriver.com>
Pekka Savola <pekkas@netcore.fi>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.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

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
  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

  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
Nov 02  Publish ISP 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
Dec 02  Submit Cellular Deployment Solutions to IESG for BCP
Feb 03  Submit Survey of IPv4 Addresses in IETF Standards to IESG for Info
Done  Submit Unmanaged Network Deployment Scenarios to IESG for Info
Apr 03  Submit ISP Deployment Solutions to IESG for BCP
Aug 03  Submit Enterprise Deployment Scenarios to IESG for Info
Aug 03  Submit Enterprise Deployment Solutions to IESG for BCP
Sep 03  Publish Enterprise Deployment Scenarios as a WG I-D
Nov 03  Submit Transition Mechanisms to IESG for DS
Dec 03  Publish ISP Deployment Solutions as a WG I-D
Mar 04  Publish Enterprise Deployment Solutions as a WG I-D
Apr 04  Submit Unmanaged Network Deployment Solutions to IESG for BCP
Apr 04  Submit ISP Deployment Scenarios to IESG for Info
May 04  Submit 6to4 Security Analysis to IESG for Informational
  • - draft-ietf-v6ops-3gpp-analysis-04.txt
  • - draft-ietf-v6ops-unman-scenarios-02.txt
  • - draft-ietf-v6ops-ipv4survey-apps-01.txt
  • - draft-ietf-v6ops-ipv4survey-ops-02.txt
  • - draft-ietf-v6ops-ipv4survey-int-01.txt
  • - draft-ietf-v6ops-ipv4survey-intro-02.txt
  • - draft-ietf-v6ops-ipv4survey-routing-01.txt
  • - draft-ietf-v6ops-ipv4survey-sec-01.txt
  • - draft-ietf-v6ops-ipv4survey-subip-02.txt
  • - draft-ietf-v6ops-ipv4survey-trans-01.txt
  • - draft-ietf-v6ops-mech-v2-00.txt
  • - draft-ietf-v6ops-unmaneval-00.txt
  • Request For Comments:
    Transition Scenarios for 3GPP Networks (RFC 3574) (23359 bytes)

    Current Meeting Report

    SUBMITTED version 1.0  15 August 2003
    IPv6 Operations WG (v6ops)
    IETF-57, Vienna
    Tuesday, July 15 at 1545-1800
    Wednesday, July 16 at 1530-1730
    Bob Fink <bob@thefinks.com>
    Pekka Savola <pekkas@netcore.fi>
    Margaret Wasserman <mrw@windriver.com>
    The minutes were edited by Bob Fink from various notes from 
    There were over 200 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: 
    v6ops web site: <http://www.6bone.net/v6ops/>
    v6ops Project Status: 
    Introduction and agenda bashing - 5 mins, Margaret Wasserman
    current status - 5 mins, Margaret/Pekka
    UNMAN Analysis discussion - 25 mins, Christian Huitema
    Forwarding Protocol 41 in NAT Boxes - 10 mins, Jordi Palet
    IPv6-IPv4 Translators in 3GPP Networks - 10 mins, Karim El-Malki
    ISP Scenarios - 40 mins, Mikael Lind
    ENT Scenarios - 40 mins, Yanick Pouffary/Jim Bound
    v6-on-by-default - 25 mins, Alain Durand
       5-10 mins presentation, remainder discussion
    threedegrees - 10 mins, Christian Huitema
    Security - discussion of what we should be doing - 45 mins, Chairs
    NAT-PT Applicability Statement team report - 15 mins, Peter Barany
    Writing IPv6 Applications report - 15 mins, Myung-ki Shin & Pekka Savola
    Status report of IPv4 Survey drafts - 10 mins, Chairs
    First Session:  Tuesday, July 15, 2003 at 1545-1800
    Introduction and agenda bashing - Margaret Wasserman
    current status - Margaret/Pekka
    Margaret reviewed the status of the v6ops projects and various 
    activities (see the v6ops web sites and slides above).
    UNMAN Analysis discussion - Christian Huitema
    Christian presented on the Unmanaged Network Analysis draft (see slides and 
    draft above) ending with a summary of his recommendations:
      Develop and standardize Teredo or similar technology
      Agree on standardized IPv6 prefix delegation mechanism
      For "informal prefix sharing", develop a standard way to perform "RA 
    proxy", possibly as part of a "multi-link subnet" specification
      Standardize a way to provision a DNS resolver address in IPv6 only hosts
      Proceed with the standardization of LLMNR
      Continue standardization of 6to4
      Standardize an IPv4 over IPv6 tunneling mechanism, as well as the 
    associated configuration services
    Christian believes the next steps are to:
      WG last call for evaluation document
      Act on recommendations
    Rob Austein said that, as a design team member, he didn't remember 
    recommending teredo.
    Alain Durand felt that the scope of the document is not to recommend 
    specific technology, e.g., teredo, rather to point out there are holes in 
    IETF specifications that need filling.
    Erik Nordmark asked why prefix delegation isn't sufficient?  Why is RA 
    proxy also needed?
    The chairs noted that this item should be taken to the list, and v6ops may 
    not be the right place to decide.
    Margaret noted the lack of mailing list feedback on the draft.
    Erik Nordmark asked if the decision for IPv6 over NATed networks should be 
    Margaret felt that there should be an interim meeting for this issue.
    Tim Chown asked why 6to4 was proposed instead of tunnel brokers?
    Christian replied because 6to4 does not need much configuration nor a 
    Tim noted that the tunnel broker user experience seems to be more 
    Marc Blanchet felt that the tunnel broker does not get a fair chance in the 
    analysis draft. Christian replied that there has not been enough time to 
    incorporated the tunnel broker work.
    Marc asked if he committed to add the tunnel broker to the analysis 
    draft, to which Christian replied that he was only making a 
    commitment to discuss and evaluate.
    Erik Nordmark noted that there is tension between configuration and 
    no-configuration solutions. Too much automation may be bad as it is 
    difficult to debug. This has not been sufficiently discussed. 
    Christian replied that there has to be a way out of the automatic 
    mechanism if it fails.
    Marc Blanchet noted that the freenet6 tunnel broker proposal has never been 
    given a chance to be reviewed, which he felt was unfair.
    Tony Hain said that the discussion is not in the right context here. This is 
    not a problem for unmanaged networks but for enterprise networks.
    Bill Sommerfeld asked why is it that the security implications are just for 
    v6 and not for v4. Christian noted that v4 is often behind NATs and thus a 
    little bit more protected.
    Bill replied that this was not true. However, he will send the text to 
    Christian to explain what is needed to change in the text.
    Rob Austein stated that help is needed for the analysis document. It is 
    still fairly new, and does still need work.
    Margaret noted that while the scenarios draft has been sent to the IESG, the 
    analysis draft still needs work. She then asked how many people have read 
    the doc, noting that she didn't see many hands, and that people should read 
    and comment on the draft.
    Forwarding Protocol 41 in NAT Boxes - Jordi Palet
    Jordi Palet presented his draft on forwarding protocol 41 in NAT boxes (see 
    draft and slides above). The basic premise is that this behavior is not 
    documented, though it is widely used. Jordi noted that there is no need for a 
    new transition mechanism.
    Christian Huitema commented that he had looked at this approach a few 
    years ago. However, it does not scale beyond one computer behind the NAT. 
    Jordi replied that it isn't intended to be a general solution, and may not be 
    the right for a totally unmanaged network. There may have to be a PC based 
    router behind the NAT.
    Christian noted that though it does work in very restricted cases, it 
    isn't really applicable to unmanaged networks.
    Pekka Savola commented that it is clear that it does not work for many 
    Rob Austein also thought that here are already applications like this.
    Bob Hinden felt it would be better to recommend that they have v6 in the 
    Keith Moore (through Jabber) commented that he thought it better to have 
    6to4 in the NAT.
    Tim Chown noted that this solution could be added to the current NATs as a 
    simple firmware update.
    Christian said that there are many NAT vendors are implementing 6to4 in the 
    NAT. It is actually bad to recommend the protocol 41 as you will confuse the 
    NAT vendors.
    Jordi felt that this could be a possible "second choice" for NAT 
    Itojun stated that this should not be recommended, but this current 
    practice should be documented.
    Alain Durand asked if this solution is compatible with 6to4 in the NAT box? 
    Christian replied no.
    The chairs felt that there should be more discussion on the list as to what 
    should be done about this document.
    IPv6-IPv4 Translators in 3GPP Networks - Karim El-Malki
    Karim El-Malki presented his IPv6-IPv4 Translators in 3GPP Networks draft 
    (see draft and slides above).
    Someone commented that STUN doesn't work the way Karim proposed.
    Gonzalo Camarillo commented that the Sipping WG has worked more on v4 and 
    NAT. v6ops has the knowledge on v6ops. There is no place  to start the 
    Margaret stated that it may be better to have this in the sipping wg as it 
    raises the v6 awareness there, and to give support there for IPv6.
    Peter noted that the NAT-PT part could be useful.
    Margaret asked what is the relation of this and the 3GPP analysis 
    document? Jonne Soininen replied that the analysis document hints that 
    something is needed, but the actual solution has not been done there.
    What action, if any, is needed next?
    ISP Scenarios - Mikael Lind
    Mikael Lind presented the ISP Scenarios team's draft (see draft and 
    slides above), noting that the team had started over with new draft, an 
    that it was a further simplification of the arlier team effort.
    It defines a generic ISP network and stages of maturity, with 
    transitions between stages, but was limited in detail, omitting v6-only 
    Dave Meyer asked how sensitive is the analysis? He noted that there is some 
    movement to collapse edge-to-core networks. Mikael noted that the team was 
    talking about DSL modems, etc, not real access routers. That the focus was on 
    ISPs, not all coexistence mechanisms, and asked if the team should write a 
    guide for ISPs, i.e., refocus the intent of the documents.
    Alain Durand asked if we can really design a generic network? We have 
    already deployed IPv6 in some networks - should we document what they did? 
    Mikael replied that although people have deployed, have they deployed in 
    production networks?
    - Should we talk about different kinds of networks (DSL, cable, etc.)? how to 
    transition my IGP?
    - Should we end this work? Is there enough ISP interest to justify the 
    Pekka Savola noted that it was very simple and general at this point - is 
    that OK? Is it sufficient?
    Margaret asked to hear from ISPs?
    Kurt Lindqvist commented that ISPs differ a lot. How many ISPs have 
    deployed v6 with same SLAs as v4?
    Dave Meyer noted that this is the same as MSDP - go document the 
    problems people were having in deployment instead of doing a 
    comprehensive guide of all possible scenarios.
    Shin Miyakawa noted that it is difficult to define transition path for the 
    NTT backbone, that they can think about anything, but 
    administration may limit them. Some routers can do what we want, others 
    can't. Eventually this will change. Some parts of network are SONET, some 
    are MPLS - there are lots of technologies inside our networks!
    Carl Yeager said that from his ISP point of view, we need a lot more 
    details about the applications required for the transition. Document is 
    nice but doesn't help small ISP migrate. Should this happen at NANOG or 
    similar? It's a FAQ, not an RFC... that this is more like a tutorial on 
    IPv6 than an ISP document - not sure that's what we need.
    Brian Carpenter commented that we did this to find out if we were 
    missing any transition mechanisms. Margaret further noted that we need to 
    know how operators will actually deploy v6. Pekka felt that our charter 
    does include documenting operational practice.
    Margaret asked how many ISPs think v6ops should do this work? There was 
    some support shown.
    How many are willing to help us? Some.
    How many people have read the draft? Some.
    How many people are ISPs in the room? Quite a few.
    How many can help? Some.
    The chairs asked for interested ISP folk to come to them after the 
    meeting and volunteer.
    ENT Scenarios - Yanick Pouffary/Jim Bound
    Yanick Pouffary presented an overview of the Enterprise Scenarios draft 
    (see draft and slides above). She especially noted that there had been much 
    recent reworking of the draft to accommodateds team input and that the team 
    now felt that it was time for it to be accepted as a wg draft.
    Also of special note was that 3 base scenarios are defined to capture the 
    essential abstraction set for the Enterprise. That it should be noted 
      There are definitively more scenarios
      We cannot possibly cover all of them
      We selected the most representative ones
    Yanick also said that the team will write a revision to the scenarios 
    document for the next IETF, that there is still work to do on this 
    scenarios doc but we need to hear from the wg on the mail list. She also 
    thanked Alain Durand who has given input.
    Yanick finished by noting that the team will start on a new analysis 
    document to map relevant transition mechanisms to the base scenarios.
    Brian Carpenter stated that more progress will be made if it's a working 
    group document. Need to think about security boundaries, etc.
    Christian Huitema noted his concern that we will have a very unwieldy 
    document because things are combinatorial. Margaret noted that the team is 
    trying to simplify.
    Alain Durand noted that it's a framework, and that it doesn't have to 
    cover all cases.
    Bob Hinden commented that we're doing scenarios to flesh out 
    transition mechanisms, and don't have to have all possible scenarios.
    Margaret asked for hands on supporting this document as a wg draft. There 
    was unanimous support to accept this as WG document.
    Second Session:  Wednesday, July 16, 2003 at 1530-1730
    v6-on-by-default -  Alain Durand
    Alain Durand presented the draft on actual experiments of IPv6 on by 
    default work at Sun (see draft and slides above).
      we come from a world where breaking existing technology (v4) when
      introducing new technology (v6) is not something we like
      partial ipv6 deployment in our network
      6to4 based, no relay router, no isatap
      some subnets are v6 enabled, some not
      some v4 subnets use private address
      some access to the enterprise network are through ipv4-only VPNs
      v6 addr are published into internal dns
      took 3 well-known implementations with ipv6 turned on
      observe interesting characteristics in bad v6 connectivity, private 
    address, and stuff
      "telnet bigserver"
      measure time it took to fall back from one address to the other
      extremely high delay on one of the 3 implementation
      "when you don't have a router, assume destination is onlink"
      tcp soft-error
        "no RA" case should be "zero delay" -> "onlink" assumption
        tcp timeout assumptions
            use v6-aware vpn, if not: tcp timeout delays
            v6 packet may go to unexpected path (non-vpn side)
      deployment BCP
    Rob Austein noted that TCP for v6 was a mess - no difference between v4 and 
    Itojun noted that "no RA" case -> ambiguous about outgoing interface, ND 
    spec need clarification
    Erik Nordmark noted that the onlink rule is useful when RA prefix is 
    expired but address is not expired.
    Pekka stated that need to analyze pros and cons.
    In cases of incomplete v6 connectivity, VERY long delays on some 
    implementations (in one case, 225 seconds before route change, even with 
    ICMP and RA) ? and this is per-address-tried!?! No reason it should even be 
    25 seconds ? need to tweak the spec so timeout is almost zero.
    Use AAAA in your DNS with caution!
    Use v6-aware VPN, if not (1) TCP timeouts, (2) packets don't go where you 
    think, (3) VPN should intercept/sink v6 packets.
    Other issues are less critical, but please read draft.
    Rob Austein noted that this is good work; we definitely need to write this 
    down. Most of these failures were also encountered in v4. We're more 
    likely to have lots of addresses in v6, so the problem is worse in v6.
    Itojun commented that the ND specification assumes every destination is on 
    link, but is not clear when it is not the case. This part of the spec 
    could be clarified.
    Mohsen Souiss noted that every TCP-based application does not work the same 
    way. For example, some web browsers are stuck on IPv6 addresses and this is a 
    bad thing. Alain Durand replied that Telnet actually is using the API the 
    way it should be used.
    Mohsen noted that with dig, for example, we get stuck as well. Some 
    application should be.
    Pekka Savola noted that it is clear that the application should not be 
    fixed first
    Alain: commented that issue 1 related to RFC2461 really hurts and should be 
    fixed. The fix is necessary to ship product.
    Margaret asked if the wg should take this on as a WG item. There was 
    unanimous support for this.
    Moreover, Margaret, as co-chair of the ipv6 WG, thinks this will result in 
    revisiting RFC2461.
    threedegrees - Christian Huitema
    Christian Huitema presented an update on the Threedegrees work he has 
    previously presented last year in v6ops.
    Main issue is that there are DNS issues in the Threedegrees 
    deployment. Some DNS responders respond with very bad responses, but these 
    vendors have been contacted and fixes are coming.
    The DNS issue has been documented for the dnsop WG, in 
    Security - discussion of what we should be doing - Chairs
    Pekka Savola presented his security overview draft (see draft and slides 
    above) to facilitate a discussion on what v6ops should be doing on 
    security. This discussion was scheduled as security is a core part of the 
    charter of v6ops, and there is a need to decide what to do to address this 
    Look at different kinds of issues
      IPv6 protocol
      Transition mechanisms in general
      + general observations
    What should we do about it?
      Very prominent in the charter, something needs to be done
      An abstract approach
      Which drafts would be applicable/which work should be initiated
      Adopt some drafts / initiate some new work?
    Different kinds of issues (the IPv6 protocol suite)
      Protocol itself (some generic, some more specific)
        Some people afraid of increased end-to-end transparency
            people used to the NAT "security model"
            education required; need a mechanism to control access
        Some people afraid of increased end-to-end encryption
          people used to the perimeter firewall "security model"
          due to key mgmt difficulties, may not be a huge problem
          highlights the need for end-host, distributed, managed 
        Issues in specifications
          how hosts should parse Routing Headers
          how privacy addresses' applicability is not clear
          how ICMPv6 messages may be generated in response to multicast 
          how neighbor discovery "on-link" sending model causes 
    Different kinds of issues (transition)
      Transition/Co-existence tools
        Tunneling in general
          UDP tunneling typically punches through NATs *AND* firewalls; 
    breaking assumptions
          configured IPv6-in-IPv4 tunneling slightly better (typically 
    explicit allow/disallow)
        Automatic tunneling mechanisms
          the risks of packet forgery and DoS attacks increase
          the virtual topologies, especially ad-hoc ones, make the network 
    architecture more complex
        Relay issues
          communication with third parties in automatic tunneling
          unless carefully done, increases the risk of DoS etc.
    Different kinds of issues (deployment)
      Issues in deployment
        Problems with IPv4/6 dual stack use
          certain cases of deployment may incur large timeouts (as 
          quality of IPv6 routing globally is inferior to IPv4: worse 
          some applications don't handle all the fallbacks properly
          some DNS servers/load-balancers abuse AAAA-querying resolvers
        Insecure service piloting
          testing services/applications without proper access controls
        Operational factors in network infrastructure
          unstable(r) router software, causing virtual topologies or breaks for 
    "production" v4
          slower processing (non-line-speed), causing hacks like MPLS
          missing features (e.g. no ability to turn off IPv6 telnet access)
          insecure default configuration/assumptions (if IPv4 access is 
    restricted, IPv6 may be allowed by
          default unless explicitly disallowed)
          costs of running one protocol (multiple topologies) vs two 
    protocols (double the processing)
    Different kinds of issues
      Things to note in general
        Prefer native IPv4/IPv6
          security issues greatly simplified
        Accept configured tunneling
          plain and simple
          where necessary, try to avoid if possible
          explicit knowledge of the end-points: a lot fewer risks
        Avoid automatic tunneling
          security properties typically difficult to handle
          usually bring on a lot of complexity
          may be difficult to retire ("sunset strategy")
    What should we do about security?
      Charter lists a lot of items of IPv4/IPv6 operations
        1. solicit input on sec issues from operators/community
        2. provide feedback to IPv6 WG on specs which are likely
            to cause sec issues
        (no 3.)
        4. publish docs on security risks of the operations (w/ sec area)
        5. identify sec issues in deployment scenarios/solutions
        We had better DO something!
        Security is about the most important item on our charter
      But what to do?
        Good question!
        Feedback sought..
    What should we do about security (generic)?
      We need more security expertise
        To evaluate security aspects of the proposals from the first
        And to help in figuring out an answer to the all of below
      We need better idea how to evaluate security
        How to deal with issues transparency etc. imply?
          specify local access control mechanisms?
          try to see if there's work on end-host firewalling?
        How to deal with issues NAT/firewall traversal imply?
          do we need to do more than what other NAT traversal mechanisms have 
    done (=nothing)?
          probably yes, but what?
        How to deal with the evaluation of transition mechanisms?
          how much complexity is "too much"?
          how much security is "enough"?
    What should we do about security (concrete)?
      Current drafts which could be applicable to this WG
    draft-cmetz-v6ops-v4mapped-api-harmful-00.txt +
    draft-bellovin-ipv6-accessprefix-01.txt +
          something like this is very much in scope
      Adopt some of the previous drafts?
        Good candidates
        If not adapt, push for being worked on (security area? IPv6 wg?)
    draft-bellovin-ipv6-accessprefix-01.txt or 
        Should we start working on something new?
          Bring in that security input from the ops/users community!
          How to go about those issues in IPv6 specs?
          Need to create two documents on security? *ARE* there issues to
            (ch4): potential security risks in the operation of 
            (ch6): identify open sec issues with deployment scenarios?
          If so, maybe need a small editorial team (or DT).
    There seemed to be a number of security people in the room for the 
    discuss that follows.
    Itojun: Agreed with overall direction of this document. 6to4 relay is his 
    hot issue, and he is still interested in getting his document 
    Rob Austein: tried to work on these issues at IAB workshop last year ? 
    could dig this up again. Pekka and I are converging offline, on a 
    semi-configured tunnel that's easier to use than existing proposals.
    Margaret: How do we get "significant study"? IRTF research group?
    Rob: talk to Bellovin.
    Christian Huitema: analysis should take place. Lots of proposals to limit 
    impact of "automatic tunneling".  You exaggerate the danger of 6to4 
    relays. Source spoofing attacks happen today, other dangers are worse.
    Randy Bush: security threats are best addressed by updating an existing 
    document. Randy noted that he disagreed with Christian.
    Erik Nordmark: the WG is supposed to be looking at 6to4 security. 
    Operators can look at the document and assess risks.
    Pekka: Not significantly worse than the v4 Internet today.
    Alain: Pekka's 6to4 document is already good. Make it a WG item and 
    last-call it, move forward.
    Brian Carpenter: Pekka did a good job. Don't think there's much we can 
    change in 6to4 without abolishing it.
    Margaret: Enough recent readers to make decision on making Pekka's draft a WG 
    Randy: it's an analysis of a WG protocol ? how much debate do we need?
    There was a unanimous show of hands to accept Pekka's draft as s WG 
    Gregory (security product vendor): We've been talking about NAT 
    security a lot at my company. The world believes this, no matter whether we 
    believe it or not. NAT default is nothing flows, v6 default is 
    everything flows. Are we building walls or roads here?
    Someone asked how hard is it to establish inside-to-outside 
    initiation as a default? Any vendor can do this today.
    Margaret: "How difficult could it be" for someone configuring routers in 
    their home? Impossible. Can vendors pre-configure all of this?
    Bob Hinden: not hard to start firewall with restrictive set of rules.
    Tony Hain: we're talking about security, and NAT doesn't equal 
    security. If you're going to replace a filtering device, you probably want to 
    replace it with another filtering device.
    Gregory: Stateful inspection is hardest at application gateway level, 
    especially with dynamic ports. Can we define this, or make 
    application guys define this (via registry)? Then Mom could do this 
    Margaret: this is more than we can do here.
    Christian: this is v6ops, not NATops. What we have to preserve is the 
    security of the users, and there are many ways to accomplish this (host 
    firewalls, etc.).
    Matt: how to move forward? Divide-and-conquer with small documents doing 
    threat analysis? Don't do an 80-page document!
    Alain Durand: one thing we've observed is that we need to make sure v4 and v6 
    security policy provide the same security. We need tools to make sure two 
    policies match, including update frequency.
    Rob Austein: two ways to protect Mom. Mom outsources this to an ISP, or UI on 
    the box that Mom buys. This is a challenge for UI and application behind UI, 
    and needs to be updated whenever a new application comes out.
    Gregory: what we need to preserve is NATish isolation, not NAT itself.
    Magaret: ADs should say how to figure out this issue.
    NAT-PT Applicability Statement team report - Peter Barany
    <no draft yet>
    Peter Barany presented a report from the new NAT-PT Applicability 
    Statement team:
    At the IETF V6OPS WG meeting in San Francisco, CA (IETF #56 meeting)
      Discussion took place about status of standards track RFCs 
    NAT-PT/SIIT (2766/2765) (just sitting at PS)
      No active editor for NAT-PT
      Need to decide what to do by March 03 with NAT-PT/SIIT
        Write an Applicability Statement?
      Decision: Write an Applicability Statement
        Form a Design Team
    Design Team Members
      Suresh Satapati (Design Team Lead)
      Rob Austein
      Peter Barany
      Karim El-Malki
      Satomi Okazaki
      Sentil Sivakumar
      Hao Wang
      NAT-PT Applicability Statement
    No Internet draft available yet.
    Scope & Goals
      Document the applicability (or non-applicability) of NAT-PT
        See RFC 2026 for definition of Applicability Statement
      Proposing modifications to NAT-PT (RFC 2766) (or extensions to make 
    NAT-PT applicable)
        is not within the scope of the Design Team
    "Table of Contents
     1. Introduction
     2. Applicability
      2.1 Deployment Scenarios
      2.2 Limitations
     3. Security Considerations
     4. References
     5. Authors and Contact Information
     6. Full Copyright Statement
    For 2.1 - Deployment scenarios agreed upon by Design Team
      2.1.1 3GPP Networks
      2.1.2 Futuristic Scenario
        Entire network infrastructure is IPv6 but there are some existing IPv6 
    hosts (or applications) that cannot be upgraded
        3GPP2 Networks
    For 2.2 - Limitations
      Some ideas
        Applications with IP addresses embedded in payload
        Address selection
        End-to-end security
          IPsec, DNSSEC
        Single point of failure
    Question about SIIT: do we want to also include SIIT? Should it be 
    considered, as well as NAT-PT? Same question with 
    bump-in-the-stack (BIS).
    Margaret: OK to work on theses RFCs as well.
    The Design Team has a mandate to include SIIT (RFC 2765) in the NAT-PT 
    Applicability Statement document (not sure whether or not we have to 
    change the title of the document to reflect this). Where SIIT is 
    referenced by RFCs/I-Ds other than NAT-PT (e.g., RFC 2767 BIS), a 
    separate section should/can be included in the NAT-PT 
    Applicability Statement document discussing SIIT in this context.
    Christian: you listed NAT-PT scenarios, but we found scenarios where 
    NAT-PT should NOT be deployed ? these should be included as well. 
    Applicability statements can be negative ? "don't use this here".
    Marc Blanchet: think about ICMP! Troubleshooting or something, but it's an 
    important topic.
    Alain: SIIT depends on where translation is happening. Pekka: some 
    confusion about what "ICMP" really is ? SIIT is not usually used on its 
    Rob Austein ? Most of the experience we have with SIIT was from NAT-PT. I 
    wish I could forget ICMP.
    Peter Barany remarked that this would be handled/discussed most likely in 
    the SIIT portion of the NAT-PT Applicability Statement document (as it 
    relates to NAT-PT ... not BIS). ICMPv6 translation is discussed in detail in 
    RFC 2765 (also, some of this will necessarily spill over into 
    mobility/MIPv6 discussed since MIPv6 uses extensions to ICMPv6 ... as do 
    other IPv6 technologies, e.g., multicast). We need to think about how to 
    partition the document to handle ICMPv6 and SIIT.
    It was also noted that the Design Team should think about using the 
    Cellular Networks, Unmanaged Networks, ISP Networks, and Enterprise 
    Networks as possible scenario sub-sections in the NAT-PT 
    Applicability Statement document since these scenarios are already being 
    addressed in separate I-Ds by the appropriate Design Teams and the work on 
    NAT-PT could be re-used from those 4 Design Teams. Peter said that the 
    design team will look at this.
    Margaret: agreement of the WG to make this work a WG item will be taken on 
    the list when the first draft is available.
    Writing IPv6 Applications report - Myung-ki Shin & Pekka Savola
    Myung-ki Shin presented the newest version of his application 
    transition draft (see draft and slides above).
    Why this draft:
      As IPv6 is deployed, the application developers and the 
    administrators will face several problems
        clarifies the problems and considerations
        application transition scenarios (cases)
        proposes guidelines on developing IP version-independent 
      One of the charter items of this wg
        good starting point for this topic
    General Problems with IPv6 application transition
      Dual-stack vs. application versions
        Operating system being dual stack does not mean having both IPv4 and 
    IPv6 applications
      DNS name resolution
        A client application can not know the version of peer 
    application by only doing a DNS name lookup
      Application selection
        Users may be confused by their various application versions 
    (IPv4-only, IPv6-only, IPv4/IPv6) because they don't know the version of 
    peer application by DNS query results
    Application porting considerations
    "IP version dependencies in applications
      Presentation format for an IP address
        dotted-decimal string for IPv4 vs. hexadecimal string for IPv6
      Transport layer API
        functions to establish communications and to exchange 
      Name and address resolution
        conversion functions b/w hostnames and IP addresses
      Specific IP dependencies
        IP address selection, application framing, storage of IP addresses
    Developing IP version-independent applications
      In order to allow applications to communicate with other IPv6 nodes, the 
    first priority is to convert the applications supporting both IPv4 and IPv6
        IP version-independent structures & APIs
      The applications should do iterated jobs for finding the working 
    address out of addresses returned by getaddrinfo()
      The applications will have to work properly in IPv4-only nodes 
    (whether IPv6 protocol is completely disabled)
    Open Issues
      Transition mechanism considerations
        Handling NAT-PT(DNS-ALG) address prefix
        Any other mechanisms ?
      Security considerations
        Handling IPv4 mapped IPv6-addresses
    Applications Area persons will join this team (as of Open Apps Area 
    meeting on Monday).
    Margaret: GRID people want to contribute, too.
    Dual-stack doesn't mean clients have both v4 and v6 applications.
    DNS does not know the version of an application based on DNS lookup.
    Looking at v4 applications in dual-stack, then v6 applications in 
    Dual-stack applications on v4-only host ? EPROTONOSUPPORT or 
    EAPNOSUPPORT errors dump out of the socket loop, and v4 is never tried!
    Presentation format, transport API, naming and addressing...
    Several guidelines on developing IP version-independent 
    applications, including running in v4-only nodes.
    Security considerations ? v4-mapped v6 addresses.
    Pekka: comments from Apps AD ? address being overloaded as identifier ? 
    needs to be clarified in this document.
    Q: failure of v6 address and fall-back to v4? Preference based on 
    performance, not just being v6? Alain: this is no different from 
    dual-homing case.
    Q: with default address selection, we could override v6 preference choice to 
    Brian: is this going to be a generic I/O system? Brian is almost-WG chair in 
    Global GRID forum. Need to figure out how to work together.
    Q: v6-only? If you use v6 APIs, you have access to v4 addresses in v6 
    Christian: one may want to develop v6 only app because of NAT 
    traversal issue.
    Alain: don't want to ship one app for each case.
    Patrik: What do you mean by "application"? "GETHOSTBYNAME" is all I want to 
    do (multiple interfaces, etc. are things I'd like to ignore)... 
    Discussion is strange...
    Margaret: you're saying document deals with useful issues, but how many are 
    applicable to applications writers?
    Q: Are C libraries the kind of applications we're talking about? Connect 
    serially or in parallel? Margaret: DNS is an application, and TCP is on the 
    hairy edge of being an application.
    The document will be revised with the help of applications people, and will 
    come back to v6ops later.
    Status report of IPv4 Survey drafts - Chairs
    SLIDES: none
    Pekka gave a status report of the progress of the IPv4 Survey 
    individual drafts since the last IETF (see drafts above).
    Pekka said that he and Margaret had pinged the appropriate ADs since 
    IETF-56, and got responses from about four areas, and also met with the 
    APPS area at this meeting. The nine documents now have individual 
    editors assigned to each.
    Documents will be updated after the first round of comments received from 
    the areas. The co-chairs will follow up with other areas not yet heard 
    Pekka noted that these documents need to be credible ? so all wg 
    participants are requested to review them!
    There were no comments.
    Meeting adjourned.


    Unmanaged networks transition
    Forwarding Protocol 41 in NAT Boxes
    IPv6- IPv4 Translators for 3GPP
    ISP Networks
    IPv6 Enterprise Networks Scenarios
    IPv6 Transition/ Co-existence Security Considerations
    NAT- PT Applicability Statement Design Team
    Application Aspects of IPv6 Transition