IPv6 WG Minutes

Brian Haberman <brian@innovationslab.net> Mon, 21 March 2005 16:43 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25120 for <ipv6-web-archive@ietf.org>; Mon, 21 Mar 2005 11:43:40 -0500 (EST)
Received: from megatron.ietf.org ([]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDQ5K-0006tW-Js for ipv6-web-archive@ietf.org; Mon, 21 Mar 2005 11:48:58 -0500
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPup-0001Dd-Su; Mon, 21 Mar 2005 11:38:07 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDPun-0001D4-UW for ipv6@megatron.ietf.org; Mon, 21 Mar 2005 11:38:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24810 for <ipv6@ietf.org>; Mon, 21 Mar 2005 11:38:03 -0500 (EST)
Received: from pilot.jhuapl.edu ([] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDPzr-0006kg-GH for ipv6@ietf.org; Mon, 21 Mar 2005 11:43:22 -0500
Received: from ([]) by pilot.jhuapl.edu with ESMTP id KP-VXL34.14234608; Mon, 21 Mar 2005 11:37:13 -0500
Mime-Version: 1.0 (Apple Message framework v619.2)
To: IPv6 WG <ipv6@ietf.org>
Message-Id: <a272df448b65c789aacafb4d48d6ef93@innovationslab.net>
From: Brian Haberman <brian@innovationslab.net>
Date: Mon, 21 Mar 2005 11:37:17 -0500
X-Mailer: Apple Mail (2.619.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86
Subject: IPv6 WG Minutes
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2011416092=="
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1

      A big thank-you to Suresh Krishnan for taking minutes.  Please
send corrections to these minutes by March 22, 2005.


IETF 62 ipv6 wg meeting minutes

People referenced in minutes
Brian Haberman (Brian)
Margaret Wasserman (Margaret)
Jinmei Tatuya (Jinmei)
Pekka Savola (Pekka)
Alain Durand (Alain)
Bob Hinden (Bob)
Rob Austein (Rob)
Hideaki Yoshifuji (Hideaki)
Mukesh Gupta (Mukesh)
Dave Thaler (Dave)
Elwyn Davies (Elwyn)
Thomas Narten (Thomas)
George Michelson (George)
Bill Fenner (Bill)
Stig Venaas (Stig)
Mark Andrews (Mark)
Olafur Gudmundsson (Olafur)

Agenda and Document Status
Brian Presenting
No one had any comments on the Agenda during Agenda Bashing

Jinmei has a comment on the Doc status. He wants to know next steps for
2462bis as ADs need implementation status reports .

Margaret needs info if former impl reports apply (just checking to make 
Also need statement from chairs and pointer to the old impl report to 
effect. Mukesh Gupta (Mukesh) wants to know if the implementation 
reports are
needed for the ICMPv6 revised draft as well. Brian clarifies they are 
for both ICMPv6 and for 2461bis. He also clarifies that they are not 
if the existing implementations are not affected. The loosening of algo 
privacy addrs, for example, has no effect on existing implementations. 
thinks the reports are so general, that is hard to infer anything 
from them.Margaret thinks that they may not be complete but they were 
enough for the first time. IESG will not force to redo a new format for
the Implementation Reports

ULA update
Margaret presenting

She has no slides. She already sent the info to the ML.

IESG review found an issue with the DNS section. The issue was the 
load due to reverse lookups on DNS. Added text to resolve this.The text
Reverse queries MUST NOT be sent out of the site.

Alain is worried about how this will be implemented on the routers or 
on DNS
servers? Mark thinks that basic premise is that this
traffic should not leave the site and must egress filter it and must 
tell the
client it does not exist. He said para had MUST in upper case.Brian and
Margaret think that this is operational guidance and cannot use 

Alain and Pekka think that if it needs to be in a DNS implementation it 
to be normative. Alain wants a separate document addressing the dns 
issues and does not want this text here. After discussion between Alain,
Margaret, and Bob agree to have the issue mentioned both in the ULA 
and another separate document. Rob clarifies that this text does not 
apply to
centrally assigned ULAs, which most likely will have a real reverse 

Alain thinks we need a BCP document containing the list of prefixes. 
agrees with Alain. We have a problem which is holding up this doc. That 
what we are fixing. We cannot wait for another doc to go all the way 
the process.Margaret thinks there are 3 options 1) get the text in this 
and publish it2) wait for the other document and add a norm reference 
to it
3) do nothing. Alain: thinks there is a 4th option 4) take great care 
in this
and point to an informative reference. He refers to RFC1918 that had 
which said don't put this on the net. that does not work. We will have 
clients still generating queries. We need to fix this in the servers

