IPv6 Working Group Meeting Minutes London IETF August 8 & 10, 2001 Chairs: Bob Hinden / Nokia Steve Deering / Cisco Meeting minutes taken and edited by Bob Hinden Slides available at http://playground.sun.com/ipng/meetings.html ------------------------------------- Agenda: Introduction / Steve Deering (5 min) Review Agenda / Steve Deering (5 min) Document & Charter Status / Bob Hinden (10 min) 3GPP-IETF Design team status / Bob Hinden (10 min) Requirements for IPv6 dialup operation / Jun-ichiro itojun Hagino (15 min) Avoiding ping-pong packets on point-to-point links / Jun-ichiro itojun Hagino (10 min) Multilink Subnets / Dave Thaler (20 min) DHCPv6 Status and Last Call / Ralph Droms (10 min) Minimum IPv6 Functionality for a Cellular Host / John Loughney (25 min) AAAv6 Status / Charlie Perkins (5 min) IPv6 Site Renumbering / Christian Huitema (20 min) Source/Destination Address Selection / Brian Zill (15 min) Domain Name Auto-Registration for Plugged-in IPv6 Nodes / Hiroshi Kitamura (15 min) A proposal for the IPv6 Flow Label Specification / Alex Conta (30 min) DNS Discovery / Dave Thaler (20 min) An analysis of IPv6 anycast / Jun-ichiro itojun Hagino (10 min) Disconnecting TCP connection toward IPv6 anycast address / Jun-ichiro itojun Hagino (10 min) IPv6 MIB Update Status / Bill Fenner (15 min) nnnn=2096,2011,2012,2013 Socket API for IPv6 traffic class field / Jun-ichiro itojun Hagino (5min) Status of Linux and USAGI IPv6 / Yuji Sekiya (5 min) ----------------------------------------------------- WEDNESDAY, August 8, 2001 1300-1500 ------------------------------------ Introduction / Steve Deering Review Agenda / Steve Deering ----------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Steve Deering introduced meeting and reviewed agenda. Document & Charter Status / Bob Hinden -------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] DOCUMENT STATUS RFC's Published RFC3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (Proposed Standard) IESG Approved Transmission of IPv6 Packets over IEEE 1394 Networks (Proposed Standard) IETF Last Call completed RFC2372 IP Version 6 Addressing Architecture (Draft Standard) New version submitted (-06), waiting for IESG response RFC2374 An IPv6 Aggregatable Global Unicast Address Format (Draft Standard) Revision underway IPv6 Node Information Queries (Proposed Standard) Updated draft issued, check for consistency w/ Multicast DNS and DNS Discovery, then new IETF last call will be started Submitted to the IESG Unicast-Prefix-based IPv6 Multicast Addresses (Proposed) In IETF Last Call A flexible method for managing the assignment of bits of an IPv6 address block (Informational) Undergoing IESG review, some comments expected IPv6 multihoming support at site exit routers (Info) Pseudo-last call in Multi6, then to IESG, expected to be published IPv6 Multihoming with Route Aggregation (Info) Contact author, if interest, submit to Multi6 IPng Working Group Last Call Completed Default Address Selection for IPv6 New draft based on w.g. comments, to be discussed at w.g. meetings Open issue standard track, Must/Should, etc. Basic Socket Interface Extensions for IPv6 (Info) On hold for updates based on last call comments Documents Ready for Working Group Last Call Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (Draft standard) Discussion: A couple comments have been received on latest draft. Will start WG last call to solicit any additional comments and then submit to IESG. [Editor's note: Based on later discussion, the w.g. last call will be deferred until after a new version of the draft is published with additional text] IPng Working Group Documents Ready for Draft Standard IPv6 over Ethernet IPv6 over FDDI IPv6 over Token Ring IPv6 over ARCNET IPv6 over PPP Implementation reports for candidates for Draft Standard needed http://playground.sun.com/pub/ipng/implementation-reports/templates/ NEW CHARTER STATUS - Revised charter submitted to IESG - New Charter approved! o Official announcement after London IETF - Working group name changed from: IP Next Generation (IPNG) to IP Version 6 (IPv6) - Updated work items, milestones, etc. WORK ITEMS - Revise and advance to Draft Standard the IPv6 Address Architecture document [RFC 2373] - Revise IPv6 Aggregatable Unicast Addresses [RFC 2374], removing the policy aspects that are considered RIR issues. - Complete work on recommended address-selection algorithms - Revise ICMPv6 spec [RFC 2463] (scope-exceeded err, no error to redirect, editorial) - Revise Generic Tunneling spec [RFC 2473] (add bidirectional tunnels) - Update Basic and Advanced API specs [RFC 2553, RFC 2292] - Complete Scoped Address Architecture spec and any necessary revisions to other working group drafts required to properly implement support for IPv6 address scoping - Work on host-based solutions to site-multihoming problems (in coordination with multi6) - Complete work on local IPv6 networking as part of IPv6 plug-and-play (to be coordinated with other WGs as appropriate, e.g., dnsext, zeroconf, etc.) - Document IPv6 renumbering model - Complete the IPv6 Node Information Queries spec - Revise and update the base IPv4/IPv6 MIBs and produce a new consistent set of MIBs that cover IPv4 and IPv6 together GOALS AND MILESTONES Jun 2001 Revise IPv6 Address Architecture and resubmit to IESG for Draft Standard Jul 2001 Revise IPv6 Aggregatable Unicast Addresses and submit to IESG Jul 2001 Resubmit the IPv6 Node Information Queries spec Aug 2001 Compete Address Selection specification and submit for Proposed Standard Dec 2001 Update ICMP document and resubmit for Draft Standard Dec 2001 Complete DNS Discovery draft and submit for Proposed Standard Dec 2001 Update Generic Tunneling specification and resubmit for Proposed Standard Dec 2001 Complete updates to Basic and Advanced API specifications and submit for Informational Mar 2002 Complete Scoped Address Architecture and submit for Proposed Standard May 2002 Submit document describing IPv6 renumbering model for Informational. 3GPP-IETF Design team status / Bob Hinden ----------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] BACKGROUND - Output of joint IPng w.g. and 3GPP session at interim meeting in Redmond - Goals o Review 3GPP's current usage of IPv6 and make recommendation for improvements o Write ID to be submitted to IPv6 w.g. - Non-Goals o Redesign of 3GPP architecture / protocols o Non-Goal example: Change 3G mobility to use Mobile IPv6 MEMBERS - Bob Hinden (Chair) - Steve Deering - Karim El-Malki - Paul Francis - Christian Huitema - Niall Richard Murphy - Thomas Narten - Erik Nordmark - Markku Savela - Jonne Soininen - Margaret Wasserman (Document editor) TOPICS - Allow use of standard IPv6 implementations - Addressing o Single address per PDP context (current) o Prefix per PDP context - Per device - same prefix for all PDP context's for same device - shared among PDP context's for many devices o Node able to create multiple addresses o Static or temporary IPv6 addresses TOPICS (CONTUNED) - Model for support of devices behind handset o Router, bridge, proxy - DNS o Locating a DNS server o Handset address in DNS - Security - MTU - Issues left to implementers in 3GPP specifications TOPICS (CONTUNED) - Transition o IPv6 only, dual stack, etc o Communication with IPv4 internet - Remote Management o MIB support Multilink Subnets / Dave Thaler ------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Discussion: "Transmit" means not forwarding between different subnets, but does allow multi-link forwarding. Need to mention in draft if in the future we are able add security to ND, this might have issues. Thaler proposes to describe simple and complex in main draft, but only specify simple behavior. Would like this draft to become a working group document. Continue complex work in a separate document. Nordmark: There might be issues about learning about looping topologies. Current ND default advertisements might be too slow. Deering: Looks good. Wants it to not have any configuration. Comment: Site typically have IPv4 subnets. How does this relate to this? Thinks it might make it match and not diverge. Also, is this a sub-ip effort. Prefers to do this at the IP level. Wasserman: How does the router figure out how router learns about hosts on a link. Send ND on both links and learn answer. Also, is this different from proxy arp. Not significantly different, but proxy Arp doesn't allow multiple levels. Deering took poll if this should become a w.g. draft. Rough consensus to become a working group draft. ACTION: Next version of "Multilink Subnets" should be published as a working group draft. Requirements for IPv6 dialup operation / Jun-ichiro itojun Hagino ----------------------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] What is experience so far with dialup support in IIJ? Problem is that can not deploy dialup nationwide in IIJ. What are speakers preference of different options? Five different options. Not sure what is best. There are different scenarios that are appropriate. Deering: Good to get feedback from operational folks. Itojun: Has asked Japan operators forum. Can this be a w.g. item. Chairs thought it should be standards track. Not sure it should be IPv6. Need to discuss. ACTION: Chairs to talk to area directors to see what is best w.g. to take dialup operation requirements and move it forward onto standards track. Avoiding ping-pong packets on point-to-point links / Jun-ichiro itojun Hagino ---------------------------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Perry: This function needs to be a MUST. We need to make our equipment more robust. This is showing in IPv4 due to the CODE RED attacks where the attack is sending packets to random addresses. Packets will loop on point-point link with IPv4. This is creating a lot of needless load on routers. Deering: Thought this behavior should go into ICMPv6 specification. Perry: Should this also be done for IPv4? Yes, but this needs to be done elsewhere in the IETF. Is this limited to other types of link. No, this is only need on links where address resolution is not needed. Usually this means only point-to-point links. Deering took poll to see if this should be added to ICMP draft and be a MUST requirement. Consensus to do this. ACTION: Deering to add rules to prevent ping-pong packets on point-to-point links to ICMPv6 draft. ACTION: Once new draft IPCMPv6 draft with new text on "ping-pong" packet rules is completed, Document editor will start a working group for Draft Call (cycle in place). DHCPv6 Status and Last Call / Ralph Droms ----------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Expect to have new draft (-20) completed before the end of August and submit to w.g. last call afterwards. Wants IPv6 w.g. review as part of last call. Will also post announcement to ipng mailing list. Minimum IPv6 Functionality for a Cellular Host / John Loughney -------------------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Comments: Deering mention real issues are not that devices that are cellular and wireless, but that links are "expensive to use". Better approach is to describe by type of link as appropriate. Other issues might be memory limited. etc. Metzger: Need to also discuss DOS attacks. Is in document, know it is an important attack. Hesshim: Questions about meaning of intra-domain. Overall authors are Looking for comments from w.g. Can this be considered as a w.g. draft? Questions: Perkins: What is the relationship to design team? Thinks this spec is more immediate work than what the design team is focused on. Also, what is requirement for how much IPsec is needed? Plans to talk to IESG security ADs. Was QOS or voice service included in the draft. Thinks it is not IPv6 specific so did not include in this draft. Wasserman: Thinks the design team is trying to do something quickly. Also, isn't this the start of an IPv6 host requirement document? Yes, it could be. Soininen: Thinks this document is important. Design team should review document and provide comments to authors. Why was AAA not included? Thinks authentication is important. Comment that this is a useful draft, but see it separate from design team. Deering thinks this we need to think about if it should be generalized or just focused on cellular before we can think about making it into a w.g. document. Socket API for IPv6 traffic class field / Jun-ichiro itojun Hagino ------------------------------------------------------------------ [Slides available at http://playground.sun.com/ipng/meetings.html] Want to know how to proceed. Add to current API document or be a separate document. Nordmark: There is work going to update "Advanced Sockets API for IPv6". How to get consensus on changes? Discussion. Should be in advanced API update. No disagreement from w.g. about adding it to advanced API. Deering took poll. Will be added to advanced API update. AAAv6 Status / Charlie Perkins ------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Wants IPv6 w.g. to take a look at new AAA document. Does IPv6 w.g. think this should this work go forward into AAA w.g.? Chairs don't think this is IPv6 specific. W.g. thinks this work should go on but not in IPv6 w.g. Hinden suggested that Perkins send email to list describing problem and ask opinion on open issues. It is important to get feedback from the IPng w.g. FRIDAY, August 10, 2001 0900-1130 ----------------------------------- IPv6 Site Renumbering / Christian Huitema ----------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Wants to get agreement on renumbering scenarios and then do a detailed analysis of each scenario to make sure we have the right tools to make these scenarios work. Then develop missing tools, publish as a BCP, etc. Demonstrate at IETF, Interop, etc. Discussion: Itojun: Important to also specify times, frequency, etc. Deering: Multi6 has defined some of these scenarios as part of multihoming. Some of these scenarios can be handled with multihoming mechanisms. Also, thinks it is hard to enumerate all of the places that configure IP addresses. Bill Manning: Almost identical to what the pier w.g. was trying to do. Missing network management. Need to also fix MIBs to work without IP addresses. IP address is the identifier. Thinks this is hard to change. No clear consensus as to how much renumbering is good or how automatically it should be. Author will continue working in this area. Discussion: lots of different views as to merits of renumbering. AD-Hoc Interop Test Report / Brian Zill --------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] ~20 people, 7 implementers 12 subnets, 4 different routers Tested: ND over configured tunnels (no defined v4 LL options) Node information queries ISATAP Dynamic NDS registration of AAAA DNS v4/v6 self proxy RIPng ping-pong problem on point-to-point links Source/Destination Address Selection / Brian Zill ------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Reviewed open issues in draft. Discussion: Deering: There was a discussion after the interim meeting presentation on MUST vs. SHOULDS. Thinks it might be better to split document between protocol and policies. Zill: Disagrees, in current draft the MUSTs are there to make sure it interoperates. The issue probably relates to the SHOULDs. Thinks it would be hard to separate these things outside of draft. Narten: Suggested that the document should call out that implementers should be aware that some of the SHOULDs may change and they need to make sure that their implementations can change later if necessary. Nordmark: Would like to keep to a single document. More discussion. Deering: Any objections to keeping as single document? May need to restructure later when moving to Draft. General consensus on keeping as single document and advancing to proposed standard. ACTION: Document editor will submit "Source/Destination Address Selection" to IESG for Proposed Standard when new draft is published. Domain Name Auto-Registration for Plugged-in IPv6 Nodes / Hiroshi Kitamura ------------------------------------------------------------------ [Slides available at http://playground.sun.com/ipng/meetings.html] Discussion: Gudmundsson: Likes what this is trying to do. One problem, DNS will get filled up with lots of garbage if you have lots of visiting nodes. Thinks part of this draft should be handled in DNS-EXT w.g. People in DNS community also have strong opinions on who can register information in DNS. Zill: Thinks DNS discovery draft provides DNS name search. Doesn't like the approach in this draft because it adds too many boxes. We are trying to make IPv6 work w/ less boxes. There may be a problem with multiple zones sharing same link? Nodes do not want their temporary addresses registered in DNS. Deering: Thinks work would be better handled in DNSEXT w.g. Need to talk to chairs. No action for IPv6 w.g. at this time. A proposal for the IPv6 Flow Label Specification / Alex Conta -------------------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Questions: Why is this needed given we already have a "class" field in IPv6. A: This would allow classifying of finer grained flows that diff serv can do currently. How do you know that information node is putting correct information in the field? It could be lying. This is different from what nodes can do today and it makes it easier to have a flow label that gets better performance than the use of the ports would allow (without both ends cooperating). Deering: Proposing to change the flow label field to allow router to set the class field in the header. This is a layer violation. Thinks this will create many unanticipated consequences. What you are trying to achieve can be done in simpler ways. Use class field to identify type of service and flow label to identify individual flows. Discussion. Disagreement about cost of handling random flow labels vs. this proposal. Discussion..... Comment that if there was a need to have port number in IP header, then we would have put them in the first place. As long as some sort of signaling is needed to install state in routers, then the current flow label definition is OK. Further discussion on mailing list. DNS Discovery / Dave Thaler ---------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Changed use of SRV DNS record to TXT records. Questions about having multiple domains on the link. Not handled in current proposal. Narten: Nervous about using text records. Doesn't think TXT records are uniformly implemented. Wasserman: Why is this using site anycast? How to find DNS server in ISP? A: This is covered in the draft as how to have the site router proxy to the ISP. Matt Crawford: Draft is currently assuming that the subnet boundary is a multiple of four bits. Might need finer grained queries. Should be addressed in draft. Discussion. Austein: Please do not use TXT. Not good to standardize. Better to have new record type. Erik G: Suggestion that we make the use of TXT record a standard for this usage. Rob: Heading down road of standardizing general format that will encourage considerable conflicting abuse. Continue work, but needs more work to get convergence. An analysis of IPv6 anycast / Jun-ichiro itojun Hagino ------------------------------------------------------ [Slides available at http://playground.sun.com/ipng/meetings.html] Would like to publish as an informational RFC. Queried room, no disagreement. ACTION: Document editor will start a working group last call for to publish "An analysis of IPv6 anycast" as an informational RFC. Disconnecting TCP connection toward IPv6 anycast address / Jun-ichiro itojun Hagino ---------------------------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Discussion: Does per-address notification, this will also effect UDP traffic. May need different type of notification. Usage of address unreachable is not correct, as address was reachable. Deering would like to be able to open a TCP connection to an anycast address and get the unicast address(es) back to continue the connection. Itojun: Beyond the scope of the draft (in anycast analysis doc). This draft is about returning error messages. Dave Thaler: Doesn't think this is TCP specific. Should be expanded to also cover other protocols. While most UDP applications don't need this, some do. Good to expand to cover UDP and other protocols. Author will revise document and ask for comments. IPv6 MIB Update Status / Bill Fenner nnnn=2096,2011,2012,2013 --------------------------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] Deering: Timetable? TCP/UDP MIBs should be done in a few months. IP MIB will be harder and take longer. Deering suggested setting deadlines. Are there plans to do other MIBs for IPv6 specific items. Many of these things are in the new IP MIB. Status of Linux and USAGI IPv6 / Yuji Sekiya -------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] ------------------------------------------------------------------------ Meeting Adjourned ------------------------------------------------------------------------