Last Modified: 2005-01-24
|Done||Publish Cellular Deployment Scenarios as a WG I-D|
|Done||Publish Unmanaged Network Deployment Scenarios as a WG I-D|
|Done||Publish Survey of IPv4 Addresses in IETF Standards as WG I-D|
|Done||Publish Cellular Deployment Solutions as a WG I-D|
|Done||Publish Unmanaged Network Deployment Solutions as a WG I-D|
|Done||Submit Cellular Deployment Scenarios to IESG for Info|
|Done||Submit Unmanaged Network Deployment Scenarios to IESG for Info|
|Done||Publish Enterprise Deployment Scenarios as a WG I-D|
|Done||Submit Survey of IPv4 Addresses in IETF Standards to IESG for Info|
|Done||Publish ISP Deployment & Solutions as a WG I-D|
|Done||Submit Cellular Deployment Solutions to IESG for Info|
|Done||Submit Transition Mechanisms to IESG for PS|
|Done||Submit IPv6 Neighbor Discovery On-Link Assumption to IESG for Info|
|Done||Submit Dual Stack IPv6 on by Default to IESG for Informational|
|Done||Submit Unmanaged Network Deployment Solutions to IESG for BCP|
|Done||Submit ISP Deployment Scenarios & Solutions to IESG for Info|
|Done||Submit Application Aspects of IPv6 Transition to IESG for Informational|
|Done||Submit 6to4 Security Analysis to IESG for Informational|
|Done||Submit Enterprise Deployment Scenarios to IESG for Info|
|Done||Submit Renumbering Procedures to IESG for Info|
|Aug 04||Submit Assisted Tunneling Requirements to IESG for Info|
|Sep 04||Publish Enterprise Deployment Solutions as a WG I-D|
|Dec 04||Submit IPv6-in-IPv4 Tunneling using IPsec to IESG for Info|
|Feb 05||Submit IPv6 Security Overview to IESG for Info|
|Feb 05||Submit Enterprise Deployment Solutions to IESG for BCP|
|RFC3574||I||Transition Scenarios for 3GPP Networks|
|RFC3750||I||Unmanaged Networks IPv6 Transition Scenarios|
|RFC3789||I||Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards|
|RFC3790||I||Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards|
|RFC3791||I||Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards|
|RFC3792||I||Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards|
|RFC3793||I||Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards|
|RFC3794||I||Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards|
|RFC3795||I||Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards|
|RFC3796||I||Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards|
|RFC3904||I||Evaluation of Transition Mechanisms for Unmanaged Networks|
|RFC3964||I||Security Considerations for 6to4|
Minutes of IPv6 Operations WG (v6ops)
Wednesday, March 9 at 0900-1130
CHAIRS: Pekka Savola <firstname.lastname@example.org>
Soininen Jonne <email@example.com>
Introduction, agenda bashing, document status - 5 mins, Chairs/Savola
- Scribes! (Jabber also?)
no comments were logged against the agenda.
The chair reviewed the status of a number of documents. This is displayed in the slides used during the meeting.
Charter Discussion - 20 mins, Chairs/WG
- discuss the pending charter update, if not finalized yet
- GOAL: discuss the scope of v6ops WG work; gain consensus on the way forward
Kurtis Lindqvist presented a discussion of the proposed working group charter. This is discussed in the slides used during the meeting.
Work has a tendency to drag. A statement in the charter gives to opportunity for the chairs to get rid of a topic. Hopefully things will go faster. Kurtis thinks the charter is fine and should be sent to David Kessens for AD processing.
The key charter change from the working group discussion makes individual submissions to the working group into working group charter items earlier, rather than going through several iterations as individual submissions, resubmission as a working group item, and immediate approval.
Enterprise Analysis Discussion, 15 mins, Bound(?)
- draft-ietf-v6ops-ent-analysis-01.txt (or a revision?)
- GOAL: discuss issues and the path forward
Jim Bound discussed the status of the Enterprise Analysis discussion. This is under review by the IESG and has been held up in that dialog.
Key changes include limiting the discussion to dual stack networks and nodes, and updating the matrix of common use cases. Discussion is limited to enterprise needs within the coming 18 months (2005 and 2006). Discussion of transport and higher layers and of multihoming was removed, as the application layer scenarios became complex.
The reason is that there are few if any networks that are not being run at least partially using IPv4. There are a number of dual stack networks, and a number of networks that are using IPv4 only for internal management, but none that are literally IPv6-only.
There needs to be further discussion of sections 3 and 5 of the draft. Section 6 needs work discussing the difference between "IPv6 only" and "IPv6 dominant". Serious work needs to be done in section 7. Section 8 was dropped, as it recommended transition mechanisms; it may be rewritten in a manner that makes no recommendations.
The question Jim placed before the house is whether this document remains of interest to the working group, or should be replaced by documents such as the Japan IPv6 Promotional Council IPv6 Deployment Guide? The sense of the room was that the working group would review the draft intended to be posted by 28 April and make a determination.
A question was raised about the authorship - there are five authors, which may be excessive. Jim's sense is that all five authors have been important to the draft and deserve listing.
In wireless networks, some issues are arising in neighbor discovery and autoconfiguration. This may become a separate draft.
Reasons to classify NAT-PT to Experimental, 10 mins, Davies
- GOAL: discuss changes, solicit comments before going for WG LC
Elwyn Davies discussed changes to the previous proposal, which was to deprecate NATPT, to become making the capability experimental and listing the issues in the algorithm. The key recommendation is to use protocol translators and encapsulators as appropriate. These will need to be discussed in a protocol development working group.
draft-daniel-natpt-bis-00.txt discusses such a proposal (NAT-PT without DNS-ALG), but has not at this point been extensively discussed.
ISP IPv6 Deployment Scenarios in Broadband Access Networks, 15 mins, Popoviciu(?)
- GOAL: discuss changes and future direction; prepare for WG LC after 1-2
Adeel Ahmed (for Ciprian Popoviciu) discussed broadband deployment issues. Key changes that have occurred in the drafts related to cable deployment in access networks in the US: Time Warner and Comcast. Updates have related to QoS for encrypted traffic and bulk subscriber provisioning.
Added discussion of Wireless LANs in the security section, related to host authentication.
The authors solicit suggestions on how to combine or improve the sections on multicast, network management, QoS, and security. The working group is requested to post comments to the authors or to the list by 27 March 2005. The working group is expected to last-call the draft when posted.
Updates on the IPv6 Fix Project, 5-10 mins, Jinmei
- GOAL: share the results of recent experiments, discuss next steps
This work is not presented as an internet draft, but as a web page, as it describes a project of the Japanese WIDE project. The objective is to address issues that obstruct transition from IPv4 to IPv6. Key activities include collecting incident reports, network measurement, implementation behavior analysis, and requesting updates from relevant vendors.
Practically speaking, the *BSD, Linux, MacOS X, SOlaris, and Windows XP implementations were tested, and work-arounds developed for issues uncovered. The general finding is that implementations are "not bad". These results are summarized at the project site.
DNS Misbehavior is being directly studies with JPRS, the JPNIC domain registry. Of domains implementing the AAAA proposal, an automated test of names of the form www.*.co.jp showed that 0.04% of the domains and 0.11% of the servers had detectable problems. These operators are being contacted and the issues addressed.
Network quality is also being directly tested. This is based on ping RTT between key measurement points in Japan at WIDE and IIJ, and in Spain, and comparison between IPv6 and IPv4 route testing. Most sites are good for both IPv4 and IPv6. Issues that arise are further tested using traceroute and other tools. There is a plan for feedback to site administrators addressing issues noted.
Next steps include firewall testing, working with vendors on improvements, and a public mailing list on issues.
Suggestions from the floor included tying into RIPE network path testing, including tunnel detection and mutual ping RTT testing.
Status and going forward with IPv6-on-by-Default work, 5-10 mins, Chairs/Savola
- GOAL: discuss the options how to move forward
Pekka Savola presented work relating to the "on-link assumption" and "on by default" work. This addresses a fundamental flaw in DNS lookup mechanisms, that have implementations try with IPv6 before attempting with IPv4. A key issue with this document is that it discusses work in progress, making that work normative for it. The documents were resubmitted removing those references, and the working groups were asked to light a fire under their proposed solutions.
The on-link assumption draft will be published with draft-ietf-ipv6-rfc2461bis, which removes that assumption.
other issues relate to
- TCP soft errors (TCPM considering),
- SCTP and SCCP soft-errors (no progress),
- default address selection for unreachable destinations (no work done yet),
- and application robustness (transition document done).
There are three possible ways forward for draft-ietf-v6ops-v6onbydefault-03.txt. One is to leave the normative references, which we have chosen to not do. Another is to simply document the problems; another is to document fixes as they appear.
There was quite a bit of discussion by the Chairs, Alain Durand, David Kessens, Jinmei, Tony Hain, and others regarding the working group process. In essence, the question was whether we need to document all the problems that had to be fixed in the process of getting something out, or could that discussion die as the problems were fixed? The sense of the AD was that this document need not be published at all if all the problems were fixed, and the working group was perhaps best served by a blog or website listing current open issues. The sense of others was that the discussion needed to occur, and drafts drove that. The upshot was essentially to punt the matter to the new chairs; David indicated that he would return both documents to the working group.
The final question relates to the future of draft-ietf-v6ops-v6onbydefault-03.txt. It could be left as a living document listing the issues. A general suggestion is to use blogging or a web site to manage the temporary information and write an RFC descibing the general class of problem and general solutions.
IPv6 Network Architecture Protection, 10-15 mins, Van de Velde(?)
- GOAL: discuss changes and the approach; ask for WG item adoption
Tony Hain presented a discussion of network technologies, notably stateful firewalls and similar middleware, designed to meet market needs currently addressed using NAT technology. The new version contains a list of such market requirements; if additional market requirements are known, the authors would like text describing them.
The document also covers a gap analysis of issues - ULAs, renumbering, hiding subnet topology, multihoming, and traceability. It is not intended to be all-encompassing.
There was wide support in the working group, with many volunteering to read and comment on the updated draft. It will be a working group document.
How to secure draft-ietf-v6ops-mech-v2 tunnel with IPsec, 10 mins, Tschofenig(?)
- draft-tschofenig-v6ops-secure-tunnels-03.txt (or revised)
- GOAL: discuss changes, solicit feedback; ask for WG adoption
This is discussion of how to carry out draft-ietf-v6ops-mech-v2-06.txt using IPsec tunnels. Commentary has been towards document clean-up, and the question whether all traffic should be encrypted or only the link-local traffic? It is simpler if one encrypts everything. However if the target is protection of traffic (authentication), then maybe authentication of control traffic makes sense.
The new chairs will post a consensus call to v6ops on picking this work up; if consensus does not develop, the work will be allowed to continue as a personal submission.
Things to think about when renumbering, 10 mins, Chown
- draft-chown-v6ops-renumber-thinkabout-01.txt (to be submitted)
- GOAL: introduce the draft, solicit feedback for next revision
This draft represents observations and ruminations resulting from testing of the renumbering procedure document and general network practice. Many of these are site-specific issues. Scenarios include those with and without a flag day.
Much of this relates to IPv6 features related to renumbering. This includes multi-addressing, multicast, mobile IPv6, and ULAs.
The principal use of ULAs in renumbering is a semi-flag-day; one might use them to retain local application support while introducing a flag day outside of your network.
Many administrative issues came up which need to be looked at. These relate to router advertisement lifetimes, filters (especially firewall/border filters), renumbering frequency, delay-related considerations, scaling features, and dual stack issues, and application issues.
The authors feel that the content is fairly complete, and this will give operators and future workers information relevant to the topic.
IPv6 Security Overview - 5-7 mins, Davies
- GOAL: talk about differences, solicit more feedback; ask for WG adoption
Elwyn's slides pretty much indicate what he said...
The folks in the room generally supported the work, and had comments on the floor.
Two key discussions were had. One regarded moving the document work working group status. There was no opposition; there was also no comment. The other regarded the place of "privacy" addresses. The authors' comment was that while "security by obscurity" doesn't work well in the Internet, obscurity helps, and could be described as one of the principal functions of a firewall. On the other hand, obscurity only exists for systems that act only as clients; any system that must be addressed by another system must have a predictable address, whether by naming (DNS), announcement (a router), or a priori.
This is intended to be a working group item.
VLAN usage for transition, 5 mins, Chown
(this is already a WG item, just not resubmitted yet)
- GOAL: discuss issues, if any; solicit feedback. Prepare for WG LC soon.
The working group seems to have lost interest in the document. It may be appropriate to send it as a personal submission to the RFC Editor.
IPv6 Distributed Security Problem statement, 5 mins, Palet
- GOAL: alert the WG to the updated draft and solicit feedback
Look at a firewall-based security (which it calls a network-based model), and proposes what it calls a host-based model (which centers on host-host exchange of policy and authentication). Key issues relate to the trust model between the network and the host and the complexity of security in the host.
The document probably wants to move in the direction of the security area. It also needs a current threat analysis, and an analysis of current security models (including intrusion detection systems, mediation VLANs, the use of 802.1X, etc) in addition to the use of host-based security.
The authors plan to update the document with any new comments received.