Pekka is worried about the effects this will have on caching resolvers 
every host needs to be modified. Olafur feels that this will cause least
damage as opposed to not doing this. Margaret: It does not hurt you any 
if you get a no from your ISP rather than from the root server. Rob 
we need to pick a default (pass or don't pass). This is the lesser of 2 
Make it a config option. we should not harm the public net. Pekka is
concerned whether the people who use ULA will see it the same way.

Pekka: It is just not clear, that the people who use ULA will see this.

Jinmei and Alain don't want this work to be done in the IPv6 wg. Rob and
Mark also think this should be done in the DNS space in the long term 
this is a short term fix.

Brian wants to use this text as a rough guideline and asks for a show 
of hands.

Who wants to see this text in the doc? about 15 hands
Who does not? one or two hands

Alain thinks the second question was a bit loaded.

Brian rephrases Q2 to be "Who does not feel this text should in this 
and be in another document"? 3 hands

Update to address arch
Bob presenting
It was approved as DS. There was an appeal. To resolve the appeal it was
published as PS. There is most likely an implementation report already. 
main changes were to resolve issues raised in Robert Elz's appeal and to
deprecate site local. There were also a few mainly editorial changes. 
will remove confusing text in the multicast scoping part of the 
wants compatible addresses removed from the spec. Tim agrees. Bob 
thinks there are
people who still want them in. Pekka feels that there was no consensus 
on ML.
We should get the consensus here. Bob thinks that we should probably 
it alone as we are recycling an exisiting standard.

Q1) Who wants to remove of ipv6 mapped addresses.
(no hands)
Q2) compatible addreses
who wants them to be removed? 20 hands
who does not want it removed? 3 hands

Hideaki does not want compatible addrs removed. He wants the address 
not to be reused. He is ok with deprecation.

Bob: Do we want to deprecate them? about 10 hands
No? 1 hand

Brian to be Hesham
The last major issue left is the processing messages without the SLLAO 
Will be adding text from Greg Daley to clarify this case. Will make 
sure that
Hesham will send the propsed changes to ths list. Jinmei and Greg agree 
take it on the list

(Reordering of presentations)

Mukesh presenting

Major changes are
* text to allow disabling of sending Destination unreachable messages 
will be
added as a SHOULD
* will remove security replated processing details for icmpv6 packets 
and add
an informative reference to 2401bis. There is a downref issue if this 
needs to
be done.
* New text for source address determination from Elym to be included as 
2.2 (b)
instead of 2.2 (b),(c) and (d)

Discussion between Suresh, Bob, Dave, Elwyn and Pekka on whether the 
should try to make the error message more informative when the the 
might not know this or may not want to know this. Pekka thinks that 
this as a SHOULD will cover the existing implementations

Pekka the previous SHOULD will cover the existing

Dave presenting

Dave talks about why we need ndproxy and what are the characteristics of
ndproxy. The doc is aimed to be EXPERIMENTAL. Loop prevention was a 
issue in the ML discussions. Added text to say loop prevention is a MUST
(and allow two ways to do it STP / physical constraints)

Erik had a new suggestion (P bit in RA)
-> if clear and on upstream proxy would set and forward on downstream
-> if set or on downstream the proxy would disable proxy func on that 
for some time.
hold down time of 2*maximum RA interval = 60 mins

now the draft has 3 options (P/STP/physical constraints)

Bob suggested the option (c) - physical constraints should be removed 
and the
authors agreed. Pekka agrees with removing (c). Suresh is concerned 
that if a
network contains some ndproxies which use the P-Bit and some which use 
there will be an issue. Greg suggests adding an appendix clarifying 

SEND interoperability is another issue which remains. Dave talks about a
draft draft-daley-send-spnd-prob-01 which talks about the scenarios
send is not a blocking issue as long as the draft is consistent. The 
requirement for send interop has been removed.

Alain wants to know if this is related to trill? Brian thinks it is not 
and is

IAB ipv6 ad-hoc committee report
Thomas presenting

RIRs were starting to request large allocations from IANA(>/23). IANA 
advice from the IAB. The ad hoc committee was formed to advice IAB on 
addressing matters

Related drafts
Format of the IANA registry huston-ip6-iana-registry-05
ip6.int deprecation huston-ip6-int-01

Alain wants to know if there are stats for number of queries for 
ip6.int as he
is concerned about the impact of doing this to existing equipment.
Thomas does not have them. George has info collected over 2 years. He 
make the info public, but he said the volume is pretty low but not 
George thinks that there will be some impact but we must not overstate 

Thomas thinks allocating /23s to RIRs is not a good idea for 
agrgegation. The
RIRs think /12 or /16s are better. He also thinks that we need to have 
a good
balance between aggregation and conservation (in ipv6 the balance is 
towards aggregation). The IETF interested in long term stewardship, and 
day to day management. We need to get good aggregation over time

Currently each RIR has its own policy but they should converge on same 
before going forward. We need to document technical considerations of
allocation sizes, reservations etc. huston-ipv6-hd-metric-00 needs 
community review

Pekka thinks is not appropriate to discuss it here. Thomas and Pekka 
kind of
agree on v6ops.

Bob announces that Thomas is retiring as AD. Thomas has been active a 
lot in
the ipv6wg. Bob wants to give him a big hand.

(The crowd goes into WILD APPLAUSE)

Thomas has had a lot fun and is continuing to have fun

ipv6 scope identifiers in URIs
Bill presenting

There is an issue with representing IPv6 scope IDs using URIs as % is 
to introduce % encoded chars. There are three ways to go about fixing 

1) Use a non-% character which fits existing grammar: We cannot copy 
and paste
2) Use %25 :It needs update to uri spec and we still cannot copy and 
3) Continue to use % : Does not fit URI spec. Exception to fundamental 
URI rule

Dave thinks Scope IDs appearing on the wire is a bad thing. Bill agrees 
him. Margaret thinks these are being used in some docs the IESG has 
Dave thinks this is OK to do as long as they are not called URIs. 
agrees with Dave. Brian, Bob, Mukesh think there is some utility for 
Jinmei is not convinced. Stig thinks there is no need to cut and paste 
these URIs will only be used internally by applications. Brian wants to
continue discussion on the ML as time is up.

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6