Last Modified: 2004-02-12
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.
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 |
RFC | Status | Title |
---|---|---|
RFC3574 | I | Transition Scenarios for 3GPP Networks |
V6OPS MINUTES final version of 24Mar04 ========================== IPv6 Operations WG (v6ops) IETF-59, Seoul, Korea Monday, March 1 at 1530-1730 Thursday, March 4 at 1530-1730 ====== CHAIRS: Pekka Savola <pekkas@netcore.fi> Jonne Soininen <jonne.soininen@nokia.com> The minutes were edited by Pekka Savola and Bob Fink from notes taken by Juha Wiljakka (both sessions), Alain Baudot (1st session) and TJ Kniveton (2nd session). There were over ??? folk in attendance. =========================== Administrative information: v6ops discussion: <v6ops@ops.ietf.org> Subscribe to v6ops mail list: <majordomo@ops.ietf.org> "subscribe v6ops" v6ops mail archive: <http://ops.ietf.org/lists/v6ops/> v6ops IETF Charter web page: <http://www.ietf.org/html.charters/v6ops-charter.html> v6ops web site: <http://www.6bone.net/v6ops/> v6ops Project Status: <http://www.6bone.net/v6ops/v6ops_project-status.html> ======= Agenda: Monday, 1st Mar: 1530-1730 ========================== Introduction and agenda bashing - 5 mins, Chairs/Jonne - Scribes! (Jabber also?) Document status - 10 mins, Chairs/Pekka - What has happened with WG documents lately - GOAL: show the status of WG documents Introducing IPv6 in MPLS Networks - 20 mins - Discuss the approaches: configured tunneling, signalling upgrade, BGP tunneling hacks, etc.? - GOAL: try to get closer to consensus on what's required to use IPv6 in MPLS-based networks. "Zero-configured" & Opportunistic Tunneling (esp. NAT traversal) Discussion - 40 mins, P. Savola - Do we agree that this is something we need in the first place? * And if so, in which specific scenarios? - What are the models for deploying relays (in-host, in-site vs network)? What are the implications? - GOAL: try to get closer to consensus on what's the right approach for opportunistic tunneling. IPv6 Distributed Security Requirements - 10 mins, J. Palet - draft-palet-v6ops-ipv6security-00.txt - quick overview of new kind of security requirements - GOAL: introduce the issue Thursday, 4th Mar: 1530-1730 ============================ Tunneling Scenarios Analysis - 20 mins, Chairs - introduce issue, first discussion continue later IPv6 Mobility Scenarios/Requirements in 3GPP - 10 mins, C. Williams - loosely based on draft-yamamoto-mipv6node-v4trav-00.txt - discuss 3GPP2 IPv6 mobility and transition issues - GOAL: understand the scenario and its requirements Transition mechanisms update - 10 mins, Chairs/Pekka - draft-ietf-v6ops-mech-v2-02.txt - draft-savola-v6ops-mechv2-interop-impl-template-00.txt - should be already at the IESG, discuss issues if any - Discuss implementation reports / interop testing - GOAL: Iron out last-minute issues, and make it easier to go to DS IPv6 Renumbering Procedures - 10 mins, F. Baker - draft-ietf-v6ops-ipv6-renumber-procedure-00.txt - discuss changes, solicit input - GOAL: prepare for WG last call Statistics from a 6to4 Relay - 5 mins, P. Savola - (no draft) - quick presentation on the usage statistics from a public 6to4 relay - GOAL: give the WG an impression about the traffic on 6to4 relays Tunneling Scenarios Analysis continued - 45 mins, Chairs Quarantine Security Model - 10 mins, S. Kondo - draft-kondo-quarantine-overview-00.txt - quick overview of a possible security model for IPv6 - GOAL: introduce the issue, to be fully discussed in security area Skipped due to lack of time: IPv6 Security Overview - 10 mins, P. Savola - draft-savola-v6ops-security-overview-02.txt - introduce the approach; discuss changes. - GOAL: discuss whether something like this is needed as WG item, adapt if so. 6to4 Security Considerations - 10 mins, P. Savola - draft-ietf-v6ops-6to4-security-01.txt - discuss changes, solicit input whether the substantial changes to the document layout helped. - GOAL: prepare the document for WG last call ======== Minutes: ====================================================== First Session: Monday, March 1, 2004 at 1530-1730 ====================================================== Introduction and agenda bashing - 5 mins, Chairs/Jonne - Scribes! (Jabber also?) SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/v6ops-agenda.pdf> Jonne introduced the session and presented the agenda. === Document status - 10 mins, Chairs/Pekka - What has happened with WG documents lately - GOAL: show the status of WG documents <http://www.6bone.net/v6ops/v6ops_project-status.html> <http://www.ietf.org/html.charters/v6ops-charter.html> SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/v6ops-agenda.pdf> Pekka presented current document status. - ISP Scenarios-Analysis: wglc held - Enterprise scenarios at -01; feedback & revision needed -> wglc; No work yet on enterprise analysis/solutions doc - Appl. transition doc revised, English proofread, in wglc -> 20.3; sent to IESG after that - v6 on by default to wglc soon after Seoul, no presentation in Seoul - Onlink assumption at -00, revision & wglc after Seoul - 6to4sec at -01; one more revision before wglc? - Renumbering procedures at -00, try to finish by IETF#60 - IPv4 surveys, all in RFC Editor's queue - Other, very critical work: IPv6 in MPLS nws, tunneling service resolution, opportunistic tunneling - Some other interesting docs: transarch -03, IPv6 DNS issues and considerations (2 dnsop wg docs), unique local IPv6 addr., 3GPP2 or other IPv6 mobility scenarios, guide to mapping IPv4 subnets into IPv6 Document Status: RFCs: - Trans-mech PS, revision sent to IESG for PS, no IETF LC yet. Implementation & Interop report template proposed; To be discussed - NAT-PT PS, NAT-PT applicability draft would require revision - SIIT PS, NAT-PT applicability draft also includes SIIT - 6TO4 PS, 6to4 security analysis is WG item, presented on Thu - 6TO4 anycast PS, no activity - 3GPP scenarios published as info RFC, analysis in IETF LC WG Documents: - 3GPP analysis IETF LC ended 1.3.04, UE tunneling to be considered separately; minor issues raised by AD - Unmanaged scenarios, at -03, in the final throes of the RFC-Editor process - Unmanaged analysis, at -01; WG Last Call just ended; Will likely need revision, then send to the IESG? Try to work on some consensus on the mechanisms proposed - ISP Scenarios & Analysis, at -01; WG Last Call just ended; Need to resolve MPLS networks recommendation If possible, send it to the IESG in Mar/Apr - Enterprise scenarios, at -01; Waiting for feedback, revision after Seoul; WG Last Call after that - Enterprise solutions; No current work -- feel free to write something; Sooner rather than later! - Trans-mech update, at -02; Status: sent to the IESG for PS, not reviewed by AD yet Implementation & Interop report template proposed; To be discussed - Application Transition, at -01; Revised, and English proofread; in WG Last Call To be sent off to the IESG after that. - IPv6-on-by-Default, at -01; To be WG last called after Seoul Presentation dropped because of last-minute cancellation - Onlink assumption, at -00; To be revised and WG LC'ed after Seoul - 6to4 security, at -01; Solicit feedback on -01; presentation on Thursday; Revise once? before WG LC. - Renumbering procedures, at -00; Solicit feedback; Try to finish just before/around San Diego IETF? - IPv4 surveys; All done -- being edited by RFC editor Other work to be done: * Very critical work: - IPv6 in MPLS networks resolution - "Tunneling service" resolution - "Opportunistic" tunneling resolution * Follow-up work - Protocol work; Either here or in other WGs * Potential new work - IPv6 Security Overview? Some other interesting documents: - A view of transition architecture draft-savola-v6ops-transarch-03.txt - IPv6 DNS Issues and Considerations draft-ietf-dnsop-ipv6-dns-issues-04.txt draft-ietf-dnsop-misbehaviour-against-aaaa-00.txt etc. - Unique Local IPv6 Unicast Addresses draft-ietf-ipv6-unique-local-addr-03.txt - 3GPP2 or other IPv6 Mobility scenarios [several drafts] - Guide to mapping IPv4 subnets into IPv6 draft-schild-v6ops-guide-v4mapping-00.txt === Introducing IPv6 in MPLS Networks - 20 mins, P. Savola - Discuss the approaches: configured tunneling, signalling upgrade, BGP tunneling hacks, etc.? - GOAL: try to get closer to consensus on what's required to use IPv6 in MPLS-based networks. SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/v6-in-mpls.pdf> Pekka presented IPv6 in MPLS networks. IPv6 in MPLS networks - The biggest unresolved issue in the ISP analysis - How to deploy IPv6 in the MPLS networks? Options Require deploying native IPv6 support Require MPLS network to support setting up IPv6 LSPs Use IPv6-over-IPv4 configured tunneling Use an automatic tunneling mechanism to set up v6-in-v4 tunnels in the network - The first and second are longer-term options Well, could be done in the short term as well.. The exact details what is required for the control plane upgrade are unclear - The third is a simple option, and works very well However, if IPv6 is added on all the edge routers, setting these up is cumbersome.. - The fourth is the "lazy man's solution" to configured tunneling More on this in the next slide Automatic tunneling in MPLS - Automatic tunneling =~ "BGPTUNNEL" Cisco has claimed IPR on this, not clear which parts of the spec Its relation to Cisco's "6PE" is a bit unclear Some say they're the same Some think BGPTUNNEL has cruft in it, and would need a clean-up Other implementations, do they interoperate? - Vendor has sold hardware which doesn't do v6, needs workaround Or doesn't do v6 well enough Is it IETF's problem work around such "reasons" ? - What's wrong with IPv6 LSP set-up deployment? Takes time to implement and/or upgrade? Folks don't want to upgrade their MPLS signalling plane Not sure if a valid reason, as upgrades happen in any case.. - Why not configured tunneling? Want to set up large IPv6 networks with "featureless" hardware Discussion: Xiaobao Chen / Orange: large mobile operator with experience on MPLS. Commenting why not configured tunneling: static MPLS tunneling has much drawbacks (performance, QoS, lacks in traffic engineering). Pekka: I don't think we're talking about the same thing. Static IP Tunnels vs. Static LSPs. Jonne rephrased the question to clarify. itojun: he says they already have traffic engineering capability in MPLS, and they do not want to have to do it again. Dan Williston (?) from Cisco (that has 6PE experience): 6PE is marketing name for BGP tunneling in Cisco. Pekka: A Cisco guy has commented that it isn't. Cisco guy: Commenting why not dual stack deployment instead: Benefit of 6PE is that it allows ISP to put IPv6 only in PE nodes, it also makes IPv6 deployment easy. What about IPv6 LSPs - it is much more complicated. Why not manually configured tunneling: It is harder to maintain, conf. tunnels may be ok in smaller networks. Tony Hain: why does IETF mandate people to run networks the same way. Different networks have different problems, different approaches need to be taken into account. Mat Ford (BT): A document telling benefits and drawbacks of different solutions would be useful. Showing hands: 1) BGP tunneling or similar is needed? => Quite many hands up (rather many) 2) No need for BGP type of tunneling => (a couple) hands => rough consensus: work on BGP tunneling for providing IPv6 over MPLS. === "Zero-configured" & Opportunistic Tunneling (esp. NAT traversal) Discussion - 40 mins, P. Savola - Do we agree that this is something we need in the first place? * And if so, in which specific scenarios? - What are the models for deploying relays (in-host, in-site vs network)? What are the implications? - GOAL: try to get closer to consensus on what's the right approach for opportunistic tunneling. SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/opportunistic-zeroconf-tunneling.pdf> Pekka presented "Zero-configured" & Opportunistic Tunneling, work that he and Jonne prepared. "Opportunistic" vs zero-configured The concepts - "Opportunistic" in Internet domain Minimal or zero infrastructure Connectivity between peers set up in an "ad-hoc" fashion Required if assuming "vendor-driven" deployment When the vendor requires IPv6 for enhancing its functions (e.g., peer-to-peer libraries) In contrast to user installing a new shiny application which requires IPv6 E.g., 6to4, Teredo Applicability: when the direct ISP doesn't offer service Tunnel broker typically not available close by, or easy enough to set up - "Zero-configured" "Configured tunnel" or similar but not configured manually Tunnel-end -point discovered automatically E.g., STEP or ISATAP; TSP with some discovery mechanisms Applicability 3GPP networks, direct ISP offering tunnel, enterprise -internal tunneling "Opportunistic" vs zero-configured - What's so special about opportunistic? There was a long threat on the list Not sure if it resolved much of anything.. Some (many?) see there is no purely "vendor-driven" approach Or if there is, we should not be recommending it If so, automatic tunneling maybe not be a strict requirement - Critical point of opportunistic vs others Whether infrastructureless, even partial, deployment is desirable And how critical that infrastructure is How much to weight in the favor of "less infrastructure" Economics of deployment is also a factor - against both approaches Anonymous services are better for 3rd party service providers 6to4 relay with 192.88.99.1 vs Tunnel broker with native addresses The different scenarios - Unmanaged user wants to do p2p with another Direct "short-cut" connectivity very important If no support from the direct ISP Automatic tunneling works automatically: Teredo requires "Server" with low b/w reqs Tunnel broker would help, if the users could find a free broker nearby If there would be incentive for broker deployment, a "nearest broker discovery" process would also help Unless the user is really determined, the user is lost without automatic tunneling If there is support from the direct ISP Dual-stack or; tunnel broker or a simple configured tunneling system If only one supports, still OK without infrastructure if "local" relays - Enterprise internal network wants to deploy v6 Zero-configured tunneling, configured tunneling, or dual-stack - 3GPP user wants to use v6 Zero-configured tunneling or dual-stack The operator should provide a service, and if doesn't, similar to "unmanaged" Opportunistic relay deployment - Relay deployment Native to 6to4 All dual-stack sites could have a relay, just turn on 6to4 pseudo-i/f But currently don't.. Would place the "burden" of deployment on native users 6to4 to Native Very difficult, but not worse than Tunnel Broker..? Native to Teredo All the sites could have a relay But currently don't, and not sure if a good idea.. Would place the "burden" of deployment on native users Teredo to Native Very difficult, similar to 6to4..? 6to4 to Teredo Sites could have an internal Teredo relay Teredo to 6to4 Nodes could have an internal 6to4 relay But some NATs might block proto-41 at egress "Zero-configured" Teasing out "Zero-configured" - Critical questions are at least How important is 3rd party ISP tunneling? Are solutions required? If yes, who would want to provide *production* service using their IPv6 addresses? Would imply long tunnels, bad quality and bad IPv6 experience.. like today's 6bone How much should we use existing tools/mechanisms, if available? NAT traversal, authentication, prefix delegation, DNS discovery, etc. Should be generic so that a node that is used in unmanaged or enterprise, with native or tunneling, doesn't have to multiple methods? Implement from scratch ("short term fix"), develop good tools ("long term solution")? How desirable is "opportunism" inside the ISP/3GPP or site? The tradeoff: if the traffic grows too much, it's time to enable native IPv6? Inside the ISP: (the neighbors wanting to talk p2p): probably not critical Inside the 3GPP: depends on how much traffic between UEs; the IPv6 status? Inside the enterprise: in larger sites, possibly desirable (e.g., p2p videoconferencing) "Zero-configured" solutions "Zero-configured" solution properties - Direct connectivity between (some) peers ISATAP: yes Others: no - Use of existing tools TSP: reinvents all discovery/config functions ISATAP: mostly new STEP: client - only little new; server - a bit L2TP architecture: uses only existing tools - 3rd party tunneling (critical: authentication) TSP and L2TP: no problem if 3rd party ISPs exist ;-) STEP and ISATAP: out of scope or not applicable Discussion: Xiaobao Chen asked a clarifying question on why tunneling needed in 3GPP networks at all. Jonne answered: noticed that some operators have problems, because current SGSNs do not support IPv6. Best way is deploying native IPv6 support (IPv6 PDP contexts), but UE tunneling may be needed in some cases, especially in roaming cases. Chen: Are you talking about user IP layer or transport IP layer in 3GPP networks? Jonne: This discussion is not about MPLS, this is user a layer issue. - What is so special about opportunistic / long thread on the mailing list, not sure if it resolved anything... Some see there is "vendor-driven" approach. If so, automatic tunneling maybe not be a strict requirement - Critical point of opportunistic vs. others: infraless deployment is desirable, how much in favor of less infrastructure; economics of deployment is also a factor - against both approaches; anonymous services are better for 3rd party service providers. Spencer Dawkins: discussion on the mailing list specifying source address specification. Pekka: I don't remember this discussion lately... Pekka: We have run a public 6to4 relay for 2.5 years for third parties; wouldn't do that with our own IPv6 addresses, w/ tunnel server. Erik Nordmark comments: IPv4 and IPv6 addresses... [question related to operational problems and DNS? -- was not recorded] different scenarios: - unmanaged users wanting to do peer-to-peer with another: direct short-cut connectivity very important; if no support from the direct ISP (automatic tunnels work automatically, Teredo requires serve, tunnel broker would help; unless the user really is determined, the user is lost w/o automatic tunneling); if there is support from the direct ISP (ds or tunnel broker or a simple configured tunneling system; if only one supports still ok without infra if "local" relays) - Enterprise internal nws want to deploy IPv6: zeroconf, configured, dual stack - 3GPP user wants to use IPv6: zeroconf tunneling or dual stack (the operator should provide a tunneling service and if not, the case is similar to unmanaged case Chen: what do you mean with operator service provision? Pekka: 3GPP operators should provide native IPv6 service, but if not, then tunneling is needed. - Relay deployment: native to 6to4, 6to4 to native, Native to Teredo, Teredo to native, 6to4 to Teredo, Teredo to 6to4 - Teasing out zeroconf / critical questions: how important is 3rd party ISP tunneling / are solutions required?; how much should we use existing tools / mechs, if available?; how desirable is "opportunism" inside the ISP/3GPP or site? (the tradeoff: growing traffic->start to use native v6; inside the ISP; inside the 3GPP (depends on how much traffic between UEs, the IPv6 status?; inside the enterprise: in larger sites possibly desirable (p2p videoconf., etc.) - Zeroconf: direct connectivity between the peers: ISATAP yes, others no - Use of existing tools: TSP, ISATAP (mostly new), STEP, L2TP - 3rd party tunneling (critical: authentication) TSP and L2TP Tony Hain: Does not figure out what zeroconf and opportunistic is? Scenarios docs are describing problems; solve generic problems here? Should analyze issues and then pick up appropriate mechanism(s). Jonne: Analysis has been done, we check are the tools that have been proposed useful? Pekka: we're trying to look at the mechanisms according to scenarios/analysis context, but having done so, we have identified some generic issues. Hain: doesn't see distinction between two types of mechanisms; one might apply in some cases, the other in others; must be answered based on the applicability area. Itojun: Does not get the difference between vendor driven and user driven. All techniques have different target customers; how to make consensus call? He has difficulties to see the distinction between the concepts. Mechanisms like ISATAP, Teredo, etc. are separate and they all have different target audiences. Jonne: will ask about consensus at the the need for these mechanisms. Hesham Soliman: in the scenarios work, we left out discussion on the mechanisms; now we get back to discussing the mechanisms. Jonne: actually we're following up the scenarios work. Hesham: OK, but the presentation is not connected to scenarios. Pekka: many mechanisms (up to 4) mayb be used for the same case, so mechanisms have to be evaluated. Hesham: Then discussion should not be generic, but on precise scenarios. Chen: When thinking about solutions, you also have to consider downsides. Is MPLS over IP considered in scenarios and analyses? Jonne: Not discussing MPLS tunneling in this slot, certainly no MPLS in the 3GPP UEs. Core networks are separate. Chen: practical problems need to be considered. Thaler: drivers beyond v6 are direct peer-to-peer communication, whether with high bandwidth requirement or something like VoIP; this goes together with direct connectivity. Nordmark: Does not understand vendor / user driven separation Hinden: understands the distinction, but thinks such distinction is not useful. All mechanisms are useful anyway. Wiljakka: From cellular (3GPP, 3GPP2) networks point of view configured tunneling in the mobile terminal does not look like a feasible alternative. Especially in 3GPP networks that have large number of hosts, addressing is dynamic and typically also private IPv4 addressing. In that case, automatic tunneling looks feasible and ISATAP is one alternative that looks positive. (Pekka commented that now we talk about zeroconf tunneling). Juha really recommends that this wg makes real work and specifies also automatic tunneling mechanisms. Finally, Juha said that he agrees on the conclusions on needed tunneling mechanisms in Unmanaged networks evaluation doc. Jordi: The point is much simpler that we are going to figure out... A way to automatically make sure that every client has IPv6 connectivity available even when moving thru different networks. I'm having this problem when traveling and I can sort it out most of the time because have the expertise, but this is not the case for regular users. We need a kind of auto-transition feature that choose the right protocol from a set, no needed user intervention, but ensure connectivity even if this is bad (worst case, for example, IPv6 over HTTP, of course I will not suggest it, only in very extreme cases). Hesham: Does not understand what does user-centric mean. People start using IPv6, but the user is not asked about that... Tony Hain: vendor that chooses to [push IPv6 to the users?]... Pekka: I don't say that vendor-driven mode is bad, but it's a different approach with different assumptions. Tony: the problem is to get the list of mechanisms to become standard Pekka: maybe we don't want to standardize all the mechanisms Hain: you haven't got back to the scenarios in context. Hain: Internet is not one tiny network, it is a big bunch of networks Nordmark: users want to use net for different applications: email, chat, ... The users are the entity using the services. Classification is not useful -- if the user doesn't want to do something, vendor should not force him. To Tony: cutting down is useful; should we have standardized different flavors of TCP and UDP to fill different roles, instead of two basic mechanisms? Mohsen Souissi: One of the best things in this wg is that we have identified different scenarios and tools. Do we want to deploy real networks with NAT traversal etc. In the production networks we need best tools and best security. Jordi: we want to deploy IPv6 - if we make tools perfect, it takes so long that we will miss the train. Not so sure how many mechanisms must be specified. There are many possible networks, many possible scenarios, I insist that we must ensure that the client can have IPv6 connectivity in any case, automatically, a kind of auto-transition, of course, trying to use the best possible solution. Chairs suggest to post-pone discussion to next session on Thursday. Bob Hinden: Just ask the question, don't wait any more. We have fooled around for 3 years already. What to ask? Tony Hain: We do not understand bullets? Jonne: 6to4 is out from this discussion. David: Lots of people in this room are ready to answer; go on and ask the question. Consensus call (raising hands): 1) Is opportunistic tunneling needed => many hands; a few hands against. 2) Is zeroconf tunnel needed to be standardized => many hands; nobody against. => Consensus: both are needed and will be standardized. Clarification: no consensus standardizing all of them, mechanisms will be selected. Implementation and deployment is a pro for mechanisms that will be forwarded. More detailed questiosn to be asked on Thursday. Dave Thaler: still confused what zeroconf menas, voted for it, but not sure what it meant. David K: We need the opinion of the people. Selection of mechs need to be done based on scenarios. Jonne: we have to analysze the different solutions with scenarios to identify the best ones. Droms: opportunistic/zeroconf is not a realistic division === IPv6 Distributed Security Requirements - 10 mins, J. Palet - draft-palet-v6ops-ipv6security-00.txt - quick overview of new kind of security requirements - GOAL: introduce the issue SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/ipv6-security.pdf> Jordi Palet presented IPv6 Distributed Security Requirements. Motivation: Border firewall is a bottle neck and does not enable end to end security. Many users and devices are nomadic, so static model does not apply. Different visited network have different security policies. Devices have extra power to process bigger security processes. Solution: Use of personal firewalls, which should be enabled by default; should look at security policy of visited network; could deal with IDS; may cope with virus and spam Concept: Attack/threat: active or passive; security is protection and IPSEC is used; need policy management tool, policy decision point. Typical architectural scheme is shown. Discussion: Unknown: suggest to have a look at netconf or sipping WG where they are also dealing with the same kind of things. ====================================================== Second Session: Thursday, March 4, 2004 at 1530-1730 ====================================================== Modified agenda for 2nd day: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/v6ops-agenda2.pdf> === Tunneling Scenarios Analysis - 20 mins, Chairs - introduce issue, first discussion continue later SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/scenarios-tunneling-analysis.pdf> Pekka presented Scenarios tunneling analysis. Introduction - First Check scenarios defined in the scenarios/analysis in more detail Try to tease out the subcases of the scenarios .. to understand the real cases better. - After that Look at the properties of the solutions compared to scenarios Find one or more (as few as possible) recommended mechanisms Find consensus on the mechsnism(s) today, or very soon Reach consensus, be sent for PS before San Diego (hopefully) Publish the specs describing current implementations Informational/Experimental through RFC-editor With an applicability statement or IESG note After consensus which mechanism(s) for PS Scenarios tunneling analysis 1/3 - 3GPP Networks Need v6-in-v4 tunneling when roaming to IPv4-only 3GPP network May need v6-in-v4 tunneling where the 3GPP operator has not yet deployed IPv6 PDP context support at all But would support some IPv6 through a transition mechanism Support for no 3GPP support at all out of scope If appropriate, Unmanaged transition mechanisms can be used - Issues Is node-to-node direct tunneling required inside the network? At least "nice to have".. Scenarios tunneling analysis 2/3 - Unmanaged networks The ISP doesn't support any IPv6, user must get IPv6 automatically a) with little infrastructure, and without contracts, or signups b) with a contract, signup, for higher security/manageability, etc. -- explicitly from another ISP out there Long tunnels are bad and don't make much sense -- is b) a real scenario worth solving? The ISP wants to support IPv6, but AR/link/gateway can't do v6 3 cases: tunneling from the gateway, separate v6 gateway, or the host(s) Solution to b) would work here as well -- but not necessarily the other way around - Issues NAT and dynamic IPv4 must always be supported Direct tunneling and low amount of infrastructure is required when there is no ISP support Is node-to-node direct tunneling inside the same ISP required? it might "come free" by the use of 6to4/Teredo note: this gets VERY difficult when NAT is in the path! Scenarios tunneling analysis 3/3 - ISP scenarios ISPs want to support unman/enterprise, nothing else - Enterprise networks ???? Scenarios work not gives no help on this yet.. The enterprise wants to deploy IPv6 using internal tunneling. Does this need to be direct? "would be nice.."? - Optional additional scenarios IP mobility (mainly 3GPP2) - node mobile, not stationary requires that time required for roaming signalling is low there may be a need for v4-in-v6 tunneling at least in some timeframe Solution Summary - Two tables: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/scenarios-analysis.pdf> Solution Summary Obtained by combining the matrices - Unman 1a) requires Teredo - Unman 1b) and 2) require STEP or TSP (ISATAP is out) - 3GPP 1) can be filled by STEP or ISATAP; no ISATAP if sec. req'd - 3GPP 2) can be filled by STEP or ISATAP Only ISATAP if direct connectivity is a MUST requirement - Teredo and STEP the [lowest] common denominator With Teredo + TSP coming a bit behind ? Questions to the WG - Does the proposal about Informational/Experimental publication make sense? Describing current implementations - Is the analysis going to the right direction? - Unman 1a) requires Teredo. Is there WG consensus for adopting that? - Does WG feel that we have to find only one solution? (Except for Unman 1a) if decided already) Whether an existing one or a hybrid? - If 1, can we choose between TSP, STEP and ISATAP? Or should an optimal combination proposal be made? Bob Hinden: I still believe that the wg can move forward with these also forwarding the mechanisms that have been deployed already. If people are using a mechanism, we have to specify it. We can work in parallel, no need to delay until the next IETF. Pekka: No indication of delaying the work until next IETF. Bob: When woul dit start? Jonne: Proposal from our ADs to go experimental with items which have been on the table for some time, with a statement that v6ops wg will be working on a preferred solution. Bob: Are we going to talk about the process today? It's not on these slides. After all this time, we should. Pekka: it is on the first slide, so yes. - publish the specs describing current implementations - info/exp through RFC-editor - with an applicability statement / IESG note - after consensus mechs for PS Bert Wijnen: Current policy is not allowing experimental personal RFCs, because that would be an end run around WG. Now individual documents can go forward, with disclaimer that IETF is working on a standardizxed solution. Bob says OK. That's a question you should propose to WG, but first questions about analysis. Tony Hain commented: It took 2,5 years getting to second last point, it is time to get it done. Jonne: Analysis documents are stable now. We are starting to develop mechanisms that suit those analyses. in parallel to that, we will allow people to post as individual submissions those solutions that are already in the market. Erik Nordmark: Slide says current implementations. Drafts describe potential extensions to things that haven't been implemented yet. Pekka: Exactly, we would encourage people submitting those drafts describe current implementations, not what they could be. Dave Thaler: Clarifying question on ISP bullet point #2, Pekka replied. (what "not the other way around" meant) Dave Thaler: As the slide says, enterprise scenarios document doesn't yet give much help in what's required. But Enterprises want v6 with little overhead in any case. Jonne: not discussing enterprise today, Dave should contribute to Enterprise work. Fred Templin: Experimental describes the implementations that are there. What about advanced features? Jonne: We should document those implementations. Pekka: The point is that someone can implement it and interoperate. Documenting only the current implementations. Fred Templin: Can extensions and improvements be proposed as work items? Pekka: that would be input to the mechanism selection process. Le Faucheur?: Comment on cross-referencing... Recommend referencing these docs? E.g. ISP scenarios - recommend that we reference for these docs there? Pekka: Are you asking about how we should capture this presentation we are having here? We would integrate the ideas in the presentation with the analysis documents. Jonne: This document is what we think that the WG thinks. Pekka: (When waiting for the next presentation to start) No time to present application transition doc today, it's in WGLC, send input on the list. === IPv6 Mobility Scenarios/Requirements in 3GPP - 10 mins, C. Williams - loosely based on draft-yamamoto-mipv6node-v4trav-00.txt - discuss 3GPP2 IPv6 mobility and transition issues - GOAL: understand the scenario and its requirements SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/ipv6mobility-trans.pdf> Carl Williams presented Thoughts on IPv6 Transition for Mobile Nodes. A number of us are looking at Mobile IPv6 deployment. We have an issue of not having ubiquitous IPv6 access to networks. Broader picture is that we have 2 mobility protocols, Mobile IPv4 and Mobile IPv6. Discussion in MIPv6 and drafts; Henrik Levkowetz organized Bar BOF on Monday evening to talk about this. Looking at mobility from transition perspective, how do we transition for MIPv4 users to MIPv6? Support for IPv4 seamless roaming for MIPv6 users? Transition implications in choosing an approach - MIPv4 and MIPv6 are different protocols with different features. There is an appendix in slides, with scenarios we have identified as important. We were looking at providing only what base spec provides, in terms of performance. Pekka: Any Internet ADs present that want to comment about this? Jonne: Dave, you aren't an AD yet. Thomas? Thomas: Wasn't paying attention. Jonne: Question is where this discussion should go -- mobile IP working groups? here? somewhere else? Pekka asked if you can give us guidance now, or do you want to discuss further and coordinate between WGs? Thomas: defer. v6ops is where we've been doing transition work and other groups not set up to do this yet. Dave Thaler: Not clear to me what the distinction is as opposed to laptop doing existing transition mechanisms? Henrik Levkowetz: MIPv4 and MIPv6 are designed to minimize overhead and signaling in movement. If you use current transition mechanism, you will have existing transition mechanism signaling, and then MIP signaling. So VoIP may be slow and painful. We have to analyze this to see what performance we get. Erik Nordmark: Hard to balance what is the existing complexity vs. performance gains you could get. Complexity would be significantly higher than just layering on top of each other. Henrik: We have implemented 1 scenario, and it required one more MIP extension and nothing else, the complexity was not great. TJ Kniveton: In designing IPv6, mobility is an important factor. So mobility should be considered in looking at transition scenarios by this group or any group looking at it. === Transition mechanisms update - 10 mins, Chairs/Pekka - draft-ietf-v6ops-mech-v2-02.txt - draft-savola-v6ops-mechv2-interop-impl-template-00.txt - should be already at the IESG, discuss issues if any - Discuss implementation reports / interop testing - GOAL: Iron out last-minute issues, and make it easier to go to DS SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/transmech-update.pdf> Pekka presented an update on the Basic Transition Mechanism work. Transmech status and steps forward - Until now Updated -01 to -02 No issues raised at the second WG LC Sent to the IESG, for Proposed Standard - Next steps Wait for IETF Last Call comments (if any) Wait for IESG feedback and resolve Get consensus on implementation and interoperability reports Draft out, but no comments yet - Next 6 months Wait for the implementations to be revised? Get the implementation & interop reports Revise the specification if needed Submit as Draft Standard Transmech changes between 01 and 02 - Functional changes (at least) Unidirectional tunnels removed Remove DNS operational guidance, refer to another document Remove SHOULD req on link-locals being based on IPv4 Add SHOULD requirement for setting source address of tunnel Add MUST checks for source addresses Should be possible to choose either static/dynamic MTU on per-tunnel basis if both implemented Static MTU can now default to anything between 1280 and 1480 bytes But if not 1280, knobs to set it MUST be in place Add minimal MUST rules for IPv4 reassembly and IPv6 MRU Summary Previous implementations should interoperate, but are non-compliant - Editorial changes A lot.. Implementation & Interoperability - Implementation status must be verified before DS Each feature In the draft, done in excruciating detail - Interoperability of specific features must be tested Each feature must interoperate Also done in detail Organizing the actual testing it out of scope Does anyone want to volunteer to do something? - Questions to ask Is using a detailed template a good idea? Should the template be returned separately for implementation and interoperability? The former is easier to fill, so we might get feedback faster.. Other issues? Thoughts? Question: is using a detailed template a good idea? - No hands for or against the template, but almost all just wanted to "get on with it", didn't care how. Bob Hinden: I'm a little confused - you talked about requirements for implementation for draft standard, but we were just talking about publishing for experimental. Pekka: This is about the basic transitions document that describes configured tunneling. Bob: OK, didn't understand context. === IPv6 Renumbering Procedures - 10 mins, F. Baker - draft-ietf-v6ops-ipv6-renumber-procedure-00.txt - discuss changes, solicit input - GOAL: prepare for WG last call SLIDES: <none submitted?> Fred Baker presented IPv6 Renumbering Procedures. - wg document, few changes - the users may require tools or notifications... - next steps: further review still appreciated (comments to authors or the v6ops list) Erik Nordmark: What are the constraints on consistency of reverse vs forward zones? Rob Austein: I agree it would be good but if someone does make them consistent, it would be the first time in recorded history. Ralph Droms: more difficult than additional steps. There is a problem with authority of owning reverse zone, especially for mobiles roaming to different administrative domain. Erik: Sure, but the site has authority to do this, whether it's an individual host or site. === Statistics from a 6to4 Relay - 5 mins, P. Savola - (no draft) - quick presentation on the usage statistics from a public 6to4 relay - GOAL: give the WG an impression about the traffic on 6to4 relays SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/6to4-stats.pdf> Pekka presented Statistics for a 6to4 Relay. - We (AS1741) have been running public 6to4 relay since Nov 2001 - PC platform, highly programmable - average kbit/s or pps is not too high; 15min estimate typically around 20-100 kbit/s - admin issues: only few users from their own nw (ds / tunneling for the customers, i.e. a bit difficult to justify the service) - no abuse has been reported; haven't detected any DoS attacks (the system can handle a lot of traffic so this is not a problem) - Weird things: MS Windows probing a lot (a Win host sends a proto-41 "probe" to 192.88.99.1) - ICMPv6 Echo Request with Hop Limit 1 - Windows probing - 500000 and growing. Clear raise from Apr 2004 - Some spikes that are difficult to PIN down - 6to4 usage 01/2004: no clear conclusions on the picture - Interesting to note: very low amount of apps at the moment; UDP/DNS actively used by many; ICMP still is an important IPv6 application; - Conclusions: 6to4 is out there but not yet really in an active use (or if it is, it is between 6to4 nodes, not through the relay) Erik Nordmark: were these DoS attacks on relay service, or attacks that went through the relay? Pekka: Through relay. Erik: You have some asymmetry. Are you attracting this traffic over IPv4 or because you're advertising the 2002:: ? Asymmetry - can it tell you something interesting about users and their location? Pekka: We advertise both, but haven't looked into the details. Tony Hain: 6to4 is in active use; I'm using it in the back of the room right now. You're probably missing a sequencing issue. If nodes are behind NAT, they'll use Teredo until they get past NAT. Nodes that are doing it are doing it between each other. Jordi Palet: I totally disagree that there is traffic only between nodes. I use lots of networks and I am surprised that 80% of the time I get access via a 6to4 relay. There are not enough relays to be effective, but it's working. Pekka: You are commenting that 6to4 can be used behind a NAT that does protocol 41 forwarding? Jordi: No, when you attach to network and get public v4 address, you can reach 6to4 relay without configuring anything, depending on OS operating. Pekka: 6to4 anycast relays being advertised but it might. Robert Elz(?): When you look at TCP traffic through 6to4 relays, are connections being initiated by 6to4 hosts, or people trying to contact 6to4 hosts? Pekka: I got a feeling that a significant portion of the traffic is on 6to4 hosts. Rob Austein: I've seen traffic patterns lately. For anything involving bulk transfer of data that I have to sit there and watch, I use ssh over v4, because it's faster than v6. Daemons may use it more. === Tunneling Scenarios Analysis continued - 45 mins, Chairs SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/scenarios-analysis.pdf> Pekka and Jonne continued the tunneling scenarios analysis discussion. Jonne: We came up with a table about which scenarios should be supported. (see slides) Pekka:to reiterate, to get ISPs to deploy something, it has to be very simple. We did same thing for mechanisms that are on the table (see slides). Any questions? Florent Parent: What does secure mean, exactly? Pekka: Good question. We were mainly looking at how the protocol has been specified, and whether it's open to abuse or attacks of mechanism user Florent: The only one that supports user authentication is TSP. Pekka: Authentication applies only to what prefixes you give. Doesn't secure data plane. Also, widely deployed means multiple vendors. Erik Nordmark: notion of authenticated tunneling? Split apart secure thing into finer grain. Pekka: Authenticates the tunnel could be done automatically with some IPsec implementations. Some implementations support transferring v6 over v4-IPsec. Users probably can't deploy that. Erik: I was thinking about notion of sending credentials. Erik: on scenario analysis slide, unmanaged 2 says it doesn't require direct connect. Pekka: nice to have, within ISP site. It would be difficult because you have to cross NATs, so you would have to do unmanaged 1a if it's a strict requirement. Tony Hain: Matrix is good; this should be sent to the list. Solution summary Pekka commented that the summary obtained by combining the matrices. Dave Thaler: I agree with conclusion, but 2nd bullet says require STEP or TSP. Teredo fits as another alternative, but requires private server relay inside ISP. Pekka: in this case (unman 2), Teredo doesn't fulfill simplicity requirement. Fred Templin: What version of ISATAP were you considering? Pekka: version 20. Fred: NAT traversal covered in 20. Pekka: it's covered but doesn't work. Fred: let's make it work. Pekka: The only way to make it work within a site would make it Teredo. They are pretty close in NAT traversal at first, ... Fred: From what you've said, you're looking at a subset at what's in current draft. Dave Thaler: Graph is correct, and I'm happy with it. Questions to WG: Does the proposal about Informational / Experimental make sense? "Does the proposal to publish them as experimental or informational now, describing current implementations, continue work on working group solution at the same time, does this make sense?" Tony Hain: I don't believe we need to go to experimental to go to standards track document. We can replace the documents later. Spencer Dawkins: I was confused earlier in the session, individual drafts match current deployment or contain proposals for additions/enhancements. Jonne: I would personally like to have it documented what is out there now, which might be other drafts besides what's there now. Show of hands - is that acceptable to go to experimental to document what is out there today? For - about 20-30. Against - 3. Rough consensus to go ahead with this proposal. 2nd question: is the analysis going in the right direction? Is it worth pursuing this, write it in draft format and get comments? Yes - 15-20. Against - None. 3rd question: Unmanaged 1a requires Teredo. Is there WG consensus for adopting that? Jordi: I think it's interesting to see all the questions before deciding. Jonne: These are the questions that we have. If you don't like them, we have others. Dave Thaler: It's incomplete because the enterprise scenarios are missing. It's going in the right direction though. Jonne: And you just volunteered to help with enterprise scenarios. Thank you. Question "Is there WG consensus for adapting Teredo?" Erik: We have the lunch menu here, but it doesn't have prices. I don't know what we have to pay to do this. If we do this with 6to4 that's already out there, what's the price tag? Pekka: That's a valid concern that's been reflected in analysis document. We will try to put significant health warnings in that and recommend local relay deployment to mitigate. Jonne: Adopt Teredo means that the WG will work on it further, not just stamp it. Tony Hain: Doing it in this room is probably not the right place. There's enough complication that it should probably be done on the list. Some people don't think it will be possible to get down to one solution. Pekka: If the working group is unanimous about doing everything, then it's a signal to us. Or it can get down to one. Tony: When you take it down to one, what are you giving up? David Kessens: Making the final decision on the mailing list is where it should happen, but we can still see what the feeling of the group is now. Jonne: Yes, it's just informative here. David K: And you might want to start by asking these final questions now, but we can discuss it later on. Jonne: Do we think there is enough basis on the preliminary work to adopt Teredo now? Yes - about 9. No - about 11. Pekka: Seems roughly equal. David K: Who don't want to adopt it - because they first want to have discussion on mailing list? or other reasons? Jonne: Because it's too early? - 1 Or because there are other reasons? - 0 Erik: Hard to extract that info from room without having people state opinions. My opinion is that I don't have the prices on the menu. Practically, it might be the right thing to do here, but do we know that we can minimize risk of partitioning IPv6 network? Tony: I believe we do need to know the price, but we could start down the path and back out with Historical. Jonne: Let's take it to the list. Pekka: working group consensus on teredo? yes - 9 (no not taken). David K: I don't think we should ask this now, let's go on. Shawn Ch( ? from Mitre: we are looking at transition mechanisms for US government. Literature is not very extensive with regard to cost and complexity as Erik said. I would request more time to go through costs of solutions as suggested. Pekka: After going through this, I think we have to pay the price anyway, but just later? I have a gut feeling that we will just be delaying the paying up. Jonne: I think it's fair to ask of the working group whether we need one solution or more Pekka: It could be a hybrid Jordi: I want to insist that when you are moving between networks, one solution may not be enough. David K: ADs certainly have preference for a minimum amount of solutions. There's always a big cost to implement multiple solutions, so if we can minimize that, it's better. Jordi: We are putting on the table 4 solutions, but maybe it's 6 or 7. There may not be a real life solution for all situations. That's what I experience when traveling. Jonne: One solution would be one, not all four. Jordi: If you give me one solutions that survives any network, that's perfect. But that would be difficult to happen. Fred: If the question is must we have one solution, then I am cautious. but can we find one solution, I would say yes. Someone yelled out from the floor: "Do it on the list!" Jonne: Now you have seen the questions, and you can talk about it at home. Question: Do we have someone signed up to do the cost analysis? At least two people have said what's it going to cost us. Jonne:If there is someone who asked that would be interested in preparing this,..Erik, don't go away... Erik: We should do it in parallel; you can't come up with a quick answer. Keep the cost question in the back of our minds, and have sensible deployment advice for relays. Jonne: I agree and we can discuss the details on the list. === Quarantine Security Model - 10 mins, S. Kondo - draft-kondo-quarantine-overview-00.txt - quick overview of a possible security model for IPv6 - GOAL: introduce the issue, to be fully discussed in security area SLIDES: <http://www.6bone.net/v6ops/minutes/IETF-59-Seoul/quarantine-model.pdf> Satoshi Kondo presented a Quarantine Security Model. In the real world when we deploy IPv6, we are facing conflict with existing firewalls or border defense models. Usually the admin doesn't care about security on v6, or just copies rules from IPv4 forwarding to IPv6. But we are dropping some of the benefits of IPv6 technologies. Three-step quarantine model described on 3rd slide. Requests network entity to check security level. Draft describes high level overview, but does not specify protocols or technologies. I have to do an experimental implementation to check whether the model really works in the real world. Let's discuss on mailing list or you can send email to give your comments. Jordi Palet: It seems the idea is quite close to what I presented on Monday. We have been working together during IETF and we believe there is a lot of commonalities of what we're doing. It's an operational problem of IPv6 deployment, so the analysis work should be done in this WG. We would like to create a small design team to work on this. It's interesting to work on and necessary for deployment. Pekka: since this is moving toward the protocol side instead of analysis side, we need to see how the proposals go forward, but I encourage you to continue working on this. === Meeting adjourned. -end |