Corrections to the chairs.
Thanks, Bob Hinden and Brian Haberman
IPv6 Working Group Minneapolis IETF November 11 & 12, 2003
Chairs: Bob Hinden <[EMAIL PROTECTED]> Brian Haberman <[EMAIL PROTECTED]> Minutes taken by Steven Blake and Dave Thaler. Edited by Bob Hinden ---------------------------------------------------------------------- Agenda ---------------------------------------------------------------------- Tuesday, November 11, 2003 Introduction and Agenda Bashing, Chairs (5 min) Milestone Review and Document Status, Chairs (10 minutes) Local Communications Goals, Tony Hain & Fred Templin (15 minutes) draft-hain-templin-ipv6-localcomm-03.txt Goal: discussion of open issues Tunnel MIB, Dave Thaler (10 minutes) draft-thaler-inet-tunnel-mib-00.txt Goal: overview of proposal, adopt as WG item? Proxy RA, Dave Thaler (10 minutes) draft-thaler-ipv6-ndproxy-01.txt Goal: status update, adopt as WG item? ICMPv6 Updates, Bob Hinden (10 minutes) draft-ietf-ipngwg-icmp-v3-02.txt Goal: status update Wednesday, November 12, 2003 Router Selection, Dave Thaler (10 minutes) draft-ietf-ipv6-router-selection-02.txt Goal: issue discussion, next steps Neighbor Discovery Updates, Tatuya Jinmei (15 minutes) draft-soliman-ipv6-2461-bis-00.txt Goal: issue discussion Stateless Autoconfiguration Updates, Tatuya Jinmei (15 minutes) draft-jinmei-ipv6-rfc2462bis-00.txt Goal: issue discussion Scoped Address Arch Document, Tatuya Jinmei (10 minutes) draft-ietf-ipv6-scoping-arch-00.txt Goal: discussion of last call comments Site-Local Deprecation Document, Christian Huitema (20 minutes) draft-ietf-ipv6-deprecate-site-local-01.txt Goal: discussion of last call comments Unique Local Addresses Document, Bob Hinden (15 minutes) draft-ietf-ipv6-unique-local-addr-01.txt Goal: discussion of last call comments Address Architecture Update, Bob Hinden (15 minutes) draft-ietf-ipv6-addr-arch-v4-00.txt Goal: review changes and plan for moving forward Identifier/Locator Separation, Kurt Lindqvist (10 minutes) ----------------------------------------------- Introduction and Agenda Bashing, Chairs (5 min) ----------------------------------------------- The Brian Haberman introduced the meeting and reviewed the agenda. Elizabeth Rodriquez (IMSS chair) announced that the IPv6 over FiberChannel draft is in last call in IMSS working group. TAHI Announcement: see slides Testing Event - Jan 19-23, 2003 - Japan - New test suite (IPv6 & SIP) - See http://www.tahi.org for more information --------------------------------------------------------- Milestone Review and Document Status, Chairs (10 minutes) --------------------------------------------------------- MILESTONES (previous dates in parenthesis) Done Submit Prefix Delegation requirements and submit to IESG for Informational. Done Submit TCP MIB to IESG for Proposed Standard. Done Submit IPv6 Node Requirements to IESG for Informational. Done Submit Forwarding Table MIB to IESG for Proposed Standard. Done Submit IP MIB to IESG for Proposed Standard. Nov 03 Submit Site-Local Deprecation document to IESG for Informational Nov 03 Submit Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard. Dec 03 (Nov 03) Submit update to ICMPv6 (RFC2463) to be republished at Draft Standard. Dec 03 (Nov 03) Submit Router Preferences, More-Specific Routes, and Load Sharing to IESG for Proposed Standard. Feb 04 (Dec 03) Submit updates to Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) to be republished at Draft Standard. Dec 03 Submit Proxy RA to IESG for Proposed Standard Dec 03 (Oct 03) Submit Link Scoped IPv6 Multicast Addresses to IESG for Proposed Standard. Dec 03 (Oct 03) Submit IPv6 Scoped Addressing Architecture to IESG for Proposed Standard. Dec 03 Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard. Jan 04 (Oct 03) Submit UDP MIB to IESG for Proposed Standard. Jan 04 (Nov 03) Submit Requirements for Local Addressing to IESG for Informational Jan 04 (Nov 03) Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard. Jan 04 (Oct 03) Resubmit Node Information Queries to IESG for Proposed Standard. Jan 04 (Nov 03) Re-charter or close working group. PUBLISHED & APPROVALS RFC's Published RFC3587, "IPv6 Global Unicast Address Format" IESG Approved none STATUS OF CURRENT WORK ITEMS Flow Label - Editor: Jarno Rajahalme - Milestone: Done o Submit for PS - Status: o In IESG o New draft submitted to resolve IESG comments - Open Issues: o None known Proxy RA - Editor: Dave Thaler - Milestones: Dec 03 o Submit to IESG for PS - Status: New draft o To be discussed in WG Prefix Delegation Requirements - Editor: Shin Miyakawa - Milestone: Done o Submit for Info - Status: In IESG o New draft submitted that responds to IESG comments - Open Issues: o None known TCP MIB - Editor: Rajiv Raghunarayan - Milestone: Done o Submit for PS - Status: Submitted to IESG - Open Issues: o None known IPv6 Node Requirements - Editor: John Loughney - Milestone: Done o Submit for Info - Status: In IESG o New Draft submitted that responds to AD comments - Open Issues: o None known Forwarding Table MIB - Editor: Brian Haberman - Milestone: Done o Submit for PS - Status: In IESG - Open Issues: o None known Node Information Queries - Editor: Matt Crawford - Milestone: Oct 03 o Re-submit for PS o Update milestone to Jan 04 - Status: New draft in w.g. last call o New draft need to resolve issues raised on mailing list and at Vienna IETF - Open Issues: UDP MIB - Editor: John Flick - Milestone: Oct 03 o Submit for PS o Update milestone to Jan 04 - Status: New draft available - Open Issues: o none known o Ready for w.g. last call? IP MIB - Editor: Shawn Routhier - Milestone: Done o Submit for PS - Status: In IESG - Open Issues: o Will be delayed by INET Address TC o Dependent on Router Selection Draft Default Router Preferences - Editor: Dave Thaler - Milestone: Nov 03 o Submit to IESG for PS o Update milestone to Dec 03 - Status: AD Comments Received - Open Issues: o Split load balancing into separate document and resolve issues o To be discussed in w.g. Link-Scoped Multicast - Editor: Jung-Soo Park - Milestone: Oct 03 o Submit for PS o Update milestone to Dec 03 - Status: WG Last Call - Open Issues: o No technical issues, but is it needed? o OK to advance? Comment: We don't need link-scoped multicast; changes SSM semantics. ACTION: Chairs need to post query to mailing list to determine working group consensus on how to move forward with the Link-Scoped Multicast draft. Scoped Addressing Architecture - Editor: Jinmei Tatuya - Milestone: Oct 03 o Submit for PS o Update milestone to Dec 03 - Status: Working Group Last Call - Open Issues: o Need to be consistent with INET Address TC on default zone values o OK to advance (after new draft)? Savola: Scoped Architecture cannot go forward until ICMPv6 is updated. Site-Local Deprecation - Editors: Christian Huitema, Brian Carpenter - Milestone: Nov 03 o Submit for Informational - Status: In working group last call - Open Issues: o Issues raised on mailing list o To be discussed in w.g. meeting Unique Local Addresses - Editor: Bob Hinden - Milestone: Nov 03 o Submit for PS - Status: In working group last call - Open Issues: o Issues raised on mailing list o To be discussed in w.g. meeting Requirements for Local Addressing - Editor: T. Hain, F. Templin - Milestone: Nov 03 o Submit for Informational o Update milestone to Jan 04 - Status: Individual submission - Open Issues: o Discussion on mailing list o Will be discussed in w.g. meeting IPv6 Addressing Architecture - Editor: Bob Hinden - Milestone: (none) o Re-Submit for Draft Standard o New milestone Jan 04 - Status: Draft available - Open Issues: o Dependent on Site-Local deprecation o Will be discussed in w.g. meeting Work Not Started - ICMPv6 Update - Privacy Extensions Update - PPPv6 Update Textual Representation of IPv4 and IPv6 Addresses - Author: Andrew Main o <draft-main-ipaddr-text-rep-01.txt> - Fixes a long history of broken ABNF definitions of textual representations o Does not cover scoped address syntax or prefix length syntax - Important to get this right, to ensure correct parsing by UIs, etc. - Request: o Please read it & prepare for decision whether to adopt as WG item o Standards track vs Informational? Textual representation: ABNF already moved out of the Address Architecture specification some time ago. Jinmei: Textual representation has a relationship to address architecture. Hinden: No; this is dependent on address architecture, not the other way around. Carpenter: Talked to co-author (Zephram); ABNF definitions have been broken for awhile (including IPv4 dotted quad). ACTION: Chairs to send out note if anyone implements an ABNF parser. --------------------------------------------------------- Local Communications Goals, Tony Hain & Fred Templin (15 minutes) draft-hain-templin-ipv6-localcomm-03.txt Goal: discussion of open issues --------------------------------------------------------- Hain : People want to tell other people how to run their networks. Not IETF business. Keith Moore: IP tells people how to run their networks. People who misuse IP can cause harm. Fred Templin gave remainder of presentation. --------------------------------------------------------- Tunnel MIB, Dave Thaler (10 minutes) draft-thaler-inet-tunnel-mib-00.txt Goal: overview of proposal, adopt as WG item? --------------------------------------------------------- Savola: have you thought about what kind of IANA registry you want to have? Dave: rules should be identical to what you need to do to get an iftype value (treat iftype the same as tunneltype). Haberman: Should ipv6 adopt this document? Chairs call the question. No objection to making this a working group item. ACTION: Next version of <draft-thaler-inet-tunnel-mib-00.txt> will be an IPv6 working group document. --------------------------------------------------------- Proxy RA, Dave Thaler (10 minutes) draft-thaler-ipv6-ndproxy-01.txt Goal: status update, adopt as WG item? --------------------------------------------------------- Dave Thaler gave presentation. Itojun: You propose to add MTU option, what is the relationship with this modification and IPsec or SEND? Dave: If there are any security parts of the RA, they are stripped (unsecured RA), or we ignore it. It looks like a router that doesn't implement SEND to hosts. Dave tends to agree with Brian Carpenter that this should become Informational, not PS. Any opinions? Droms: Any interoperability issues? Or does this merely define how a device would implement this function. Dave: mainly the router. Trying to show that you can do this without NAT. Huitema: what about spanning tree? Dave: Optional; don't always need loop prevention. Dudley: Important to default (Spanning Tree) to on. For those links that have the requirements, should it be used as default. Dave: Yes. Haberman: Any objection to adopting this document as a w.g. document for the ND proxy work item, as informational. No objections. Adopt as a working group document? For Informational. No objections. ACTION: Next version of <draft-thaler-ipv6-ndproxy-01.txt> will be an IPv6 working group document. --------------------------------------------------------- ICMPv6 Updates, Bob Hinden (10 minutes) draft-ietf-ipngwg-icmp-v3-02.txt Goal: status update --------------------------------------------------------- Savola: Should we redo the w.g. last-call? Hinden: Yes, when new draft is out. Also, do we have to redo the implementation reports? Hinden: Need to look at that and check with the ADs. Chown: Extra ICMPv6 type: Site Exit Routers suggested in multi6. Should we add that in this document? Hinden: Not sure we should do it now; it can use experimental types. Haberman: Same issue with MLDv2 spec. Could have requested a code from IANA without any IETF action. Multi6 could go request a type on their own (at least until we change the IANA policy in this document). Question: Who is the editor. Hinden: Currently I am, and we are working for new editor. If interested, please contact the chairs. ---------------------------- Wednesday, November 12, 2003 ---------------------------- --------------------------------------------------------- Router Selection, Dave Thaler (10 minutes) draft-ietf-ipv6-router-selection-02.txt Goal: issue discussion, next steps --------------------------------------------------------- Savola: Don't use uppercase "may" in last guideline on slide 5. Thinks it is a misuse of terminology. Narten: Recommendations for operators or implementors. A: Operators. First three will be lower case, last will be upper case. --------------------------------------------------------- Neighbor Discovery Updates, Tatuya Jinmei (15 minutes) draft-soliman-ipv6-2461-bis-00.txt Goal: issue discussion --------------------------------------------------------- security/mobility issues raised bug fixes, increase clarity goal is another Draft Standard RFC restrictions on new functionality Updates to RFC 2461 (Hesham primary editor) 1) mixed host/router behavior (on diff interfaces) Proposal: state distinction is per interface Templin: can you have a router with 1 interface? A: Yes 2) what if pref life > valid life? Proposal: MUST NOT send 3) onlink assumption considered harmful Proposal: remove this assumption 4) router lifetime values "inconsistencies". Does >18.2 hours violate spec? Proposal: allow any value up to 65535, don't change sending behavior in section 6 5) clarify M/O flags in context of DHCPv6 Proposal: say stateful for M is RFC 3315 need similar reference for O Greg Daley: dependency issues, O reference is just a draft 6) what happens if host receives prefix length > 64 Proposal: ignore and assume a 64-bit prefix? to be discussed on list 15) do we have to mandate link-local addresses as source in redirects? Proposal: yes, no change 7-9 are security issues Proposal: add a section on securing ND and refer to SEND for dynamic security expand security considerations section based on send-psreq draft add discussion on manual vs dynamic keying, currently vague 13) omission of prefix options considered harmful Proposal: handle with ND extensions for movement detection not in this spec 14) introduce globally unique link id for movement detection Proposal: handle with ND extensions not in this spec 10) relax requirements on RA frequency to allow 50ms Proposal: allow, but not sure if safe 11) remove random delay in MNs before RS Proposal: change 6.3.7 to allow no delay if know a hand-over (not startup, etc) has taken place 12) remove random delay in routers before RA Proposal: draft-mkhalil-ipv6-fastra-* Kempf: issues raised, may not want in this spec Narten: legitimate for mobility but need to look at as part of the whole problem useful to talk about in DNA, wary of changing this spec. Bound: Agree w/ Narten. Just pull these from the recycle issues and move forward. Narten: put them on hold, don't adopt them at this point may adopt them later if get resolution when document is still open Nordmark: #11 need to explain motivation for delay... power failure case clarifying intent may help the other discussion. Kempf: talk to security AD on 7-9 Daley: interested in looking at issues in DNA but not committing Huitema: don't add anything, have implementation experience with current draft and want to keep moving forward Narten: don't make specific changes now Itojun: limit to clarifications, don't introduce new stuff 15) remove delay before NS Proposal: discuss 18) add R/H flags per MIPv6 spec Proposal: accept Mobility: Clarifications now, but not new features. Limit effort to clarification.. --------------------------------------------------------- Stateless Autoconfiguration Updates, Tatuya Jinmei (15 minutes) draft-jinmei-ipv6-rfc2462bis-00.txt Goal: issue discussion --------------------------------------------------------- Some issues already have consensus on list others: 6) src addr selection issues: prefer link-local vs deprecated Proposal: add reference to RFC 3484 7) deprecated addr handling, semantics of "new" communication consensus: incoming TCP connection is not "new" Proposal: use text proposed on list also talk about case where application specified deprecated address 8) semantics of L=0 A=1 case (addr configurable but not on link) Proposal: no change 9) stable storage for auto-configured addr for stability Proposal: mention it but not mandate 10) issues raised in send "use IPsec" is not enough Proposal: add summary to security considerations, no change in protocol 11) DAD for 802.11 2462 says don't drop just because Llayer source != receiving node 802.11 doesn't meet this Proposal: add note in Appendix A and reference draft-park-ipv6-dad-problem-wlan Suggestion was made to have an IPv6-over-WiFi specification. 12) conflict with MLD spec re random delay for first packet 2462: if NS for DAD is 1st pkt, random delay MLD report is usually the first packet Proposal: just add a note? not a problem in _this_ spec Dino: so don't send MLD reports for link-local addresses Daley: that would break things 13) DAD relayed issues: dad delay, random delay, how optimize dad spec: SHOULD do DAD for every unicast addr MAY skip DAD in some cases should we remove the MAY? Proposal: DAD optimization is a separate draft need discussion on list 15) semantics of M/O what requirement keyword, and specify DHCPv6? Proposal: should mention DHCPv6, need to discuss details 16) whether a non-host router can use autoconf a) configure a global addr b) configure a link-local addr c) configure itself about "other" information Proposal: a=NO, b=YES, c=NO Haberman: clarification - you mean per-interface definition right? Jinmei: yes 17) 'not-yet-ready' status of an autoconf addr for renumbering can deprecated addr be used? Proposal: out of scope of this update, specify as extension 18) avoiding intf failure on DAD failure 2462: SHOULD be disabled if no link-loc addr Proposal: SHOULD but MAY allow automatic recovery 19) 2462 requires a 64-bit ID same issue as 2461 no suggestion so far Proposal: discuss on list Itojun: is there an issues list page? ?: #13 what do you mean by "strict" Jinmei: force DAD not DID #18 MIPv6 suggested 3041 id in this case, should 2462 suggest A mechanism? Hinden: need to be careful making changes Huitema: #18 is really a security violation, bad guy can disable everyone's interfaces. Chairs called question of making ND and Addr-Conf w.g. documents. No objections . Next version of drafts will be w.g. documents. ACTION: Next versions of <draft-soliman-ipv6-2461-bis-00.txt> and <draft-jinmei-ipv6-rfc2462bis-00.txt> will be IPv6 working group documents. --------------------------------------------------------- Scoped Address Arch Document, Tatuya Jinmei (10 minutes) draft-ietf-ipv6-scoping-arch-00.txt Goal: discussion of last call comments --------------------------------------------------------- last call issued Oct.22 most issues have consensus on list Default zone ID value draft suggests but does not require 0 issue: MIB needs 0 Proposal: SHOULD use zero Thaler: why SHOULD and not MUST? (for MIB compliance) Haberman: just make sure MIB and this doc agree Itojun: can we get implementation reports and if no one uses non-zero then can use MUST Alignment with draft-main-ipaddr-text-rep Proposal: add a reference to the text-rep draft normative or informative? Haberman: make sure reference looks like the ref in the addr arch doc (informative) number of authors > 5 default zone ids for "subnet-local" multicast scope Proposal: remove subnet-local, already removed from 3513 and addr-arch-v4 references ICMPv6 update as a normative reference shouldn't be a problem (do concurrently) --------------------------------------------------------- Site-Local Deprecation Document, Christian Huitema (20 minutes) draft-ietf-ipv6-deprecate-site-local-01.txt Goal: discussion of last call comments --------------------------------------------------------- Huitema was called up to discuss, no slides two main comments 1 (Pekka etc) more text about why NAT is bad, e.g. from Margaret SL-IMPACT Proposal: OK 2 recommendation for deprecation current: existing behavior MUST be ignored by any new implementation Q: what is a new implementation, is there a flag date, what if shipping both old and new versions, etc one way: write weasel text other way: replace MUST by SHOULD (Huitema prefers this) rationale: writing more text doesn't help Hinden: Thinks current text is just fine. Carpenter: tends to agree with hinden, IETF doesn't have a clear procedure for versioning. No objection to SHOULD but like it with no changes. Leave it up to the implementor how to handle Nordmark: may be helpful to add a sentence to state the intent? Huitema: we already say that Hinden consensus summary: Leave deprecation text as is and bring in two paragraphs from Margaret's document. Haberman took consensus call: Any objection? No ACTION: Chairs will advance <draft-ietf-ipv6-deprecate-site-local-01.txt> when next version of draft is out. --------------------------------------------------------- Unique Local Addresses Document, Bob Hinden (15 minutes) draft-ietf-ipv6-unique-local-addr-01.txt Goal: discussion of last call comments --------------------------------------------------------- Last call started Oct.22 Hinden is active author, Haberman is shepherding chair Need for ULAs need to provide for local disconnected/intermittent allocation Proposal: yes, better than other known alternatives Huitema posted summary to the list of alternatives and problems with them Application handling? do applications need special knowledge about these addresses? not introduced by this type of address, also applies to firewalls etc useful to investigate general solutions to this class of problems impact to source/destination addr selection? will longest match rules just work? provide more feedback via ICMP errors Moore: agree don't burden address scheme with this need to change address selection to get other things to work it's hard enough to get address selection right, will probably have to change it anyway Nordmark: ULAs are different than filtering etc, they're not reachable by design Moore: by design they're not globally reachable, but it's a stretch to say they're not reachable by the peers of interest. Don't want applications to assume they're not reachable if not global Nordmark: wrong impression is dangerous Moore: hard enough to get right Itojun: agree with Nordmark Daley: this is a routing problem, why not just send destination unreachable Hinden: see later slide, discussed later in the talk. Leakage Doc provides reasonable measures to prevent most leakage Uniqueness minimizes impact Leakage also affects firewalled addresses, etc ULA is a good tradeoff among alternatives Itojun: different types of filtering (e.g. don't advertise routes, do advertise and filter data, etc) Charging, IANA instructions IETF documents can't specify a specific charge or use of revenue Proposal: remove 10 Euro and say low cost and intent to prevent hoarding Geoff Huston (who raised issue) is okay with the new proposed text. Filtering black holing has bad side effects Proposal: MAY respond with ICMP admin prohibit Savola: is MAY strong enough? Hinden: isn't ICMP always a MAY? should be consistent with other places Savola: then change to SHOULD Hinden: OK Itojun: if we don't advertise then who will send admin prohibited Thaler: diff subtypes for different filtering methods Iljitsch van Beijnum: New ICMP message for source not right? Haberman: scope exceeded does that Iljitsch: is "scope" global here? Moore: three cases 1) trying to send out to global internet 2) trying to send to a ULA with no route 3) filtering between two local networks Carpenter: ICMP is likely to cross admin boundaries which may block ICMP not bad to define but can't rely on them arriving Moore: can be defined and work most of the time Alternative random algorithm Proposal: make sure others are allowed Best name Proposal: take to list Haberman: prefer really cool acronyms :) Propose to make the changes discussed and advance? Chown: language says need globally unique, but is probabilistically unique should be more clear Haberman calls for consensus: Any objection to proposed changes? No? Submit to IESG with changes? Yes? Moore: clarification - will revised document redo WG last call? Haberman: we could have 1 week last call Itojun: please ask whether we need another last call Wasserman: yes Iljitsch: locator/identifier separation work coming, not sure we should standardize something different Hinden: Not advisable to wait Narten: Right Carpenter: sentence used to be there "might be useful for Multihoming too" make sure it's out. Hinden thinks it's already out. Iljitsch: are they unroutable by design or by lack of a way to do it? so clarify. Hinden: says "not routable with currently technology" or something Kurt Lindqvist: don't wait Wasserman: there's no conflict with locator/identifier work ACTION: Chairs will start short working last call for <draft-ietf-ipv6-unique-local-addr-01.txt> when new draft is available. --------------------------------------------------------- Address Architecture Update, Bob Hinden (15 minutes) draft-ietf-ipv6-addr-arch-v4-00.txt Goal: review changes and plan for moving forward --------------------------------------------------------- site-locals removed from special list of prefixes added text describing SL deprecation added instructions in IANA considerations to reserve and not reassign changes dependent on approval of SL Deprecation document changes due to IAB recommendations 2.5 nodes shouldn't make assumptions about address structure 2.5.1 nodes aren't required to validate that u=1 is unique --------------------------------------------------------- Identifier/Locator Separation, Kurt Lindqvist (10 minutes) --------------------------------------------------------- Multi6 WG update A number of proposal (6 active drafts, more expired) many/most split identifier (who) and locator (where) semantics and syntax vary for most, locators are todays IPv6 addresses impact: - We will not turn off ipv6 :-) - All proposal will try to have no impact on ULPs - Most involve a shim layer between ULPs and IP considerations: - secure mapping of id<->locator - goals are in RFC 3582 - more operational considerations being written (current drafts from Nordmark, crocker) Itojun: SONY LIN6 draft mentions patent pending, so may be IPR issues ---------------------------------------------------------------- Meeting Adjourned ----------------------------------------------------------------
