All,
Attached are the minutes taken for our meeting in Vancouver. Many
thanks to Karen O'Donoghue for acting as minute taker and Suresh
Krishnan for being the Jabber scribe. Please review the minutes and
provide any changes, clarifications, or updates.
Regards,
Brian & Bob
IETF IPv6 Maintenance Working Group Meeting
Wednesday, 5 December, 2007, 0900-1130
The meeting was called to order by co-chairs Brian Haberman and
Bob Hinden. Karen O'Donoghue (with input from Ed Jankiewicz)
took minutes and Suresh Krishnan acted as Jabber scribe. The blue sheets were
distributed, and the agenda was presented with no additions. During
the agenda discussion, Rosalea Roberts reminded the working group
of the draft-narten-ipv6-3177bis-48boundary-03 discussion
currently ongoing in v6ops and encouraged this working group to
follow and participate in that discussion.
Node Requirements Update (Brian Haberman for John Loughney)
=================================================
Document: RFC 4294 IPv6 Node Requirements
Slides: IETF70-6MAN-node-reqs-update.pdf
Brian Haberman, speaking for the unavoidably absent John
Loughney, discussed the question of updating RFC 4294. There are
basically two questions. Should we do the work and if yes, how
should we proceed? Several individuals indicated that the update
should be done and there was no opposition. Based on the consensus
that the work should be done, Brian further asked how to proceed.
Three options were identified:
1. Simple update to cover base RFCs
2. #1 AND adding additional RFCs
3. #2 AND restructuring
The ensuing discussion primarily focused on options 2 and 3 with
most speakers supporting option 2. A recurring theme was the need
for a definition of the minimal requirements for interoperability with
organizations responsible for deployment (e.g. DoD and NIST)
specifying additional deployment specific requirements. Others
indicated that the current document currently contains very few
MUSTs as it is. The use of conditional language to specify
requirements for subsets of functionality was discussed. Brian
Haberman requested that participants continue the discussion on the
mailing list.
IKEv2 issues (Pasi Eronen)
=====================
Draft: draft-eronen-ipsec-ikev2-ipv6-config-01.txt
Slides: IETF70-6MAN-ipv6-ikev2.pdf
This draft addresses an issue with IPv6 configuration in IKEv2 for
remote access VPNs. There was general agreement that IKEv2 is
broken and this works needs to be done. Discussion focused on
whether the link model utilized was representative enough and
potential scalability issues. Yari Arkko indicated that he liked the
draft and supported the effort. A change is needed and there is a
small window of opportunity to make this change. Bob Hinden asked
if it was appropriate for the 6MAN WG to do the work. Yari prefers
for the security ADs to sponsor the work with strong participation
from this WG and will take the action to initiate a conversation with
them.
Reserved IIDs (Suresh Krishnan)
========================
Document: draft-krishnan-ipv6-reserved-iids-02.txt
Slides: IETF70-6MAN-reserved-iids.pdf
Suresh presented this proposal to create a centralized repository for
reserved interface identifiers. Brian Haberman pointed out that we
already do this for the multicast address space (RFC 3307). No one
opposed the adoption of this as a working group document.
DHCP options in RAs (Suresh Krishnan)
================================
Document: draft-krishnan-intarea-ra-dhcp-00.txt
Slides: IETF70-6MAN-dhc-options-in-ra.pdf
Suresh presented a draft that defines a generic neighbor discovery
option for carry DHCP options over IPv6 Router Advertisements.
The rationale included a desire to avoid parallel definition and
duplicate standardization as well as the potential to share code.
During the discussion phase, several individuals addressed concerns
with the proposal. Alain Durand stated that this draft had been
discussed yesterday in the DHCP WG and the sense of the DHC
meeting was that it was a bad idea. Bob Hinden pointed out that IF
this goes forward the WG would need to classify current options.
There is probably a very small set of options that this would be
appropriate for. Erik Nordmark stated that this creates more
problems than it solves. The more places we put this kind of
information, the more work we have to do to resolve what happens
when you get contradictory information from another method. We
also need to be very specific about the lifetime of this information.
Dave Thaler pointed out that without this proposal, anyone who
wants to put the same information in RAs and DHCP must come to
the IETF for review and approval. Ralph Droms agreed that by doing
this we eliminate possible oversight. One individual did indicate that
this was a good idea, but we need to be very careful about what
information is allowed to be carried. Yari Arkko concluded the
discussion by stating that he did not support this draft.
Address Selection (2 presentations)
==========================
Document: draft-arifumi-6man-addr-select-sol-00.txt
Slides: IETF70-6MAN-arifumi-addr-select.pdf
Arifumi Matsumoto presented the above draft. Erik Nordmark stated
that the document talks about a node with multiple interfaces. How
would you deal with the situation where you got multiple responses?
The chairs asked the room who had read the document and who
thought it was ready for to be adopted as a working group item.
There was a small set of people answering yes to both. Further
discussion was directed to the list.
Document: draft-fujikawa-ipv6-src-addr-selection-01.txt
Slides: IETF70-6MAN-fujikawa-src-addr-selection.pdf
Fujikawa Kenji presented the above draft. Time ran out and the
chairs requested that the WG read the document and take the
discussion to the mailing list.
On-link issues & 2461bis (Hemant Singh)
==============================
Document: draft-wbeebee-on-link-and-off-link-determination-00.txt
Document: draft-wbeebee-nd-implementation-problems-00.txt
Slides: IETF70-6MAN-offlink.pdf
Hemant Singh presented a discussion on the on- and off-link issues
with RFC 4861. Hosts in aggregated routed networks are offlink.
There is data forwarding confusion on IPv6 hosts behind modems in
aggregated routed networks. RFC 4861 is ambiguous on how to
configure RA on a router to signal off-link. The author wishes to
clear up ambiguity in the specification. Erik Nordmark said this
sounds like an implemention bug.
Bob Hinden indicated that more discussion and analysis are needed
before we can adopt as a working group item. He directed discussion
to the mailing list.
Dickson draft (Brian Dickson)
======================
Document: draft-dickson-v6man-new-autoconf-00.txt
Slides: IETF70-6MAN-New-Autoconf.pdf
Brian Dickson presented a proposal that is motivated by looking at
wide and timely IPv6 deployment and issues of scaling in a mixed
IPv4 and IPv6 network. The draft proposes the use of prefix lengths
other than 64 bits in certain circumstances. The purpose of this draft
is to foster discussion and collect some analysis for consideration.
Brian wants to know if we can make a small change to improve
scalability?
An animated discussion followed Brian's presentation. Tony Hain
stated that he thought this was a really bad idea. It breaks current
operations, the fundamental premise that it helps scaling is flawed,
and the proposal is ten years too late. Marla Azinger stated that the
document was too long and she was disappointed that the author
didn't get to the point thus obscuring the message. She felt we
couldn't decide today because more work is required to clarify the
arguments and proposal. Alain Durand voiced some sympathy with
the idea that maybe /64 is not the right thing; however, he felt that
we need to separate the policy and technical discussions. Margaret
Wasserman pointed that while we could decide whether or not this is
good technically we are not in a position to force a policy change.
Another speaker felt the analysis was good, but the idea was bad.
Erik Nordmark seconded the concern that the timing is wrong (it is
either 10 years too late or 20 years too early). He also is not
concerned about current IPv6 address consumption rate. Another
individual pointed out that we don't fully appreciate the impacts of
this on other organizations. Brian Dickson concluded with the
comment that making these changes later would require re-prefixing
and re-numbering. A parallel move towards incremental changes
would not impede deployment.
The chairs asked the room whether the work should continue. Many
hands said no and a few indicated yes.
ULA-C Analysis (Margaret Wasserman)
=============================
Document: draft-mrw-6man-ulac-analysis-01.txt
Slides: IETF70-6MAN-ULAC-Analysis.pdf
Margaret Wasserman presented her draft on an analysis of Centrally
Assigned Unique Local Addresses (ULA-Cs). The draft discusses
the motivation, costs, and some of the arguments for and against
ULA-Cs in an attempt to help the IETF IPv6 community reach
consensus on this issue. The questions for the WG are: 1) Should
some kind of centrally-assigned ULA be available; and if so 2)
should they be defined in the IETF?
Bob Hinden's draft was produced with the motivation that he wanted
a good example of what it could look like if the IETF wanted to do
this. He is not a strong proponent. The world has gotten used to local
addresses, and he doesn't want the lack of net 10 type addresses to
slow down v6 deployment. Kurt Lindquist felt that ULA-Cs create a
sixth RIR and is a bad idea. Alain Durand indicated that this is a
technology versus policy issue, and he's not sure where it should be
discussed. Tony Hain indicated that we are not creating a registry.
Instead, we are creating an instruction to the registry community.
Someone will create this and do it anyway if the IETF doesn't. Dave
Thaler indicated that the benefits don't outweigh the costs. The
chairs asked that folks read the draft and comment on mailing list.
The meeting adjourned.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
