IPng Meeting Minutes San Diego, IETF December 13, 14, 2000 Bob Hinden, Nokia Steve Deering, Cisco Chairs ------------------------------------------------------------------- Agenda ------ Introduction / S. Deering Review Agenda / S. Deering Document Status and Charter Status / B. Hinden Summary of Internet Address Registry Presentations / Alain Durand Source/Destination Address Selection / Rich Draves An analysis of IPv6 anycast / Itojun Hagino Analysis of DNS Server Discovery Mechanisms for IPv6 / Dave Thaler Discovery of Resource Records Designating IPv6 Address prefixes / Matt Crawford Socket API for IPv6 traffic class field / Itojun Hagino Default Router Preferences & More Specific Routes in RAs / Rich Draves Automatic Prefix Delegation Protocol for IPv6 / Brian Haberman Destination Option Headers Cleanup / Francis Dupont An end-to-end usage of IPv6 flow label / Jochen Metzler Socket API for IPv6 flow label field / Itojun Hagino Multihoming / Masataka Ohta Record Route Hop-by-Hop Option for IPv6 / Hiroshi Kitamura ETSI bake-off report / Francis Dupont Overview of USAGI Project (Linux IPv6 Improvement Project) / Yuji Sekiya Site renumbering using router renumbering protocol / Tatuya Jinmei How to write UDP/IPv6 applications that care about path MTU / Tatuya Jinmei Status of OSPFv3 implementation for Zebra / Yasuhiro Ohara LIN6: Mobility Support in IPv6 based on End-to-End Communication Model / Fumio Teraoka -------------------------------------------------------------- Introduction / S. Deering ------------------------- Steve Deering opened the meeting, introduced chairs, etc. Review Agenda / S. Deering -------------------------- Reviewed agenda. Added short summary talk on IPv6 Multihoming meeting held on Tuesday. Document Status and Charter Status / R. Hinden ----------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html DOCUMENT STATUS RFC's Published - RFC2894 Router Renumbering for IPv6 (Proposed Standard) - RFC2928 Initial IPv6 Sub-TLA ID Assignments (Informational) IESG Approved - IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol (Proposed Standard) - Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (Proposed Standard) IETF Last Call completed - RFC2372 IP Version 6 Addressing Architecture (Draft Standard) o IESG want implementation of scoped multicast forwarding. o New draft issued w/ ABNF updates and IESG clarifications o Started new w.g. last call for Draft Standard o IPng w.g. last call completed, new draft, ready to submit to IESG o IETF Last Calling completed, waiting for a new ID, then IESG vote DOCUMENT STATUS IETF Last Call completed (continued) - RFC2374 An IPv6 Aggregatable Global Unicast Address Format (Draft Standard) o IESG want to wait for more operational experience (?) - IPv6 Node Information Queries (Proposed Standard) o Comments from last call - Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (Proposed Standard) o IESG Comments Submitted to the IESG - IPv6 Multihoming with Route Aggregation (Informational) o IESG comments o Next step??? - Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 (Informational) o IESG discussing security issues / conclusions o New Draft promised for April 2000 o Work in progress, new draft promised for August 2000 o Status???? IPng Working Group Last Call Completed - Transmission of IPv6 Packets over IEEE 1394 Networks (Proposed Standard) o Ready to submit to IESG ACTION: Document editor will submit "Transmission of IPv6 Packets over IEEE 1394 Networks" to the IESG for Proposed Standard. - IPv6 multihoming support at site exit routers (Informational) o Ready to submit to IESG ACTION: Document editor will submit "IPv6 multihoming support at site exit routers to IESG for Informational. - A flexible method for an IPv6 addressing plan (info) o Update (title change, perl examples), then new w.g. last call o New draft, start new working group last call The chairs would like the title changed to something that does not appear to be an address assignment plan and text stating this in the draft itself. ACTION: Document editor will start new working group last call "A flexible method for an IPv6 addressing plan" for informational. - IAB: The Case for IPv6 (Informational) o Comments to author, then IAB to submit to IESG o New draft o Waiting for IAB comments/changes? o IAB wants further work o ... Carpenter: no longer an IAB doc. Perkins: Could be taken on by NGTRANS working group. ACTION: Document editor will no longer report on status of the "IAB: Case for IPv6" to the IPng working group. The NGTRANS may pick up this document. 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 WORKING GROUP CHARTER STATUS - Revised charter submitted to IESG o Open issues o MIBs o Multihoming o ICANN language o Working with Internet AD's to revise MOBILE / WIRELESS IPv6 DEVICE DESIGN TEAM - Develop recommendations on how mobile / wireless devices should use IPv6 Include o IPv6 Protocols o Addressing o Security o Mobility o Network Management - Identify relevant specifications Multi6 BOF Summary / Thomas Narten ------------------------------------ Summary - Room too small, less than 1/2 people fit - Official chair got in 15 min late - Randy Bush ran meeting - Operators were present and actively participated - Outcome: o Interest to form w.g., homed in operations area o Develop charter o Initial document: taxonomy, problem statement, define goals o Mailing list: multi6@ops.ietf.org o Subscribe: multi6-request@ops.ietf.org Summary of Internet Address Registry Presentations / Alain Durand ----------------------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Summary of presentation made to recent Internet Registry meetings. Recommendation was accepted by RIPE NCC and APNIC. ARIN did not accept it and wants further discussion. Source/Destination Address Selection / Rich Draves --------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Source Address Selection Rules Nordmark: Rule 7 issue. Concerned that temporary addresses will break applications. Didn't think it should be in the default list of addresses to select. Selection should be very application specific and can't be in basic rules. Suggest that temporary addresses need specific rules to enable. Dupont: Also concerned with rule 4. Draves thinks that need to be controlled by API. Dupont: Raised thought that this should informational, not standards track. Draves thought that this was required for interoperability. Deering thought this was important to insure uniform operation. Should be on standards track. Bound: Suggest don't use phrase "route lookup". Also, had concern about rule 7 about temporary addresses. Would prefer that there be a client / server switch for this. Durand: Thinks rule 7 is application dependent. Needs per application control and should be in default list. Itojun: Thinks "must" items are there for interoperability. Others should be in host/router requirements. Carpenter: Doesn't agree with Dupont. Need to specify default behavior. Should be standards track. Other: Likes draft. Would like some simpler way of achieving these goals. Draves: Doesn't turn into too much code. Remaining issues - API (socket options?) for controlling mobility and privacy preferences o Home vs. care of address o Temporary vs. public addresses - Consolidate SrcLabel/DstLabel? - Last call Deering: Still open issues. Need to close issues on mailing list and then measure consensus on list. Want to move this forward before next IETF. An analysis of IPv6 anycast / Itojun Hagino --------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Discussion/questions about security issues and how to use IPSEC or not. Document needs to be clarified in several areas. Analysis of DNS Server Discovery Mechanisms for IPv6 / Dave Thaler ------------------------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Result of DNS Discovery design team. Deering: Wanted to get w.g. input on use of anycast. Is this a reasonable way to go forward on this approach. Polled group. Rough consensus on using anycast transport mechanisms. The design group will look at content approached based on using anycast for transport and will report back to working group. [Editor: Does site boundaries limitation cause problems with anycast (e.g., discovery message is sent from one site to another)?] Discovery of Resource Records Designating IPv6 Address prefixes / Matt Crawford ------------------------------------------------------------------ [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Next step is to update spec, then submit for informational. Discussion about why this needed to be a standard to insure interoperability. Took poll of w.g., very rough concerns for standards track. ----------------------------------------------------------------------- THURSDAY ----------------------------------------------------------------------- Introduced session. Chairs announced that they are considering having an interim meeting before the March IETF. It would allow more detailed discussion of important topics. Socket API for IPv6 traffic class field / Itojun Hagino ------------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] The need for traffic class API Hosts want to be able to mark Class and Flow Label bits in header. Discussion about default value. Either zero is OK or software can read initial value before setting and restore it. Also, no need for dealing with IPv4 TOS in IPv6 API. Default Router Preferences & More Specific Routes in RAs / Rich Draves ---------------------------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Changes: Add a two bit preference field Add Route Information Option Would like to get option type from IANA. Discussion: F. Dupont said he suggested this something like this in the early days of IPv6. Question about need for variable length of prefixes in option, vs. fixed length. Draves: draft only has three choices: 0, 8, or 18. This isn't too complex. Question about conception model. Should it be done in RA? PRF bits in RA Header change overlap multicast bits. Relation to Multi6 w.g. activity. They might end up with something similar. There might be multiple administrators who are not cooperating setting these bits. Might be an issue here. Deering: Ideas has been around for a while. Most concerns raised previously have been addressed (e.g., full routing tables not sent), concern that this puts more manual configuration in hosts, etc. Hinden: Liked idea, but has concerns about how to set the preferences. Too many conflicting scenarios. Deering took poll to see if this should be a working item. Group consensus that work should continue but it is too early to decide if it should be a w.g. document. Automatic Prefix Delegation Protocol for IPv6 / Brian Haberman -------------------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Describing work outside of IETF dealing with home networking. Wants advice from w.g. about what way to go. Deering: Important to make sure that router always gets the same prefixes. IPv6 addresses need to be long lived. Third parties make this harder. How big a prefix? This is an open issue. Matt Crawford: Didn't see a focus on which part of the problem this was addressing. Lots of details to resolve. Brian Carpenter: Do you have any feedback if they might be interested. Need to consider DNS issues as well. Destination Option Headers Cleanup / Francis Dupont --------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Deering asked why speaker said the destination option was a "nightmare". Dupont: because that the destination header can occur at different places. Deering answered that this is the way that IPv6 was designed. Dupont doesn't think that this freedom is useful. Zill: We should design the API around the protocol, not the protocol around the API. Deering: Important to keep flexibility to allow new uses as new applications are conceived/developed. Deering does not understand the need for this approach. Dupont want there to be more structure in destination header placement. Bound: Also doesn't think we should change the protocol to match the API. [Editor: ran out of time, stopped presentation/discussion, but there didn't see to be much support for this proposal] An end-to-end usage of IPv6 flow label / Jochen Metzler ------------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Question from 3GPP on the use of the IPv6 flow label for bearer identification. Current definition of flow fits well with 3GPP definition of bearer service. Alex Conta: Question that if application assign flow label, how does the network know what the flow label means. Network can learn that application wants all the packet with the same label to be treated the same. Discussion... Bound: Needs more overall solution, need to think about whole problem, and needs to use integrated services to handle this. 3GPP usage: Wants to be able us flows labels to identify end-end flows. Would require some sort of signaling to tell what flow label means. Routers can not change flow labels. Conta: Can change flow labels in network, but still change them. Want topic discussed at interim meeting. Deering: Thinks that there is interest in standardizing usage of flow label. Discussion...... Nordmark: Instead of talking about solution, would like to see what problems need to be solved. Deering: Agrees, we need to focus on the problems and should discuss at an interim meeting. [Editors note: if discussed at interim meeting, make sure transport people are involved] Socket API for IPv6 flow label field / Itojun Hagino ----------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Deering: Good work, but can't define API until after we define what flow label is. Multihoming / Masataka Ohta ------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Chairs suggest that this work be moved to the new IPv6 multhoming w.g. Record Route Hop-by-Hop Option for IPv6 / Hiroshi Kitamura ---------------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Comments. Alain Durand seems like proposal made last year. Had denial of service attack problem. Crawford: Doesn't think compression is necessary. Deering asked people to comment on mailing list. ETSI bake-off report / Francis Dupont ------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Overview of USAGI Project (Linux IPv6 Improvement Project) / Yuji Sekiya ------------------------------------------------------------ [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Site renumbering using router renumbering protocol / Tatuya Jinmei ------------------------------------------------------------------ [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] How to write UDP/IPv6 applications that care about path MTU / Tatuya Jinmei -------------------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] Status of OSPFv3 implementation for Zebra / Yasuhiro Ohara ---------------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] LIN6: Mobility Support in IPv6 based on End-to-End Communication Model / Fumio Teraoka ---------------------------------------------------------------------- [See slides at http://playground.sun.com/pub/ipng/html/meetings.html] ------------------------------------------------------------ Meeting Adjourned ------------------------------------------------------------