Draft v6ops minutes for IETF62 - for comment by all and update by the chairs

[Baker Fred <fred@cisco.com>]

Note to secretariat: presentations used during the meeting are at  
http://netcore.fi/pekkas/ietf/62/
------------------------------------------------------------------------ 
----------------------------------------
Minutes of IPv6 Operations WG (v6ops)


Wednesday, March 9 at 0900-1130
===============================

CHAIRS: Pekka Savola <pekkas@netcore.fi>
        Soininen Jonne <jonne.soininen@nokia.com>
  - Scribes:
	Fred Baker
	Mikael Lind

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
 - draft-ietf-v6ops-natpt-to-exprmntl-00.txt
 - 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(?)
 - draft-ietf-v6ops-bb-deployment-scenarios-00.txt
 - GOAL: discuss changes and future direction; prepare for WG LC after  
1-2
   revisions

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
 - draft-v6fix-en">http://v6fix.net/wide-draft-v6fix-en
 - 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
 - draft-ietf-v6ops-v6onbydefault-03.txt
 - draft-ietf-v6ops-onlinkassumption-02.txt
 - 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(?)
 - draft-vandevelde-v6ops-nap-01.txt
 - 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
 - draft-savola-v6ops-security-overview-03.txt
 - 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
 - draft-chown-v6ops-vlan-usage-02.txt
   (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
 - draft-vives-v6ops-ipv6-security-ps-03.txt
 - 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.