=======================================
IPv6 Operations (v6ops) Interim Meeting
18-19 September 2002
Wind River, Sunnyvale, CA
======
CHAIRS
Jun-Ichiro itojun Hagino <itojun@iijlab.net>
Margaret Wasserman <mrw@windriver.com>
Attendance was 85 people.
Margaret chaired the meeting, and various folks contributed notes for the minutes which were edited by Bob Fink.
===========================
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 web site: <http://www.6bone.net/v6ops/>
v6ops Project Status: <http://www.6bone.net/v6ops/v6ops_project-status.html>
======
Agenda
-------------------------
Wednesday, September 18th
Introduction and Agenda Bashing - Chairs
- Review v6ops Charter, Priorities, Plans and Processes -- Margaret (2 hrs)
http://www.ietf.org/html.charters/v6ops-charter.html
- Overall mission of the WG
- Review Task List & Milestones
- Reach consensus on goals and priorities
- Discuss plans and processes to reach those goals
- Survey of IPv4 Addresses in IETF Standards -- Chairs (15 min)
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv4survey-02.txt
- Current status and open issues
- Accept as a WG work item?
- Transition Mechanisms Update -- Chairs (15 min)
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-v2-00.txt
- Current status and open issues
- Accept as a WG work item?
- Security Implications of Mixed IPv4/IPv6 Networks -- Itojun (1 hour)
http://www.ietf.org/internet-drafts/draft-itojun-v6ops-v4mapped-harmful-00.txt
- Description of NTT DSL Network Deployment -- Shin Miyakawa (20 min)
- Discussion/Status of Deployment Scenario/Solutions Work
http://www.ietf.org/internet-drafts/draft-soininen-ngtrans-3gpp-cases-00.txt
http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition-01.txt
http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-unmanscope-01.txt
http://www.ietf.org/internet-drafts/draft-huitema-ngtrans-unmaneval-00.txt
http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-00.txt
- Introduction and Re-Focus -- Margaret (30 min)
- Cellular Networks -- Jonne Soininen (30 min)
- ISP Networks -- Cleve Mickles (30 min)
- Unmanaged Network -- Christian Huitema (30 minutes)
- Enterprise Networks -- Yanick Pouffary (30 min)
------------------------
Thursday, September 19th
- Goals of Breakout Sessions and Formation of Groups -- Margaret (30 min)
- Deployment Solution Breakouts (2-1/2 hours)
- Cellular Networks -- Jonne Soininen
- ISP Networks -- Cleve Mickles
- Unmanaged Networks -- Christian Huitema
- Enterprise Networks -- Yanick Pouffary
- Breakout Reports and Next Steps
- Cellular Networks -- Jonne Soininen (20 min)
- ISP Networks -- Cleve Mickles (20 min)
- Unmanaged Networks -- Christian Huitema (20 min)
- Enterprise Networks -- Yanick Pouffary (20 min)
---
New Work/Discussions Related to the v6ops Charter:
- Operational Issues with IPv6 Addrconf & DHCPv6 -- Ralph Droms (20 min)
- Unidentified issues in IPv6 deployment/operation -- Itojun (30 min)
http://www.ietf.org/internet-drafts/draft-itojun-jinmei-ipv6-issues-00.txt
Wrap-up and Review of Action Items -- Chairs (30 min)
==============
Meeting Report - Day 1
Wednesday, September 18th
------------------------------------------
Introduction and Agenda Bashing - Margaret
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/Intro-Agenda.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/Intro-Agenda.ppt>
Margaret covered meeting arrangement details. The group expressed thanks to Wind River for hosting this meeting and providing food, meeting rooms, a/v and network equipment and various services.
There were no changes to the agenda above.
----------------------------------------------------------------
Review v6ops Charter, Priorities, Plans and Processes -- Margaret
<http://www.ietf.org/html.charters/v6ops-charter.html>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/Charter-Priorities.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/Charter-Priorities.ppt>
Margaret presented the charter of v6ops as it was accepted by the IESG and discussion on the v6ops list.
- Overall mission of the WG
- Review Task List & Milestones
- Reach consensus on goals and priorities
- Discuss plans and processes to reach those goals
Need to develop guidelines for operation of shared IPv4/IPv6 net
Need to provide guidance for deployment of IPv6 nets
Need to agree on tasks
Ralph Droms asked if identifying standards work meant just IETF.
Margaret thought it could mean others. E.g., 3gpp operators could bring issues that dictate communication with other standards groups.
Q: What does 'operators' mean, its a loaded term. Margaret replied that it meant people deploying IPv6 in enterprises, homes, ISPs, as opposed to implementors.
Jim Bound noted that implementors get bug reports from operators.
Fred Templin asked if operational included efficiency and performance. Margaret replied that she thinks it includes all of these.
Jim Bound noted that the term 'user' is overloaded but it is necessary for a while. Margaret replied that we will come up with subcategories later but not worth time defining a vocabulary at this time.
Jim Bound said we often have conversations with folks deploying IPv6. The DoD is a large deployer and though we can't talk about everything, we can speak about some of what they are experiencing.
Randy asked that folks not refer to others, let them speak for themselves.
Thomas Narten clarified that it is not generally useful when one party speaks for others.
Jim Bound asked if this meant that we can't talk of our experiences?
Randy noted that one should speak in 1st person.
Thomas noted that you can't draw hard fast rules, but keep it in your frame of reference.
Margaret hoped that Jim could get DoD folks to talk here.
Bob Hinden noted that vendors have contact with many more people than might come to these meeting, thus it is important we can speak of this.
-
Task (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."
On working with others on, Randy noted that DNSOPS is reorganizing to deal with IPv6 issues.
Several folk mentioned that with SIP, conversations are under way to deal with IPv6. More is needed and chairs will talk with IESG about this to see that issues are being resolved.
Jim Bound, what about SNMP/management/MIBs areas. Margaret replied that MIB work is underway.
There was some discussion about CableLabs/DOCSIS, which will require wait and see.
Alain noted the topology discovery issue.
-
Task (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."
Discussion: v6ops is tasked with informing ipv6 about standards to be revised and developed; v6ops is *not* tasked with developing new standards.
Christian, some issues are more for users and some for developers. Is this all in this wg. Margaret replied that it was not her job to determine this.
- Determine solutions or workarounds
- Identify standards work needed in other groups
- Initiate work with other groups
- Ask IPv6 operators for experiences
-
Task (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."
Hesham asked if this included education for apps developers? Margaret replied yes it will. Tony Hain wondered if this should this be in this wg.
On Nessers draft:
Marc Blanchet has sent comments that aren't answered yet.
Itojun, multiple books underway on conversion to IPv6.
Margaret asked if there are specific issues common to using IPv6. Maybe we should write some BCPs to help.
Itojun, we may need to write about scoped addresses and traps developers can fall into.
-
Task (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."
Christian, two ways to approach this issue, one of which is reviewing existing security docs for issues. Itojun noted he will do this.
Work on secure ND progressing? Thomas Narten replied yes.
-
Task (5) "Publish Informational or BCP RFCs that provide viable 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. "
Christian noted that while v6ops is talking over from ngtrans, many drafts are not being carried over or their solutions addressed.
Margaret noted that there were 19 open projects underway at ngtrans.
Randy commented he can shut down ngtrans immediately and keep the mail list open. He thinks that as some things will be in limbo while waiting for further v6ops results that allow projects to be pulled into v6ops.
Alain asked for guidance on what could be discussed on the ngtrans list.
Margaret noted that we don't want a plethora of mechanisms that have problems.
Hesham asked if there is protocol design in v6op. Margaret replied yes (Task 7), but only as needed and with AD approval.
Tony Hain asked, related to timing of shutting down ngtrans, if drafts could be refreshed. Randy replied yes.
Fred Templin thought that people might drop off from the ngtrans list and will there be a moderator? Should we combine the lists? Randy replied no as it is too difficult to have too many conversations.
Jim Bound stated that there is an issue that we never have had an answer as why ngtrans will die when there has been support by wg folk, chairs, some ADs. Why is this being done.
Margaret said she could understand this concern.
Harald Alvestrand stated that there was discussion on whether to recharter or start new group at the IESG. That we need to focus on this meeting and have this discussion in another forum. Jim agrees if we really do address it.
Randy noted that if you read the original messages about v6ops it was explicit about closing ngtrans.
Bob Hinden shared some of the concern about ngtrans closing. WG items generally get sent somewhere else if they close, and this isn't happening with ngtrans. Harald noted that his point was taken.
Alain, suggests to not shut it down now, but put it into sleep mode until we decide what to do with drafts.
Margaret noted that we don't decide that here, but will address this outside of this meeting.
-
Task (6) "Assume responsibility for advancing the basic IPv6 transition mechanism RFCs along the standards track, if their applicability to common deployment solutions 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."
Christian noted that he had a problem with a charter that says only work identified in it can exist. Margaret said that was not what was intended. She pointed out that the correct intention is there but out of order (swap task 6 and 7?)
Jim Bound commented that two years ago 6to4 wouldn't have made it to v6ops, so what differentiates what comes over and what does not?
Margaret replied that ideally we might have done things differently. RFCs are in this draft as we can pull in things needed, but non-RFCs will time out and go away. We need to take action to take RFCs away.
Jim asked why is there a problem with getting IESG to change charter to be clear on this.
Margaret replied that the chairs will address this with the IESG.
Hesham commented that it is too early to tell if the world cares. Tony Hain replied that this was wrong, many care.
Alain noted that if wg folk needed to tweak charter, it should be done. By giving some of the names of standards the v6ops charter gives the impression some are blessed and some are cursed. Need a better spin.
What about 6over4? It's in v6 wg as it is a v6 over link layer. Dave Thaler replied that it should be under same constraints as other ngtrans mechanisms. Steve Deering noted that 6over4 can be classified under two axis, but this group can comment to v6 wg on what you think should be done with it. But leave where is for now.
Randy wants to get the main body of work done in v6ops and let this decide what fits in v6op, or gets accepted. Jim Bound agreed with Randy.
-
Task (7) "Identify open operational or security issues with the deployment solutions 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 deployment issues that can be solved using widely-applicable transition mechanisms, such as dual-stack, tunneling or translation.
If the satisfactory resolution of a deployment 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."
Ralph Droms asked if this will run into process issues; will this identify issues already under discussion by v6wg. Is this a problem? Margaret replied that we will find some things that are problems standardized in other wgs, and we will write a doc to give input and state problem, but won't write standards for other areas.
Ralph Droms asked if other issues are identified now?
Jim Bound asked how do we come up with this list of additional issues to resolve.
Margaret repliked that is the purpose of this meeting and this group.
Fred asked if mention of "operational and security issues and deployment solutions" could be reworded to "operational and security issues" throughout.? Marg, doesn't know and will ask.
Jim Bound, why does this have to done by October 1st? Why can't we fix a charter. Margaret replied that she didn't know, but will find out.
Tony asked that if we can't affect the charter, why discuss it? Randy commented not to waste valuable time here to discuss this as it can be done on list.
Jim Bound, in response to Randy, noted that we are trying to understand why and what before we go forward. Christian, not productive to continue this discussion. Agreed.
-
Jim Bound asked why is there such pressure to publish the scoping drafts by October 1. Margaret said
she didn't have a good reason for the completion date.
-
Margaret wants group to realize the primary purpose of the wg is not standardization, rather advocacy and education of what needs to be done for ipv6 transition.
---
Understanding WG Process
Discussion then moved from the what to the how; What are the procedures? That is, the process to be used in the WG.
How will we accomplish these goals?
Important to understanding the WG process, which may be slightly different
from that of other working groups.
Try to reach common understanding of our processes to promote
efficiency, consistency, keep chairs honest, separate discussions
about technical issues and process
Goals of WG process
Follow the spirit of IETF process, not just the letter;
openness and fairness
Steps in process
1. Submission - may be drafts or just ideas via the mailing list.
2. Author Refinement
3. WG Acceptance
Does it fit within charter?
Significant support from the working group, not just quiet
acceptance.
Be accepted as work item by a rough consensus of WG.
Have corresponding goals/milestones in the charter;
approved by area director
4. Editor Selection - almost always will be among those who wrote
the original document
5. WG Refinement - Updated by WG consensus
6. WG Last Call - supported by significant number of people, including
experts in area. In other words, silence is not consent.
Jim asked if these are wg drafts? Margaret replied that personal drafts are not covered by this.
Thomas Narten noted that another way to raise the bar is by having several folks (other than chairs and authors) that will support making a draft a wg item.
Margaret noted that the proposed WG acceptance slide actually covered Thomas' point.
Structure discussion
Rob Austein noted the need to have good pre-content to avoid language problems.
At face-to-face meetings, will try to use structured discussion slides.
Consensus was to use slides to help with difficulty with language among participants.
Tools and Resources
Mailing list and Archive
Will have additional Web site
Anything else?
Alain Durand noted that he thought there were v6ops email problems? Randy said there wasn't and explained why.
Margaret welcomed everyone to the new v6ops working group.
--------------------------------------
Transition Mechanisms Update -- Itojun
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-v2-00.txt>
SLIDES
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/trans-mech.txt>
Itojun-san presented a list of specific comments on the draft recommending changed to the nasic Transition Mechanism RFC from the mailing list.
When asked if the group wants to work on this draft, no one was against it, many were for it, a few don't care.
The result was the same for it becoming a wg project.
The question will now be taken to the mailing list.
------------------------------------------------------
Survey of IPv4 Addresses in IETF Standards -- Margaret
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv4survey-02.txt>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/Survey-of-IPv4-Addrs.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/Survey-of-IPv4-Addrs.ppt>
Margaret gave an overview of the Phil Nesser IPv4 Survey draft:
Survey of IPv4 Addresses in IETF Standards - Author is Phil Nesser
He believes it needs further review and feedback
Are there people willing to put significant time into this and review?
Show of hands - yes.
Should we accept as a WG work item
Show of hands - yes
This document also satisfies the requirements in the charter.
Many folks (17) agreed to participate in fixing parts of this Nesser draft that relates to their expertise.
Margaret commented that the ID needs some organization/management to assure review. Itojun commented on the need for ietf list solicitation.
Q: should this draft be broken into parts/layers, as it is unwieldy. Margaret said possibly by area, but need to talk with Phil Nesser.
-----------------------------------------------------------
Security Implications of Mixed IPv4/IPv6 Networks -- Itojun
<http://www.ietf.org/internet-drafts/draft-itojun-v6ops-v4mapped-harmful-00.txt>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/ipv4-mapped.txt>
Itojun-san gave a summary of his Internet Draft. Rob Autstein pointed out that many of the mapped address issues are already known to be IPv4-only issues, and DNS servers must already defend against those
issues. Christian pointed out that the overloading - using mapped addresses for the API - can be filtered so that a stack drops any inbound datagrams with a mapped address.
Itojun-san suggested we should use API version, and deprecate SIIT.
Jim Bound said Erik Nordmark should be given a chance to fix SIIT.
Itojun-san presented some specific suggestions (see draft).
Harald commented that there are 2 issues: what goes on with dual stack using v4-mapped. The other is what goes on in a machine that implements SIIT.
Jim Bound said it's too late to turn on IPV6_V6ONLY option by default.
Rob Austein pointed out some care must be taken when dropping an AAAA record with a mapped address.
Jim Bound asked where implementation suggestions will go - in a document? Itojun-san said yes it will go into a document. Jim said that these recommendations will affect deployed applications. Jim doesn't want to have anything that says RFC2553 is not to be followed.
Alain Durand says it is way too late in the game to change the default behavior.
Much additional discussion about security issues of using mapped addresses in the API.
There was rough consensus (except for Itojun-san) that problems with mapped addresses have been resolved.
Itojun then presented on more general security issues (
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/security-implications.txt>
Itojun-san argued we need something better than firewalls for leaf devices; firewalls will stifle deployment of point-to-point applications.
Steve Deering pointed out that simply saying "security" is not a sufficiently precise definition for a goal.
Tony Hain suggested that the v6ops WG role should be to suggest that "security is lacking" and leave the revision of specifications to other WGs.
Margaret observed that v6ops WG charter is to explore security in IPv4-IPv6 networks, not the general problem of IPv6 security.
Itojun-san gave a list of more specific security issues related to IPv6-IPv4 in parallel (see draft-itojun-ipv6-transition-abuse-00.txt, [now timed out]).
Steve Deering pointed out that IPv6 is not more dangerous than IPv4.
Randy Bush asked if there might be specific problems with IPvx routing information being carried in IPvy routing
protocols?
Dave Thaler said there is work in security for routing protocols going on in the IETF.
Jim Bound said operation area should generate requirement for public key infrastructure in IPv6.
Randy Bush said IESG is asking that we watch for vulnerabilities introduced by transition mechanisms.
Rob Austein understood desire to remove firewall but deemed it unlikely as it's been there since before global addresses.
Steve Deering asked if routing keying static, i.e., is lack of KD a show stopper, is Itojun saying global key is needed?
Christian Huitema commented that all of Itojun's points are valid, but should we not review each standard to see what it's problems are (as opposed to redesigning everything).
Randy noted that he wants security considerations addressed.
Dave Thaler, agree that using IPsec not enough. Agrees routing protocols need updating for security but it is going on. This group should address security problems/issues.
Jim Bound agreed that we need a document of things to be aware of, but that IPsec is often not enough. Need PK exchange.
Rob noted that identifying security issues is important, and that he is worried about unexpected interactions, that it is important to work on this.
Itojun commented that scoped addresses need to be checked. Jim B, are we focused on transition? How does this relate to scoped addresses?
Jim Bound asked if v6ops will be working on security issues not involved with transition. Margaret said yes.
----------------------------------------------------------
Description of NTT DSL Network Deployment -- Shin Miyakawa
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/ADSL-NTT.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/ADSL-NTT.ppt>
Shin Miyakawa presented a description of the NTT ADSL dual stack deployment. He wants to make this a wg draft to get support for their approach to DSL service from others.
Margaret asked if this would fit in the ISP scenarios document. Miyakawa-san said yes, but the document might be appropriate as a stand-alone document as it is a complete deployment specification.
Bob Hinden wants the published document to be clearly labelled as a "recommendation" not a standard (will be published as Informational).
Itojun-san pointed out that handing document to v6ops WG implies changing change control to WG; Miyakawa-san agreed that he could agree - but that the original is an NTT document as a service specification. He will wait to see the English translation to see if it is appropriate for an ID.
-----------------------------------------------------------------------------
Discussion/Status of Deployment Scenario/Solutions Work -- Margaret Wasserman
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/Deployment-Intro.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/Deployment-Intro.ppt>
Margaret then introduced the discussion and Status of Deployment Scenario/Solutions Work.
Purpose - provide viable solutions in common network environments
serve as useful guides to network operators
Four deployment teams
Cellular Networks - Jonne Soininen
ISP Networks - Cleveland Mickles
Unmanaged Networks - Christian Huitema
Enterprise Networks - Yanick Pouffary
Two documents each - Scenarios Documents and Analysis/Solutions Documents
The documents should help network operators.
Will use appropriate terminology,
focus on general approaches that will work.
-----------------------------------
Cellular Networks -- Jonne Soininen
Jonne first presented a status report of the 3GPP work, and then the "Transition Scenarios for 3GPP Networks" ID.
<http://www.ietf.org/internet-drafts/draft-soininen-ngtrans-3gpp-cases-00.txt>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/3gpp-design-team.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/3gpp-design-team.ppt>
This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e. General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet. GPRS network internal transition scenarios, i.e. between different GPRS elements in the network, are out of scope of this document.
Jonne then presented an overview of the "IPv6 Transition Solutions for 3GPP Networks" ID.
<http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition-01.txt>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/3gpp-design-team.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/3gpp-design-team.ppt>
This document describes making the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed.
Randy Bush commented that he thought there were scenario docs and techniques for addressing the scenarios. The two 3GPP drafts didn't seem to follow this approach.
Alain Durand noted that each team used a different approach.
Randy noted that he is trying to separate environments and what is needed, from solutions.
Jim Bound asked if 3GPP2 is part of this effort. Jonne said no.
Hesham noted that 3GPP2 hasn't defined how to do v6 at all, so hard to do this yet.
Jonne commented that he doesn't think it should be combined.
Hesham stated that there were significant difference between the two.
Margaret saw no reason we don't have separate drafts for 3GPP and 3GPP2.
Margaret asked if the scenarios ID should be a wg item? But first, who is willing to work on draft. There was good support for making the scenarios ID a wg item, none against. Margaret will take this to the list for final approval.
-----------------------------
ISP Networks -- Cleve Mickles
<http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-01.txt>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/isp-cases.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/isp-cases.ppt>
Cleve Mickles presented an overview of the ISP design team and of the "Transition Scenarios for ISP Networks" ID.
Define the "Problem Set" of Scenarios
CORE/Backbone
Broadband Hybrid Fiber Coax / Cable
Broadband DSL
Narrowband Dialup
Ethernet to the Home/Home Networking
Internet Exchange Points
Security(detection & prevention)
Network Management
Provide solutions/analysis in a companion document
Team makeup:
CORE Backbone
Vijay Gill
Jun-ichiro itojun Hagino
DSL
Vladimir Ksinant
Gerard Gastaud
Dialup Networks
Shin Miyakawa
Cleveland Mickles
Cable / HFC
Aidan Williams
InterExchange (IX)
Alain BAUDOT
Marc Blanchet
The scope of the "Transition Scenarios for ISP Networks" document is to cover the major topics ISPs must consider in building and running their IP networks. The document will include sections on Core backbone networks, Broadband DSL networks, Broadband HFC Cable networks, Narrowband Dialup networks, and Ethernet to the home networking. The document will also identify Security and Network Management concerns which in some cases will be common to all as well some areas that may be unique to the particular service.
Although the Optical core is important in today's networks, that layer is generally transparent to the IP layer except in a few special cases where ISPs have allowed the IP core to be aware of the optical layer underneath. Hence, this draft does not include further optical considerations.
Each scenario will discuss issues related to network topology, network hardware, routing, policing, security, network management, configuration and host gear.
Cleve noted that he would like to have all sections filled in by IETF55 (Atlanta). Only DSL exists now.
Itojun asked if we need to go into as much detail for DSL? Cleve replied that this was just a starting point to get comments.
Some felt that there was too much of how DSL works as opposed to how it's deployed.
Rob Austein commented that though it may not need quite that level of detail, but that it exposed good issues, like tunneling, VoIP.
--------------------------------------
Unmanaged Network -- Christian Huitema
<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-unmanscope-01.txt>
<http://www.ietf.org/internet-drafts/draft-huitema-ngtrans-unmaneval-00.txt>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/unman-eval.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/unman-eval.ppt>
Christian Huitema gave an overview of the unmanaged network design team effort. They are working on two docs: scenarios and analysis.
Alain Durand asked if unmanaged network should be responsible for IPv4-IPv6 translation (e.g., IPv4-only host talking to new IPv6-only printer). Christian answered "yes".
Hesham asked if the scope is home networks only or any unmanaged network, because security requirements may be different in different scenarios. Rob Austein suggested that ad hoc networks are different from unmanaged
networks.
Jim Bound gave other examples of military networks that may fit under "unmanaged networks". Consensus was to leave ad hoc networks out of scope for this design team.
Christian explained that the design team has vacillated between picking just enough transition mechanisms to do the job and examining every transition mechanism for applicability. The interesting aspect of the transition mechanisms is the way in which they interact with DNS.
Miyakawa-san asked for clarification about whether Unmanaged might touch ISP at the definition of the CPE. Margaret acknowledged that the various initiatives will touch; the CPE is an example.
Dave Thaler pointed out that the Unmanaged document looks at the several problems in a different way and suggested it might be a good template for other documents.
Hesham asked if this include unmanaged nets larger than home? Christian replied that it should include larger but may require other drafts.
Rob Austein noted that the ad hoc case has different characteristics.
Jim Bound asked if the small nets in defense networks should be included in Enterprise or here?
Margaret asked if they should be covered atl all, given our work load.
Bob Hinden commented that enterprise networks don't cover this, in his opinion.
Randy stated that military is not what we are covering.
Margaret noted that maybe the name is not right, but can address this later.
Jim Bound wants it noted in minutes that ad hoc nets came up and were not resolved.
Q: do we want v6 to v4 connectivity when we have a new device, I don't.
Rob Austein commented that he pushed v4 only clients talking to v6 only servers. This is non-contentious as we need solution that can be used elsewhere. If you don't buy assumption, we don't need to deal with unupgradable clients that external connectivity no important.
Alain Durand asked if the team was looking at NAT64? Rob noted that there was disagreement as to whether any of the NATxxx work, so need more idea on what requirements are.
Christian stated that it is not clear what way to look at possible solutions for naming and connectivity mechanisms.
Christian wants to spend breakout time evaluating mechanisms for scenarios. Are close to consensus on scenarios.
Shin Miyakawa asked how to handle overlapping mechanisms. Margaret replied that we will have to deal with this as it comes up.
Dave Thaler noted that UNMAN addresses connectivity, naming, apps. other scenario efforts don't break it down this way and maybe they should for consistency.
Margaret askedd if there was support for the UNMAN scenario draft to become a WG item. Fair sized number of folks said they would work on it. There was consensus, with no dissent, to accept as wg item.
--------------------------------------
Enterprise Networks -- Yanick Pouffary
<http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-00.txt>
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/enterprise-scenarios.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/enterprise-scenarios.ppt>
Yanick Pouffary described the current makeup and state of the Enterprise design team. The effort only began on 20 August. Yannick noted that these are *actively managed* networks. Also, there may be multiple independent networks and mobile IP users.
Members:
- Yanick Pouffary - Hewlett Packard - Chair
- Jim Bound - Hewlett Packard Doc Editor
- Yurie Rich - Native6 Group
- Marc Blanchet - Viagenie
- Tony Hain - Cisco - NGtrans wg co-chair
- Paul Gilbert - Cisco
- Scott Hahn - Intel
- Margaret Wasserman - Wind River v6ops wg co-chair
- Jason Goldschmidt - Sun Microsystems
- Mathew Lehman - Microsoft
- Aldrin Isaac - Bloomberg
Goals:
- Focus on defining:
Set of technology scenarios
Set of transition mechanisms needed by different scenarios
Set of tools needed for IPv6 deployment within the Enterprise
- Focus on defining a template for
How existing / new transition mechanisms and tools could be used
in the Enterprise network scenario
Non Goals:
- This document will not declare specific transition mechanisms or tools for the Enterprise
An Enterprise Network is:
- A user network connected to an ISP actively managed by the users of that network,
and has multiple independent networks within the Enterprise.
- May also have mobile IP users accessing Network within the Enterprise
or from the public Internet into the Enterprise
Enterprise can be
- A large business (Manufacturing, Financial, Government)
- A small office business (e.g. Law Firm, Stock Brokerage)
Strategy
Our initial consensus strategy is to discuss the scenarios first
Then deal with the technical and transitional details below the scenarios
The following scenarios list is not complete
Randy asked who on the team was actually managing a network. At least 3 were and several working with users that are.
Issues raised that case scenarios have been looked at, not general requirements.
Alain Durand commented that the scenarios are focusing on net topology. Topology wise its a small problem to transition, rather the difficult problem is a coporate management style.
Christian Huitema suggested that the terminology "mobile users" should be used rather than specifying the "mobile
IP" solution.
It was noted that "Managed" and "independent" networks implies there may be "submanagement" or "scoped management" issues.
-------
adjourned day 1
==============
Meeting Report - Day 2
Thursday, September 19th
------------------------------------------
Goals of Breakout Sessions and Formation of Groups -- Margaret
Margaret discussed the purpose of the 2.5 hour breakout sessions in the 4 areas.
Intensive review of documents
Expand on the documents
Align documents
Lead to another cycle of documents
The afternoon plan is to come back with breakout reports. She would like to see main points and any directional shifts.
Later this afternoon there are scheduled presentations on:
DHCPv6 - Ralph Droms
Unidentified and/or unresolved issues for v6 - Itojun
There were no comments on the agenda so the meeting adjourned for the breakout sessions to begin.
-------------------------------
Breakout Reports and Next Steps
After the breakout sessions and lunch, the general v6ops meeting continued to listen to the reports/summaries of the breakout sessions.
-----------------------------------
Cellular Networks -- Jonne Soininen
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/3gpp-breakout-report.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/3gpp-breakout-report.ppt>
Jonne gave the report of the Cellular/3GPP breakout session (see slides above).
Jonne noted that though all the scenarios were up for discussion, the discussion concentrated mainly on a few specific scenarios:
- IPv4 UE connecting to an IPv4 node through an IPv6 network
- IPv6 UE connecting to an IPv4 node
- IPv4 UE connecting to an IPv6 node
- UE connecting to a node in an IPv4 network through IMS
When IPv4 over IPv6 was discussed it was thought that this might be a limited case and thus it was concluded that not use much energy should be spent on this case
-
IMS UE connecting to a IPv4 SIP node
Not as general as the normal Ipv6 only node scenario
(GPRS scenario 4)
SIP-ALG vs, e.g., DNS-ALG
This two cases exist:
SIP ALG and media flow translation in the same box
SIP ALG and media flow translation in the separate box
(There needs to be a protocol between the two entities}
Next steps:
more text to clear up the analysis
(need to clarify how the flow really goes)
protocol between SIP ALG - media flow translation
(need to gather requirements for the protocol)
(check if there is work that is relevant to see if fits}
-
GRPS IPv6 only case
There was a long discussion of the problems of NAT-PT
DNS ALG - breaks DNSSEC
scalability issues - how to use multiple NATs
NAT64 vs NAT-PT discussion
having DNS ALG in DNS server in the network
having A record support in the end-node itself
DNS-ALG in end-node
trust models
trusting operator DNS server
not trusting operator infrastructure
hybrid model
Discussion:
Christian said that the trust model change is bad - it's not the main topic of 3G, it is a common problem.
Margaret wondered if the NAT-PT issue applies to other uses. She was unsure.
Margaret noted that there was no real difference in scalability.
Rob commented that the DNSSEC issue needs to be explored further.
Itojun asked if this was responsibility of dnsext, dnsop or v6ops?
Rob was not sure, and he volunteered to take this on before Atlanta.
Alain felt the need to be quick as IPv6 only devices will start to appear soon.
-----------------------------
ISP Networks -- Cleve Mickles
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/isp-breakout-report.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/isp-breakout-report.ppt>
Cleve Mickles gave the report of the ISP Networks breakout session (see slides above).
Additional work areas were added
wireless
Broadband Ethernet (Ethernet in the home?)
Infrastructure Services
e.g., data center
There was an outline clarification
Add multicast
Add multihoming/managed access
Security
Traffic engineering
It was felt that DSL has too much detail.
L2 discussion not necessary
Other issues send to list
Agreement that the draft represents the majority of ISP networks
Itojun presentated examples of IPv6 ISPs in Japan
this provides input for the analysis draft
Discussion:
It was asked if wireless should be kept or moved as it was felt that was still open question.
---------------------------------------
Unmanaged Networks -- Christian Huitema
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/unman-breakout.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/unman-breakout.ppt>
Christian gave the report of the Unmanaged Network breakout (see slides above).
This group is much further along than the other groups.
Their scenarios are essentially done and they are already discussing solutions.
They considered two things:
List of issues
List of other work related to the problems
Issues
- Different topologies (routers, multiple routers)
multihousing unit, shared subnet, multiple subnets
shared wireless (single/multiple isp, security)
fixed ethernet (impacts, naming, discovery)
- Prefix delegation
- Use of tunnel broker for case A
- Monitoring requirements
- SIIT issue: only layer 3, support for port mapping, v4 to v6 support?
- Registration of new appliances, notification, device capability, security (application vs network)
- Security: is the inside really safer?
- What support do we need for "legacy" ipv4:
ipv4 only, local connectivity to local ipv6, remote ipv6 (legacy apps vs new apps)
- Solutions for name resolution LLMNR, DDNS, etc.
- Mobility, roaming guest in the house, call back home
Three issues for another team:
Ad hoc networks
Personal area network
Mobile networks
A matrix of considerations related to desired name resolution was presented
e.g., v4 only, v6 only, v4/v6 (see slides above)
The problems with NAT-PT was determined to be, coming from a dual stack host:
V4(B) or V6 translation
V6(B) or V4 translation
Recommendations for naming were:
- Make the IPv6 host dual stack
IPv6 host will also look for A record
Solves the "litteral URL" issue
- If not dual stack, use "local SIIT" (BIA)
Need to reserve of configure a SIIT prefix
Or just forego interoperability with IPv4
- Leave the AAAA requests alone
Since the host will look for A if needed
Results of the evaluation of use of dual-stack or SIIT showed no solution for going from v4-only to v6-only.
Jim Bound asked why are you digging this far. Christian replied that we're already doing analysis document, not scoping document.
Thomas Narten asked how can you talk to IPv4? Christian replied that he is talking about naming, That there wou;d be header translation in network somewhere.
More naming issues recommendations:
- IPv4 only host need some translation
Need a DNS ALG
Itojun asked, regarding naming recommendation, which node needs changing? Christian replied that the dualstack, or ipv6only would.
- But translating A request is harmful to dual stack hosts
- Suggestions
Use two different DNS services, based on protocol type, port numbers or names
Use a special address range for translated addresses
Other naming issues:
- Configuration
Both DHCP option and reserved address work
- Acquiring autoconfigured addresses
Gateway receive request for local name
Gateway issues LLMNR request, cache the results
Returns AAAA reply
Rob noted that, regarding acquiring autoconfigured addresses, that the solution conflicts with dnsext recommendation on LLMNR (TTL and such). Tony asked if it is the name leak problem? Rob said yes.
- Advantage: stateless
Multiple link issues
- Some medias are hard to "bridge"
Bluetooth, IEEE 1394, possibly power line
- Request to support two topologies
Star: Every link goes to the router
Mesh: "routers" connected to the home network
Connectivity issues:
- Two options for mesh topology
Multi-link subnet (single /64)
Analogous to "proxy ARP"
Need a detailed specification
Configured subnet prefixes
Require multiple /64 prefixes
Require a prefix allocation specification
Christian noted there was no solution for mesh topology for now.
- Star topology
Simple solutions, e.g. allocation of subnet # by the gateway + use of classic RS/RA
Naming issues in a star topology
- Configuration
Both DHCP and reserved address work
- LLMNR for resolving AAAA
Gateway must repeat the query on multiple links
Naming issues in a mesh network:
- Configuring the DNS server
The "reserved address" approach just works.
DHCP requires a set of DHCP proxies
- Options for using LLMNR
LLMNR cache + relays at routers
-Or, "right scope" multicast
Subnet scope if "multi-link subnet"
Or, site local scope if "configured routers"
- Multicast issue appear in LLMNR, but also duplicate address detection
Dave Thaler asked about dynamic dns. - (lost answer)
Margaret asked how do you discover addr? Rob said that dynamic update needs to be explored.
A comment was made that scope really is a domain? Is it really a DNS domain/scope?
Fred Templin commented that the meshed network case has a lot of overlap with adhoc network space.
Discussion:
[embedded in presentation above]
--------------------------------------
Enterprise Networks -- Yanick Pouffary
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/enterprise-breakout-report.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/enterprise-breakout-report.ppt>
Yanick gave the report from the Enterprise Network breakout (see slides above).
Plan of action
- 1- Establish drivers that would make an enterprise interested in IPv6 (Migration benefits), Brainstorm ideas
-Get to the 80% coverage approach,
- 2- Evaluate new / existing scenarios
Enterprise driver/reasons for IPv6
- Better Address Space Economics
-Address depletion in geographic pockets
-Support new devices/technologies that drive up address usage
-Support applications that require global addresses (P2P)
- Simplified Mobility Model
-Seamless roaming
- Simplified Operation Model
-Network and end device renumbering
-Reduced reliance on DHCP
- Security
-End to end packet integrity
-Integrated IPSec
- IPv6 development
- New IPv6 and the 'killer app'
Enterprise building blocks in arbitrary order
- Internet data center
-server farm
- Intranet data center
-server farm
- VPN infrastructure
- WAN Corporate backbone
- WAN extranet
- LAN (single site, single routing domain)
- Network edge devices or perimeter (firewall, mail proxy etc)
- Connectivity - Multi-ISP
-Multi addresses
- Applications Inventory
- Audit / Understanding the network mapping
Call for more scenarios from the outside
- Attempted to list some more scenarios
- Internet Data center providing access to IPv6 apps/IPv4 apps across ISPs (IPv4 and or IPv6)
-Outgoing/incoming access
-Cross of perimeter
- Outsourced all / most of corporate backbone and desire to deploy native IPv6
- Simpler case - Entire enterprise move to v6
- Call for more scenarios
Brainstorming session outcome
- Try to order the scenarios by complexity
-Difficulty to define complexity
- Decided to not order the building blocks
- Generate a matrix of building blocks versus scenarios
-How they apply to different scenarios
single building/single location
campus environment/single location
campus environment/multiple locations
Connectivity models/use the building blocks to create scenarios
- Hostv6 / Nodev6 / Devicev6 etc….
-on v4 LAN
-on v6 LAN
- LANv6 (island) to LANv6 (island)
-over v6
-over v4/v6
- LANv6 (island) to LANv4 (island)
-over v6
-over v4/v6
Simplest scenario
- Single location (in an IPv4-constrained region)
- Don't have a perm globally routable v4 address
-Don't have infrastructure for a server
-For e.g. need "permanent" address, need peer-to-peer …..
- Solution is to go to IPv6
Discussion:
[none recorded]
=================================================
New Work/Discussions Related to the v6ops Charter
-------------------------------------------------------------
Operational Issues with IPv6 Addrconf & DHCPv6 -- Ralph Droms
SLIDES:
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/DHCPv6.pdf>
<http://www.6bone.net/v6ops/minutes/IETF-55-Sunnyvale-Interim/DHCPv6.ppt>
List of issues
Are actions required
Who should take ownership of the action to solve the problem
Try not to dig the hole too deep
This was a very lively discussion.
DHCP = stateful autoconfiguration?
DHCPv6 is essentially the only one (save for hard wired addressing -:)
The RFCs often refer to stateful configurations, so is this equivalent to DHCPv6?
Does this loose reference require clarification - consensus was yes
We probably need to refer this to the v6 working group.
Issue on the M, O, and A bits
A bit set in prefix advertisement causes SLAAC independent of others
M bit set in RA causes use of DHCP for address; M bit not set, then no DHCP
Discussion about whether that is really what is mean't in the RFCs
Does it need clarification, and where?
O bit set in RA causes DHCP for other configuration items (e.g., DNS server)
Does all this need clarification - yes. Send to v6 WG.
Is there a lequirement for every stack to support DHCP?
Required when M and O bits are set.
After much discussion it was decided that clarification was needed,
but that we should take this to the v6 WG.
Authentication for DHCPv6
Inconsistencies between DHCP and SLAAC
Preferred and valid lifetimes of addresses, for example
There are other inconsistencies, but latest information wins
Move to the v6 WG.
Need to discuss how we push things to the v6 WG.
DNS configuration
Can select DNS resolver autoconfiguration with O bit not set and
DNS resolver configuration through DHCP with O bit set
Requires stack must have DHCP for use with O bit set
Some folks argued that the O bit is not very useful
SLAAC and DHCP from same prefix?
There was a general consensus that much of this discussion should be
revisited in the v6 WG
----------------------------------------------------------
Unidentified issues in IPv6 deployment/operation -- Itojun
SLIDES:
<http://www.ietf.org/internet-drafts/draft-itojun-jinmei-ipv6-issues-00.txt>
Itojun presented Unidentified issues in IPv6 deployment/operation (see slides above and below).
Motivation
* ngtrans chairs asked WIDE to identify issues/problems still remaining
* issues related to deployment/operation can touch some protocol issues
* not sure how the document should end up
-v6ops wg item?
-recommendation to other wgs?
Addressing - DNS
* Reverse DNS mapping
-Difficult to maintain reverse mapping
-Cannot auto-generate (like dhcp128.example.com)
-Dynamic DNS registration still in infancy
-Scoped addresses - separate name tree, just like firewall?
-Temporary address - probably we don't want to register
-Don't rely on the existence of PTR RR
-Alternate mechanism? - ICMPv6 node info query
* Forward DNS mapping
-Dynamic DNS registration still in infancy
-Scoped addresses
separate name tree, just like firewall?
AAAA record does not carry scope info
Addressing - scoped unicast
* Link-local
-ND - there's no question, it's needed
-Normal use - back to DNS discussion
* Is site-local address really useful?
-IBGP session
how likely we will renumber?
routers MUST have global address to send ICMPv6 to outside
-Security risks
putting site-locals into routing header and attack nodes inside other company
Attacks via application layer (itojun@[fec0::1]@kame.net)
Addressing - multicast
* How should we really use scopes?
-SLP and other protocols rely upon scoped multicasts
* How likely it is to have multicast routing infrastructure?
-If likely, protocol designs can take advantage of it
-If not likely, protocol designs should use unicast, not multicast
Addressing - anycast
* How to use anycast for service location purposes
* Characteristics of anycast address - separate draft
-draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt
Prefix management
* ISP-to-edge prefix assignment (prefix delegation) -> ipngwg
Routing
* BGP4+ clarifications
-implementation varies due to document ambiguities
-what to put into nexthop attribute
-BGP4+ operation by link-local address only
* Interaction between routing protocols ("redistribute")
* Aggregation - network designs for a site/ISP/...
* Multihoming - RFC3178, multi6 wg
32bit IDs
* A lot of protocols use 32bit IDs
* 32bit IDs = management headaches, scalability limitation
* What is the domain of uniqueness?
-BGP, OSPF - within an AS
-NTP - worldwide uniqueness needed
* How wide does ID need to be?
-128bit - global IPv6 address can be used
-64bit - EUI64 maybe? (not guaranteed to be unique)
-64bit - 32bit AS number + 32bit serial (management headache)
-32bit - insufficient (32bit AS numbers)
* Scoped IPv6 address and IDs?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
DNS issuess
* Server discovery
-anycast, multicast, DHCPv6?
* Packet size
-EDNS0? root zone response size? glue AAAA records?
* DNS server reachability
* Broken DNS servers
-Incorrect NXDOMAIN response when "www.example.com" has only A,
and AAAA query is issued
(should be empty NOERROR)
* Making root DNS servers IPv6 ready
* Making ccTLD/gTLD DNS services IPv6 ready
SNMP
* Transport - okay. we can run it over IPv4/v6
-content and transport are separate
* Need SNMPv3 to support trap via IPv6
* MIBs - in the works
Security
* Some new model is needed, which is better than firewall
* With firewalls, no real benefit of IPv6 (no p2p apps deployment)
* Firewall model is flawed anyways
-roaming laptop infected by virus, insider attacks
* "use IPsec" is not enough
-need to go into gory details
-routing protocol documents need to be revisited
RADIUS
* protocol specs are there, just deployment issues
Non-socket APIs
* DBMS can handle IPv4 addrs as primitive data type
* Same thing should happen for IPv6
* Platform-dependent APIs
Education
* Lack of educational materials
-operation, API, whatever
* Host/router requirements
Summary
* Various issues still need to be addressed
* maybe in v6ops wg, or other wgs
* how should we handle this?
-v6ops wg recommend something to other wg via AD?
-this document be published as snapshot?
-whatever?
Itojun will try to break his document into pieces, with the idea of using different approaches in different cases.
--------------------------------------------
Wrap-up and Review of Action Items -- Chairs
* Rob Austein to look into DNSSEC and DNS ALG analysis
* Talk to Randy about charter changes
* Take issues back to the individual groups and the whole WG on the mailing list
-------------
adjourn day 2