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 [132.151.6.1]) 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 ([132.151.6.71]) 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 ([127.0.0.1] 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 ([132.151.1.176] 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 [132.151.6.1]) 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 ([128.244.197.23] 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 ([128.244.124.185]) 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
All, A big thank-you to Suresh Krishnan for taking minutes. Please send corrections to these minutes by March 22, 2005. Regards, Brian 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 sure). Also need statement from chairs and pointer to the old impl report to this effect. Mukesh Gupta (Mukesh) wants to know if the implementation reports are needed for the ICMPv6 revised draft as well. Brian clarifies they are needed for both ICMPv6 and for 2461bis. He also clarifies that they are not needed if the existing implementations are not affected. The loosening of algo for privacy addrs, for example, has no effect on existing implementations. Pekka thinks the reports are so general, that is hard to infer anything specific from them.Margaret thinks that they may not be complete but they were good 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 increased 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 normative language. Alain and Pekka think that if it needs to be in a DNS implementation it needs to be normative. Alain wants a separate document addressing the dns related 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 document and another separate document. Rob clarifies that this text does not apply to centrally assigned ULAs, which most likely will have a real reverse tree. Alain thinks we need a BCP document containing the list of prefixes. Brian agrees with Alain. We have a problem which is holding up this doc. That is what we are fixing. We cannot wait for another doc to go all the way during the process.Margaret thinks there are 3 options 1) get the text in this doc 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 text which said don't put this on the net. that does not work. We will have legacy clients still generating queries. We need to fix this in the servers Pekka is worried about the effects this will have on caching resolvers that 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 more if you get a no from your ISP rather than from the root server. Rob thinks we need to pick a default (pass or don't pass). This is the lesser of 2 evils. 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 and this is a short term fix. Brian wants to use this text as a rough guideline and asks for a show of hands. (CONSENSUS CALL) Who wants to see this text in the doc? about 15 hands Who does not? one or two hands (CONSENSUS IN FAVOR) Alain thinks the second question was a bit loaded. Brian rephrases Q2 to be "Who does not feel this text should in this document 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. The 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. Bob will remove confusing text in the multicast scoping part of the draft.Pekka 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 leave it alone as we are recycling an exisiting standard. (CONSENSUS CALL) Brian Q1) Who wants to remove of ipv6 mapped addresses. (no hands) (CONSENSUS AGAINST REMOVAL) Q2) compatible addreses who wants them to be removed? 20 hands who does not want it removed? 3 hands (CONSENSUS IN FAVOR OF REMOVAL) Hideaki does not want compatible addrs removed. He wants the address space not to be reused. He is ok with deprecation. (CONSENSUS CALL) Bob: Do we want to deprecate them? about 10 hands No? 1 hand (CONSENSUS IN FAVOR OF DEPRECATION) 2461bis Brian to be Hesham ================== The last major issue left is the processing messages without the SLLAO option. 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 to take it on the list (Reordering of presentations) icmpv6 ====== 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 sender should try to make the error message more informative when the the receiver might not know this or may not want to know this. Pekka thinks that adding this as a SHOULD will cover the existing implementations Pekka the previous SHOULD will cover the existing implementations ndproxy =========== 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 major 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 interface 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 STP there will be an issue. Greg suggests adding an appendix clarifying this. 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 explicit requirement for send interop has been removed. Alain wants to know if this is related to trill? Brian thinks it is not and is independent. IAB ipv6 ad-hoc committee report ========================= Thomas presenting RIRs were starting to request large allocations from IANA(>/23). IANA wanted advice from the IAB. The ad hoc committee was formed to advice IAB on ipv6 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 will make the info public, but he said the volume is pretty low but not trivial. George thinks that there will be some impact but we must not overstate this. 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 more towards aggregation). The IETF interested in long term stewardship, and not 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 process 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 used to introduce % encoded chars. There are three ways to go about fixing this 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 paste 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 with him. Margaret thinks these are being used in some docs the IESG has passed. Dave thinks this is OK to do as long as they are not called URIs. Margaret agrees with Dave. Brian, Bob, Mukesh think there is some utility for this. Jinmei is not convinced. Stig thinks there is no need to cut and paste as these URIs will only be used internally by applications. Brian wants to continue discussion on the ML as time is up. (END OF MEETING)
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- IPv6 WG Minutes Brian Haberman
- Re: IPv6 WG Minutes Brian Haberman