IPng Minutes Los Angeles, IETF Robert Hinden / Nokia Steve Deering / Cisco co-chairs ----------- Steve Deering introduced the meeting. Three meeting slots are scheduled. Robert Hinden took and edited the minutes. Monday 7:30PM - 10:00PM Tuesday 3:45PM - 4:45PM Thursday 9:00AM - 11:30AM The agenda was reviewed. The resulting agenda was: Monday Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) UNH Interoperability Testing / B. Lenharth (5 min) Document Status / R. Hinden (15 min) Mobile IPv6 Status / D. Johnson (15 min) Proposed ND Split / M. Wasserman (5 min) IPv6 over PVC ATM / S. Deering (10 min) IPv6 over NBMA & IPv6 over ATM Status / P. Schulter (10 min) Router Renumbering / M. Crawford (15 min) Scope Issues / S. Deering (30 min) Tuesday Multicast Listener Discovery Protocol / S. Deering (30 min) IPv6 Plug and Play, Done? / R. Hinden (30 min) Thursday DNS Status / S. Deering (30 min) ICMP Name Lookups / M. Crawford (5 min) ICMP Node Info / A. Durand (10 min) Reverse DNS Lookup / M. Crawford (15 min) IPv6 Host Naming Translations / J. Paugh (10 min) Address Allocation Status Report / R. Hinden (5 min) ------------------------------------------ UNH Interoperability Testing / B. Lenharth ------------------------------------------ [Editors note: B. Lenharth was not able to give the report. R. Hinden gave summary] Most recent test event was at Connectathon. No router vendors present. Used Sun as router between two segments. IMAG BGP4+athon Five implementations - Cisco - Digital - Telebit-DK - Gated - MRT eBGP & iBGP tests route redistribution - BGP -> RIP - RIP -> BGP --------------------------- Document Status / R. Hinden --------------------------- RFC Published - RFC 2292 Advanced Sockets API for IPv6 (Informational) IESG Approved - MIB for IPv6: Textual Conventions & General Group / Jun 97 (PS) - MIB for IPv6: ICMPv6 Group / Jun 97 (PS) - IPv6 over PPP / Nov 97 (PS) - IPv6 Testing Address Allocation / Nov 97 (Informational) - IPv6 Multicast Address Assignments / Nov 97 (Informational) - IPv6 Packets over Token Ring Networks / Nov 97 (PS) - Generic Packet Tunneling in IPv6 Specification / Dec 96 (PS) - IPv6 Packets over FDDI Networks / Nov 97 (PS) - IPv6 Packets over Ethernet Networks / Nov 97 (PS) IETF Last Call completed for Proposed Standard - An IPv6 Aggregatable Global Unicast Address Format / Nov 97 (comments from Registries, new draft) - IP Version 6 Addressing Architecture / Nov 97 (new draft) - IP Header Compression / Nov 97 (need new ID, IPSEC) - MIB for IPv6: TCP / Jun 97 - MIB for IPv6: UDP / Jun 97 Submitted to IESG for Draft Standard - IPv6 Specification / Mar 98 - ICMPv6 / Mar 98 - Path MTU Discovery for IPv6 / Mar 98 Submitted to IESG for Proposed Standard - IPv6 Router Alert Option (IESG returned, need new ID) Submitted to IESG for BCP - TLA and NLA Assignment Rules / Nov 97 IPng Working Group Last Call Completed for Draft Standard - Neighbor Discovery for IP Version 6 (IPv6) - IPv6 Stateless Address Autoconfiguration IPng Working Group Last Call Completed for Proposed Standard - IPv6 over Point-to-Point ATM Link IPng Working Group Last Call Completed for Experimental - IPv6 Name Lookups Through ICMP IPng Working Group Last Call Ongoing - Router Renumbering for IPv6 (31 Mar 98) Moving Specifications to Draft Standard - Submitted to IESG o IPv6 Specification o ICMPv6 o Path MTU Discovery for IPv6 o Implementation Reports ftp://playground.sun.com/pub/ipng/implementation-reports/ - W.G. Last Call Completed o Neighbor Discovery for IP Version 6 (IPv6) o IPv6 Stateless Address Autoconfiguration TLA/NLA Assignment Rules Status - Plan to Create W.G. Unsuccessful - Should this be an IETF Document? - Meeting w/ Registries and IANA Tuesday - Proposed Changes (consistent w/ Current Aggregation Draft) o Focus on providing input from w.g. to IANA & Registries o TLA Assignment to all transit providers o Relax rules for peering and TLA routing o Remove Auction ------------------------------- Mobile IPv6 Status / D. Johnson ------------------------------- Mobile IPv6: IPv6 Changes and Open Issues Dynamic Home Agent Address Discovery - Mobile node may not always know its home agent address: o While mobile node is away from home o Home network may need to be reconfigured o Different machine may take over as home agent - Mobile IPv6 uses Home-Agents anycast address for this: o Mobile node sends to anycast address instead of directly to unicast home agent address o This home agent replies giving its own unicast address o But this anycast address (alone) gets us one home agent address o What if we then try to register with it but it says "busy," but there are other home agents on the home subnet? Improved Home Agent Discovery - Each home agent keeps a list of other home agents on subnet: o Home agents set new Home Agent (H) bit in Router Advertisements o Each home agent keeps a Home Agents List conceptual data structure, similar to Default Router List o Home agent replies to anycast giving complete list +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Other Neighbor Discovery Changes - New Advertisement Interval option for Router Advertisements: o Gives MaxRtrAdvInterval so mobile nodes know when they've missed (one or more) Advertisements from it +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertisement Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Discussion about need for this. Comparison with special home agent protocol. Mobile nodes need easy way to learn that they have moved. Proposal for sending to anycast address of home agent. Possible any assignment of "3" (0 is subnet router, 1 & 2 are for point-point link address assignment, 3 is next). Discussion about can interval be less than one second. Should ND be change to use milliseconds instead of seconds? Why is less than once second needed? Question about do all links need high frequency beacons? Only wireless? Mobile IP is not focused on wireless only. - Also allow MinRtrAdvInterval for home agents < 3 seconds: o Frequently enough to ``learn of their presence within a few minutes'' is not fast enough for mobile nodes moving about o Routers wanting to provide good service to mobile nodes MAY advertise more frequently Other Issues for IPng Working Group - How do we satisfy our IANA Considerations? o Need Destination Option type codes for 4 options o Need an anycast address for Home-Agents anycast - How do people know about Mobile IP SHOULDs and MUSTs? o Most important is requirement to be able to process received Home Address option - This applies to all implementations: hosts and routers, mobile and stationary --- everybody! o Suggestion: For now, collect all IPv6 requirements on a Web page, advertise it widely o Really need to write a real ``requirements'' document, but that's a big job (and too slow) ACTION DOC EDITOR: Get assignment for these options code points and start the anycast address assignment. Collect all code points. ND, ION, mobileIP etc. Deering and Johnson will write short draft describing anycast assignment in the next two weeks. Comments, Please - We are very close to going to Last Call for Mobile IPv6 - We need feedback/agreement from IPng Working Group - Please send e-mail comments to the Mobile IP mailing list: mobile-ip@SmallWorks.COM - Comments can also be sent to: o Dave Johnson, dbj@cs.cmu.edu o Charlie Perkins, cperkins@eng.sun.com -------------------------------- Proposed ND Split / M. Wasserman -------------------------------- ND is a useful set of mechanisms. Many IPv6 host will (and should) implement the full set. Some ND mechanisms may not apply to some: - link types - node types - situations Proposal to split ND into eight separable ND mechanisms - Address Resolution - Duplicate Address Detection (DAD) - Router Discovery - Prefix/parameter Discovery - Address Autoconfiguration - Router Unreachability Detection - Neighbor Unreachability Detection (NUD) - ICMP Redirects Requirement for minimal IPv6 functionality on many link types: - Address Resolution - DAD - ICMPv6 redirects Advanced Features: - Configuration o Router Discovery o Prefix/Parameter Discovery o Address Autoconfiguration - "Blackhole" detection / Fall back o Router Unreachability Detection o NUD Configuration "scopes": - Per link-type: all nodes must implement for communication to occur o Address resolution o ICMPv6 Redirects - Per link: Usefulness depends on cooperation of all nodes on link: o Duplicate address detection - Per link: Usefulness depends on cooperation of all routers on link: o Router discovery o Prefix/Parameter discovery - Per host/per-interface: can be useful without cooperation of all hosts on link: o Address Autoconfiguration o Router/Neighbor Unreachability detection Suggested specification changes - Make distinction between 8 mechanisms - Assign configuration scope, recommendations and defaults - Describe for separate implementations Suggested specification split: - Put minimal required mechanisms, related messages and descriptions into separate document o Address resolution o DAD o ICMPv6 Redirects Discussion. Suggestion was made that this document can define what is appropriate for each link types and what can be turned off. It would be an applicability document for ND and Autoconfiguration. ------------------------------ IPv6 over PVC ATM / S. Deering ------------------------------ Two competing specs for how to run IPv6 over ATM in a PVC Mode: IPv6 over PVC ATM draft and ION NBMA draft. In previous meetings the approach discussed was that there would be a separate document that defined this mode independently from full NBMA draft. Deadline proposed. Chairs believe deadline was end of January 1998 and that deadline has passed. ION document were published prior to March 1998 meeting. In ION documents IPv6overPVC-ATM is not in one place but spread over multiple sections in two documents. Some differences in two approaches: MTU, generation of link-local addresses, others? Deering's personal opinion is that it should not be spread over two documents. Would prefer PVC case to be in a single document. Postponed further discussion till after the ION status report, next. --------------------------------------------------- IPv6 over NBMA & IPv6 over ATM Status / P. Schulter --------------------------------------------------- ION meet today and discussed this issue. Grenville Armitage (Lucent) Peter Schulter (Bright Tiger Technologies) Markus Jork, Geraldine Harter (Digital) The General Architecture - Assume general NBMA 'cloud' o Capable of pt-pt links (static or dynamic) o Capable of pt-mpt links (dynamic, real or emulated) o May or may not have native 'multicast' - NBMA cloud could be o ATM o Frame Relay o IPv4 network o ... - MARS ? NHRP ? o Only used for SVC mode where native multicast is not supported, and dynamic shortcuts make sense Since last we met.... - Modified host triggered redirection behavior (replies are now Redirects) - Added new Shortcut Limit option for host triggered redirect (NS) message - General text cleanup Open Issues: - Assignment of a new ND option number (we picked the next available number) ACTION IPng Doc Editor: Get option assignment - What is it? o is a media-specific companion document to - Contains o Rules of generation of ND link tokens and link address fields o Codepoints for MARS and NHRP messages o Rules for LLC/SNAP encapsulation - Null encapsulation optional o Covers PVC and SVC cases separately - Clients do not need to implement SVC related extensions (eg. MARS) if only PVC support is required PVC rules - Standard LLC/SNAP encaps, with IPv6 PID o Null encapsulation allowed/negotiable - Default IP MTU of 9180 octets - All PVC rules now in section 3.1 (encapsulation, MTU, link token generation) SVC rules - Standard LLC/SNAP encaps with IPv6 PID o Different unicast and multicast formats as per RFC2022 o Null encapsulation discouraged, since it cannot be used between MARS and IPv6/NBMA client anyway --------------------------------------------------------- Continuation of IPv6 over PVC ATM Discussion / S. Deering --------------------------------------------------------- Three points: 1) Technical differences. "IPv6 over Point-to-Point ATM Link" spec is what has been implemented in WIDE implementation. 2) Should there be a stand alone document? 3) If we go with ION document, there should be proper acknowledgment of < authors. Asked for comments. Discussion. Many liked separate document. Suggested to use ION link-local rules. Another comment suggested that once technical issues resolved we should go with ION work. Suggestion that ION has been implemented as well. Discussion should have happened in ION. K. Yamamoto is willing to defer to ION, but wants it out quickly. Deering suggested that K. Yamamoto and ION authors get together and resolve differences. Would still like to have the PVC document be stand alone. Will go forward with ION document with closer coordination from K. Yamamoto. -------------------------------- Router Renumbering / M. Crawford -------------------------------- Status draft -03 - In w.g. last call - Outstanding issues o Stagger replies to multicast command o Limit multicast destination addresses to all routers only o Check for formation of unacceptable address (multicast, etc.) during execution - Open questions o enable matching conditions on length of prefix? Yes o Forbid formation of v4-compatible address? Yes o Discard custom authentication -IPSEC only? Yes, frees up field Spin-Off work - Define "Site" - Or agree not to Comment that given authentication this document does not need to define site. Security implicitly defines site. -------------------------------------------------- Multicast Listener Discovery Protocol / S. Deering -------------------------------------------------- New draft out . Equivalent of IPv4 IGMP for IPv6. Changes: - Using Link-local address for sourcing messages - Packet formats - Terminology Solicited comments. ------------------------- Scope Issues / S. Deering ------------------------- Discussion with diagrams. | | | | | | | | | +--------+ +--------+ +--------+ | | | | | | | Rtr | | Rtr | | Rtr | | | | | | | +--------+ +--------+ +--------+ | | | | | | | | | ============================================ Link Local: Drew scope boundary through the middle of Routers Site Local: Showed three alternatives. First site boundaries is in the middle of routers. Second boundary is in the middle of links. Third is interface based. Deering advocated the first alternative only. Assumption that sites are not overlapping. Overlapping sites are not currently supported. There is only one site-local prefix. Question about why we want site local. This was discussed at length on mailing list. Conclusion was to keep them. It would be more destructive to get rid of them, than to keep them and to define usage. Current objective is they are useful during renumbering. Site local addresses don't have to change. Comment that Erik Nordmark's draft is only defined usage of site-local. Think we can keep this usage without defining in detail. Deering wants to propose simple definition with guidance for implementors. If they don't get use, this will not be a problem. +--------+ +--------+ | | | | | Rtr 1 +--------------------+ Rtr 2 | | | | | +--------+ +--------+ ..site A.. | ..........site B........... | ......site C......... In this example there is a site boundary between each router. This results in three sites (left 1/2 of rtr 1, right 1/2 of rtr 1 through left 1/2 of Rtr 2, etc. Long discussion..... General consensus in the discussion to keep site local and agreement to make site boundaries in node (not link or interface). ACTION: S. Deering to write a draft ------------------------------------- IPv6 Plug and Play, Done? / R. Hinden ------------------------------------- Context - Plug and Play likely to be IPv6's Carrot - Makes IP Easy to Use! - Lowers Cost of Ownership for Enterprises and ISP's - Enables Network Appliances o Phones, PDAs, Games, household appliances, etc. Where Are We Now? - ND and AddrConf o Global Address Creation o Router Discovery o IP Parameters - DHCPv6 - Router Renumbering o Centralized reconfiguration of Router Advertisement Information - DNS o Automatic Creation of Reverse Map What Is Missing? - DNS o How to find DNS Server o How to register Node DNS name - Services o How to find Printers, File Servers, etc. o Enterprise and Home Office solution Solutions - Role of Service Location Protocol o Appropriate for General Service Location o Works with and without Servers o Not appropriate for DNS server location - DNS Server Location o Need Something New - DNS Name Registration o Status of Dynamic DNS Updating? DNS Server Location - Need to Learn o Server Address(s) o Default Domain o Domain Suffix Search list o Others? - Issues o Authentication o Lifetimes o Changing Approaches - Add Attribute to ND Router Advertisements o Requires adding this info to Routers o What if no Router? - DNS Server Advertisements? - Anycast Address for DNS Servers o Requires further communication w/ DNS server to get other related information - Multicast Address for DNS Servers o Use Expanding Ring (TTL) Search Next Steps - Discussion - Pick Approach Ohta: for DNS lookups, any DNS server will do; for registering/updating names, need specific server. Nordmark: what about coffee machines without keypads? Bound: don't dump on servers! Cheshire: svrloc allows literal addresses, so would work fine for DNS discovery. Deering: maybe spin off to a separate working group? Bound: to use anycast, need to allow hosts to have anycast addrs Durand: DNS service itself is complex, server-based; not exactly what dentists want? Additional discussion. General conclusion that topic should be pursued, but not clear if it should be in the IPng working group. ----------------------- DNS Status / S. Deering ----------------------- First item is where we are in DNS work. Major piece of core charter. Need to find current state and what should we do. What document should be moved forward, what not, what else needs to be done. Solicited opinion. Huitema: Did revision of draft based on previous decision. Submitted first release in January. New draft based on comments. Draft stable. Added tutorial part, comment to expand this and clarify. Reluctant to do any changes. Wants doc to go to w.g. last call. Has not received any major objections. Only wants to make changes based on w.g. comments. Waiting for results of reverse lookup. Publish as is or merge with new reverse lookup approach. Relationship w/ current RFC. Backwards compatible with current AAAA RFC. Conclusion (w/ no objections) is this will replace current AAAA RFC. RFC1886 will become obsoleted (historic). ACTION: Chairs do W.G. last call when new draft is out. ------------------------------- ICMP Name Lookups / M. Crawford ------------------------------- Status (-02) - In w.g. last call for experimental. - Could be rolled in with several other suggestions. Wants to hold off moving this forward until that is resolved. -------------------------- ICMP Node Info / A. Durand -------------------------- ICMP Node Info / Local extensions of ICMP "who are you" Motivation - Local address <=> "local name" mapping - Local address <=> global address mapping - local topology discovery - "local name" space discovery => local means "link local" or "site local" - Something very simple Two ICMP types, several codes, X: request, Y: reply X/0: "localname" request Y/0: "local name" reply X/1: incoming interface Y/1: incoming interface global address request global address reply X/2: all interfaces global Y/2: All interfaces global address request address reply Unicast Usage - X has only Y link local address and wants to discovery: o Y "local" name o Y global addresses Multicast Discovery - "Allowed" multicast destination addresses o All node link local o All router link local o All route site local - Source address of requests and replies packets MUST be local - Replies may be multicast to all node link local - anti-flooding mechanisms are needed Security Considerations - Do we open a can of worms? - Is IPSEC appropriate - if yes, is it necessary? Question: relationship between this and link local naming. Huitema: Should coffee pot use this or DNS? Answer this. Discussion. Generally thinks naming functions should be in DNS resolver and not in ICMP. M. Otha: Should this be used in sites? Not only link scope. These names should only be used with limited scope. This can be used to discover all of the names on the link. Deering: Thinks functionality should be in resolver, but that doesn't mean that this needs to be in DNS protocol. Matt: Could make small changes to "who are you" draft to allow more request types and replies. Kazu: Doesn't like this under ICMP. On Unix systems UDP would be better. Need root access to send/receive ICMP messages. ACTION: Chairs to figure out how to keep this work going. Might be in new w.g., somewhere else. Dimitry H: Need mechanisms to discover global address of router from link-local address. Doesn't think SNMP is appropriate. Could add ND option to router advertisement to advertise global address of router. Can we require routers to accept packets sent to prefix it is advertising with interface ID from link local address of router. Becomes an anycast address for router. Deering: links and subnets are not necessarily the same thing. Would like architecture to allow subnets to span multiple links. Discussion.... Nordmark: Wants to keep node in control of what addresses it uses. Doesn't want other nodes to decide. Also, is this also needed for hosts too? Bound: Thinks we should just have ND advertise all addresses of node. Nordmark: If so, would need to add lifetimes with each addresses. Lots of detail here. Otha: Thinks sites are collection of links. Discussion.... ----------------------------------------- Reverse DNS Lookup / M. Crawford ----------------------------------------- IPv6 DNS Lookups Goals and Semi-Goals - Delegate on arbitrary boundaries - Cacheable intermediate data - A single zone can be used under multiple higher-level prefixes. - Zone needs no modification if net is renumbered - Coexists with existing ipv6.int - Forward and reverse can be in sme zone file. New DNS Tools - Binary Labels o Compact representation of bit-string with semantics of a sequence of 1-bit domain labels: \[x200100/24].ip6.int. o Longest-match fallback when nameor datanot found - Non-terminal domain renaming (DNAME) o Maps a suffix set of labels to a different suffix: c.d.d.f. DNAME y.z causes a query for a.b.c.d.e.f. to go to a.b.y.z Proposed Structure - Higher-level registries of ISPs delegate address space to a domain chosen by the lower-level entity. - The delegated prefix disappears in the mapping o Hence, lower-level domain can be used with multiple prefixes - The delegating DNAME record can be cached [ Slide w/ examples] Pesky Details - How to look up site-local addresses? o Resolvers know to use only same-site DNS server? o Top level delegates \[xFEC0/10] to special name with site-local addresses? - Like Questions: Has this been reviewed by DNS w.g.? Met yesterday, feeling is that it should be done. Some technical details to work out, but should be done quickly. Expect to be done by next IETF meeting (August 98). Huitema: Thinks this is compatible with new DNS draft. Has talked to Matt C. about it. Good to have all of this together. Good thinking, very complementary. All data in one place. Only practical question is of timing. Relationship between DNAME and Binary Lables? Could this be blocked for a long time? Matt did not think this would happen. KRE: DNS group has a good track record to get work out. Should be ready for IESG by next IETF. Conclusion is to merge the two drafts. ---------------------------------------- IPv6 Host Naming Translations / J. Paugh ---------------------------------------- Solaris NIS/NIS+ Naming Services Goal is to not break IPv4 applications IPv4 & IPv6 Addresses Stored Separately - NIS map, NIS+ table and /etc file created for IPv6 addresses - Prevents existing IPv4 applications from unexpectedly receiving IPv6 addresses - Separate IPv6 database can be served by older slave/ replica Server Side Changes - New IPv6 host database created o hosts6.byname/hosts6.byaddr maps for NIS o hosts6.org_dir table for NIS+ o "AAAA" record for DNS o /etc/inet/hosts6 file for local file o Updated utilities to create hosts6 database (ypmake(1M), nisaddent(1M), nispopulate(1M), etc) [ Figure showing getXbyY() Application ] ------------------------------------------ Address Allocation Status Report / R. Hinden ------------------------------------------ Address Allocation Status Report / R. Hinden Met with registries and IANA. General conclusion is continue with approach described on Monday. New change is approach to initially assign sub TLA to transit providers who request allocation. When this is 90% used, they can then ask for a full TLA. This will be assigned with the understanding that they will have to give back the sub-TLA after a transition period. This should keep the top level routing in the order of the number of transit providers. Will work with registries and IANA to revise the draft. Expect to publish it in early May. Dimitry: Make sure policy doc does not rule out allocation of TLAs to exchanges. Carpenter: this doc will not be an IESG-approved doc; will be published as Informational RFC. ----------------------- IANA Status / R. Hinden ----------------------- Met with Jon Postel. Will collect and sanitize current code point request and send to IANA. Future request sent to IANA will be reviewed by IPng document editor. R. Hinden will serve as IANA technical reviewer for v6 numbers; asked for all spec authors to email him their code-point requirements and corresponding document citations. ------------------------- Meeting adjourned -------------------------