IPng Meeting Minneapolis IETF March 15, 1999 Robert Hinden / Nokia Steve Deering / Cisco IPng w.g. Co-Chairs Minutes taken and edited by Robert Hinden. Introduction / S. Deering (5 min) --------------------------------- Steve Deering introduced the meeting and passed out the rosters. Working group meet for two sessions: MONDAY, March 15, 1999 0930-1130 (Salon D) MONDAY, March 15, 1999 1930-2200 (Salon D) Approximately 200 people attended. Review Agenda / S. Deering (5 min) --------------------------------- Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) New Internet Draft Procedure / R. Hinden (5 min) Current Deployment Activities / P. Metzger (10 min) UNH Interoperability Testing / W. Lenharth (5 min) 6REN Status / R. Fink (5 min) Document Status / R. Hinden (15 min) Report from IPng Grenoble Meeting / S. Deering (45 min) Chairs' Recommendation on IPng w.g. / S. Deering, R. Hinden (15 min) Mobile IPv6 Status / D. Johnson (5 min) DNS Extension Status / M. Crawford (5 min) Router Renumbering Status / M. Crawford (5 min) Multicast Listener Discovery Protocol / S. Deering (5 min) Tunnel Broker Terminology & Concepts / A. Durand (5 min) Tunnel Broker / I. Guardini (10 min) Connection/Link Status Investigation (CSI) for IPv6 / H. Kitamura (10 min) Node Information Query / Matt Crawford Generic Address Mapping / A. Durand (15 min) Steal This Slide / M. Crawford (10 min) ND Extensions for Frame Relay / A. Conta (15 min) Using E.164 Telephone numbers as IPv6 addresses / H. Afifi (10 min) GateD IPv6 Status / W. Siadak Current State of IPng Multihoming / S. Deering (30 min) New Internet Draft Procedure / R. Hinden ---------------------------------------- The IESG announced the following procedure for all Internet Drafts: "All Internet-Drafts must begin with ONE of the following three statements: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except for the right to produce derivative works. This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and will only exist as an Internet-Draft. Any submission which does not include one (and only one) of the above three statements will be returned to the submitter. The IETF Secretariat will NOT add this text." IPng Procedure The IPng w.g. chairs require anyone considering the submission an IPng Internet Draft (i.e. draft-ietf-ipngwg-xxxx) that does not include the first statement obtain permission from the chairs prior to publication Without the first statement is not possible to consider the draft for entry into the standards process. Current Deployment Activities / P. Metzger ------------------------------------------ Perry Metzger could not attend. Report from floor that new web site is up at http://ipv6.org UNH Interoperability Testing / W. Lenharth ------------------------------------------ Testing last week at Connectathoen. Tested w/ three companies. Next event will be week before November IETF. Have added new items to test suite, more ND, Mobile IPv6, and plan to add OSPFv6 to test suite. See http://www.iol.unh.edu for more information. Question about if other vendors use lab. outside of test period? Yes, many of the vendors have the lab do testing outside of the public test periods. 6REN Status / R. Fink --------------------- The 6REN - ESnet has established an open participation initiative, the 6REN - it will act as an IPv6 rallying point for all Research & Education Networks world-wide (and any others that want to join) - thus enabling production IPv6 services worldwide Isn't this just the 6bone? - The 6bone is a testbed network coordinated by the IETF NGTRANS WG - Production quality portions of the 6bone will be a part of the 6REN - The 6REN will promote and coordinate production quality IPv6 service - The 6REN is NOT a network, it's an initiative to create production ipv6 networks 6REN participation - Free and open to all Research and Education Networks that provide production IPv6 service - Other for-profit and not-for-profit IPv6 networks are also encouraged to participate on this basis as well - you only need a willingness to join in helping create production quality IPv6 networks Current 6REN Participants CAIRN US) NTT (JP) Canarie (CA) Renater/G6 (FR) Chungwa (TW) Sprint (US) Esnet (US) SURFnet (NL) Internet2 (US) WIDE (JP) IPFnet (DE) CERNET (CN)* MCI/vBNS & NGnet (US) AARnet (AU)* (*soon we hope!) Work underway - Existing 6bone backbone networks are being approached to find out who can participate in this effort (this includes Sprint and NTT, so it's not just RENs) - Effort underway to help currently non-IPv6 experienced RENs to develop plans and proposals to provide production IPv6 service More work - Native IPv6 peering points are being developed at: o the StarTAP in Chicago, called the 6TAP (jointly planned, developed and operated by Canarie and ESnet) o the Amsterdam exchange, called the AMS-IX (jointly developed by various NL organizations) - Planning underway to coordinate these and other IPv6 exchange efforts More work - Qwest is providing RIPE-style registry service similar to that provided for the 6bone (courtesy of David Kessens) - Reverse DNS (ip6.int) registry will be provided through ISI, under IANA oversight, as done now for the 6bone - ESnet will provide transit to all 6bone participants (for all 6ren participants) to be sure no connectivity is lost to parts of the 6bone that are less reliable Next - Convert the early participants to production IPv6 addresses as soon as the registries start handing out Sub-TLAs early next year - Or continue the use of 6bone testbed addressing where appropriate - Work on making these networks provide production quality IPv6 service Providing... - The top down push to get site networks to put IPv6 into use - The environment and motivation to run existing and new Internet applications over a native IPv6 infrastructure - To guarantee that transitioning from IPv4 to IPv6 is transparent as possible - Early operational experience and conventions for running IPv6 production networks Join the 6REN Initiative - See the new web site for the 6REN: http://6ren.net - Contact Bob Fink if you have any questions: fink@es.net Document Status / R. Hinden --------------------------- Document Status - RFC Published o RFC2497 A Method for the Transmission of IPv6 Packets over ARCnet Networks (PS) o RFC2507 IP Header Compression (PS) o RFC2526 Reserved IPv6 Subnet Anycast Addresses (PS) o RFC2529 Transmission of IPv6 Packet over IPv4 Domains without Explicit Tunnels (PS) - IESG Approved o Basic Socket Interface Extensions for IPv6 (Informational) Document Status - IETF Last Call completed for Draft Standard o RFC2372 IP Version 6 Addressing Architecture o RFC22374 An IPv6 Aggregatable Global Unicast Address Format - IESG want experience w/ scoped multicast forwarding and other IESG issues? - IETF Last Call completed for Proposed Standard o Router Renumbering for IPv6 - IESG Comments - New draft ready for Last Call - Submitted to IESG for Proposed Standard o IPv6 Router Alert Option - IESG wants to reconcile w/ IPv4 Router Alert - AD has the action item to ensure that spec for IPv6 Router Alert is up-to-date, and that reasons for difference from IPv4 Router Alert are documented. o DNS Extensions to Support IP Version 6 - IESG issues? - There will be discussions at the IETF meeting to better understand issues and if required update drafts. Result will be reported to the w.g. mailing list. ACTION: Document editor to contact implementors to document scoped multicast forwarding multicast. ACTION: AD is check that current specification up to date and documents why IPv6 Router Alert is different from IPv4 Router Alert. ACTION: "DNS Extension for IP Version 6" document authors to send email to w.g. list to with resolution of issues. Document Status - Submitted to IESG for Informational o Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 - AD reported that the IESG hasn't gotten to it yet; no known objections at this point. - IPng Working Group Last Call Completed for Proposed Standard o IPv6 Jumbo Payload Option - Decision to combine w/ TCP/UDP Jumbograms specification. - Next step is to do an w.g. last call. - IPng Working Group Last Call Completed for Informational o Initial IPv6 Sub-TLA ID Assignments - IESG asked to delay - IPng Working Group Last Call Completed for Experimental o IPv6 Name Lookups Through ICMP - Renamed to be "IPv6 Node Information Queries", see below. DOCUMENT STATUS - Ready for Working Group Last Call? o IPv6 Jumbograms (PS) o A Method for flexible IPv6 Address Assignment (Informational) o Multicast Listener Discovery (MLD) for IPv6 (PS) o IPv6 Node Information Queries (Experimental) - Author will update draft and combine with related draft by A. Durand. o IAB: The Case for IPv6 (Informational) - Do an unofficial w.g. last call ACTION: Document editor to start an IPng w.g. last call for "IPv6 Jumbograms" for Proposed Standard. ACTION: Document editor to start an IPng w.g. last call for "A Method for flexible IPv6 Address Assignment" for Informational. ACTION: Document editor to start an IPng w.g. last call for "Multicast Listener Discovery (MLD) for IPv6" for Proposed Standard. ACTION: Document editor to start an unofficial IPng w.g. last call for the "The Case for IPv6" for Informational. Report from IPng Grenoble Meeting / S. Deering ---------------------------------------------- IPng WG Wrap-Up Session February 4, 1999 Grenoble WG Docs to Finish Up - MLD [done?] - ICMP revision o scope-exceeded err, no err to redirect, editorial - advanced API - router renumbering [done?] - merged jumbogram specs [done?] - generic tunneling (add bidirectional tunnels) Unfinished IPng WG work - flow label standardization (no action now) - scope issues, source address selection - multihomed host/site issues - autoconfig <-> DNS <-> mobileip story [Apparently already under control in other WGs; move this to "other WG prodding" category] - dial-up issues? [e.g., WIDE proposal for prefix assignment on PPP connection establishment] - [IPv6 literal addresses in URLs, etc.] Comment that there is a missing piece in Autoconfig/MobileIP. We don't know how to do secure/authenticated plug and play. Someone needs to put the whole picture together. New IPng WG tasks - specify transient interface IDs for privacy concerns - specify E.164-in-IPv6 addressing - specify IPv6 over additional media o USB? Bluetooth?, IOG pipe?, ... - start an IPv6 "host/router requirements" document - [ND extensions for address querying / mapping (from Frame Relay work)] Other current WG chores - keep all WG docs moving along publication/standardization track - identify "base set" of docs for advancement to full standard Other lower-layers WGs to prod - DNS, DHCPv6, IPv6-over-Firewire, Mobile-IP, RIPv2, OSPF, IS-IS, IDR, MOSPF, PIM, Diff-Serv, (Diameter), Malloc (maybe) New work for other WGs - IPv6 readiness check (incl. MIBS) [an IPng WG will probably have to take responsibility for making this happen] - secure ICMP/ND (ipsec) - authenticatable, auto-config'd hosts (ipsec) Other ideas to pursue, perhaps in new WG(s) - specify how exchanges can work - TCP/UDP/host use of anycast - next level of plug-n-play ("AppleTalk"-like) - 6-over-4 cut-through (NHRP-like) - more complete story for billions of mobile devices (esp. phones) - multi-link subnets o Other ideas to pursue, perhaps in new WG(s) (cont.) - scope-name discovery - conformance tests [not in IETF scope] - tools for reducing network mgmt costs Possible items for IRTF - transport use of global interface IDs - higher-layer survival of renumbering - router auto-config / auto subnet numbering - "better" multicast address alloc. - "better" VPNs - "better" billing opportunities - architected MLD snooping - firewall-in-the-host [already under control, e.g., will be in NT5] - ICMPv3 -> MLD Other - convey msg that "IPv6 is done"; it's time to implement, deploy, and port apps - review/strengthen "case for IPv6" and various documents about NAT problems. - keep prodding IP address registries - develop a voice-over-IPv6 story - participate more in other WGs - pass API docs to other stds bodies Question from B. Carpenter: Should we also send formal statements to other standards bodies? Comment that Open group thinks IPv6 is done, and is ready in include IPv6 API's into unix standard. Chairs' Recommendation on IPng w.g. / S. Deering, R. Hinden ----------------------------------------------------------- Revise Charter of IPng WG to: - Itemize (from previous presentation) o "Unfinished work" o "New IPng WG tasks" o "Other current o "Chores" tasks, with new (near-term) milestones - Change name to "IPv6 Working Group" - Form "IPv6 Directorate" to handle shepherding tasks and recommendations for new WGs and/or RGs Discussion and questions: Jim Bound: how would directorate members be selected? Normally ADs select directorate members. Discussion. E. Nordmark (new Internet AD) said he thought this was a good idea. Working group agree do these changes. ACTION: IPng w.g. chairs to revise w.g. charter with new work items and name change. ACTION: Internet ADs to create "IPv6 Directorate". Mobile IPv6 Status / D. Johnson ------------------------------- Current version of Mobile IPv6 draft has been through w.g. and IESG last call. Send additional comments to IESG. Some discussion. Doesn't think document needs to be changed. Mobile IP w.g. will discuss on Tuesday. DNS Extension Status / M. Crawford ---------------------------------- Document Status - One new comment received. o Specify that the 0-7 pad bits must be zero. (For secure DNS SIG purposes.) - Dependencies. o draft-ietf-dnsind-binary-labels o draft-ietf-dnsind-dname - draft-ietf-dnsind-edns0 - All on IESG agenda, with editorial comments pending. Some issues raised with DNS consortia people. Meeting later this week to discuss the issues. Router Renumbering Status / M. Crawford --------------------------------------- Changes from -06 to -08 draft version - Various editorial detail - Added a long section & appendix detailing how to decide when you've reached all your routers if you don't know how many routers you have o Compute estimator of round-trip reliability of least reliable of your routers. o Use that estimator to compute the Bayesian probability of null hypothesis Ho "reached all routers" vs. union of all Hn "n routers missed", for n >= 1 Comments: Nordmark: Another way to deal with this to always advertise all prefixes in every update with short lifetimes. Response: Then you get a different failure mode, in which routers that go out of contact expire their prefixes. But the use of regular no-op messages is mentioned in the text. ACTION: Document editor to start IPng w.g. last call for Router Renumbering for PS. Multicast Listener Discovery Protocol / S. Deering -------------------------------------------------- Status - Specify behavior when Max Response time is zero - Miscellaneous clarifications, as suggested by reviewers - I believe it is ready for WG last call for proposed standard. ACTION: Document editor to start IPng w.g. last call for Multicast Listener Discovery Protocol for PS. --------------------------------------------- MONDAY, March 15, 1999 1930-2200 (Salon D) --------------------------------------------- Tunnel Broker Terminology & Concepts / A. Durand ------------------------------------------------ Tunnel Broker - Virtual IPv6 ISP - A place where users connect to register and activate tunnels - Manages tunnel creation, modification and deletion on behalf of the users - Shares the load among several tunnel servers - Sends configuration orders to the relevant tunnel server when tunnels are to be created or modified - Registers the users in the DNS - Provides users potentially "permanent" IPv6 addresses which survive IPv4 renumbering (e.g., dial-up) Tunnel Server - Dual stack (IPv4 & IPv6) router connected to the global Internet - Receives configuration order from the tunnel broker - Creates, modifies, or deletes the half part of the tunnel toward the user. - Maintains statistics Meta Broker - Tunnels brokers around the world register could register to a well know place such as: http:/www.ipv6.org - Helps user to choose the appropriate tunnel brokers o Closest o Cheapest o Most reliable o .... Tunnel broker / I. Guardini --------------------------- Motivation - IPv6 tunneling over the Internet require heavy manual configuration o Network administrators are faced with overwhelming management load o Getting connected to the IPv6 world is not an easy task for IPv6 beginners - The Tunnel Broker approach is an opportunity to solve the problem. o The basic idea is to provide tunnel broker servers to automatically manage tunnel requests coming from the users. - Benefits o Stimulate the growth of IPv6 interconnected hosts o Allow early IPv6 network providers the provision of easy access to their IPv6 networks. The Tunnel Broker Architecture [figure of architecture] How does it work? [example figure1] [example figure2] Our Implementation - CSELT'sTunnel Broker service available at: http://carmen.cselt.it/ipv6tb - Basic features o Based on widely available tools to allow fast prototyping of the service o Basic communications between client and broker run over http o Tunnel Broker - Tunnel server and Tunnel Broker - DNS interactions based on simple RSH commands o The user must register before getting access to the service o The Tunnel Broker provides scripts (automatically created) to ease client's configuration o Both router and host support o The provider DNS manages names - global IPv6 address mapping e.g., guardini.tb.ipv6.cselt.it and guardini-if.ipv6.cselt.it o Administrator interface allow full control over users, tunnels and Tunnel server Tunnel Broker Service at CSELT [figure] Software Available - The first version of our implementation of the Tunnel Broker will be available soon at: ftp://carmen.cselt.it/pub/broker/tb-current.tar.gz - It already supports: o Client / IPv6 INRIA FreeBSD, IPv6 for windows NT (MS research) o Tunnel Server / IPv6 INRIA FreeBSD - We need contributions to add support for more IPv6 stacks! Connection/Link Status Investigation (CSI) for IPv6 / H. Kitamura ----------------------------------------------------------------- IPv6 Hop-by-hop option and ICMPv6 messages Extension Outline of "Connecting/Link Status Investigation" (CSI) Mechanism - A generic framework to collect status information of nodes along the both outgoing and incoming path - One new IPv6 Hop-by-hop option o CSI option - Three new ICMPv6 messages o Status request / status reply o Status report - As simple as "ping" mechanism - More efficient and reliable than "traceroute" type functions Connection /Link [figure] Requirements for CSI Mechanism - Cause minimum traffic o Ideally one pari of request/reply packets - Avoid unstable (dynamic routing) patch problem - Investigate bot outgoing and incoming paths - Be simple enough - Support CSI feature disabled nodes case and messages lost case - Be scalable and easily expandable IPv6 Hop-by-Hop CSI Option [figure] IPv6 Hop-by-Hop CSI Option - A packet that is set the CSI option investigates nodes along the path - Collect and record status information when it pass through nodes - Option tope of CSI option must be 00 1x xxxx o Starting bits (00): to avoid discarding the packet at the CSI disabled nodes o Third bit (1): To record the collected data - Value is 001xxxxx.0x20+TBA (tenatively 0x22) ICMPv6 Status Request / Reply messages [figure] ICMPv6 Status Request / Reply messages - A round trip probing loop (boomerang) o Source --> Destination --> Source - Both messages must be set the CSI option - Trigger to start collecting status information - Carry the collected data by the CSI option ICMPv6 Status Report message [ figure ] ICMPv6 Status Report message - Issued by hbh_CSI_management_routine() - Carry the overflowed collected data o from the investigated nodes o to the source (initiator) Status Report message transmission conditions and check algorithm - Data is full - Position record Bitmap is full and page must be updated - Hop limit is expired Traceroute (or Pathchar) type mechanism [ figure ] IPv6 hop-by-hop CSI Option Format (1/3) [pkt format] ICMPv6 Status Request Message Format [pkt format] ICMPv6 Status Reply Message Format [pkt format] Predefined Investigation Types [pkt format] Record Incoming Interface Address of Investigated Nodes [pkt format] Comments: A.Durand: Similar proposal made in 199x? How is this different? Also, how does this work with multicast traceroute. B. Carpenter: Diff Services needs to be able trace paths of a specific DS path. This could be extended to do this. Deering queried room to see if this should be followed. Some thought it was too complex. Would not want to implement because it would take too much code. Thinks we can do something simpler. A. Durand: Would also like to see Multicast added. Deering replied that the IPv4 multicast is limited to only trace one branch of the tree. Query sent to leaf of a tree. Done this way to reduce hazard of generating large implosions of traffic. Should think very carefully about generalizing this to multicast. Node Information Query / Matt Crawford -------------------------------------- Background - Generalized Who-are-you format - ICMPv6, although there's no intrinsic reason it must be so - Asks for information about the node at the destination address o No other query parameters Format +--------+--------+--------+--------+ | Type | Code | Checksum | +--------+--------+--------+--------+ | Qtype | Flags | +--------+--------+--------+--------+ | | + Nonce + | | +--------+--------+--------+--------+ | | + Reply Data + | | +--------+--------+--------+--------+ Qtypes: NOOP, Supported Qtypes, FQDN, Addresses Flags: defined for each Qtype Nonce: Matches replies to requests, crude anti-spoofing Comments - UDP would ease building apps with it - Return node name in DNS form, not ASCII - Urge consistency if multiple names exist - Is use of TTL appropriate? - Limit number of Qtypes more sharply? - Define a compressed form of Supported Qtypes reply data - Additional Query types? Generic Address Mapping / A. Durand ----------------------------------- Related Work Address mapping matrix Name, preferred, global, site-local, link-local, (MAC address?) to Name, preferred, global, site-local, link-local, (MAC address?) Unicast Queries - UDP unicast query - Node information query - Usage: o local address to name mapping o local address to global address mapping site local - Suggestion: use many multicast addresses hashed - Usage: o Name to local address mapping without DNS - Replies may be unicast or multicast??? - Caching issues A. Durand and M. Crawford will work together to combine drafts into one. Steal This Slide / M. Crawford ------------------------------ Presented several new idea. Hopes someone will pickup and work on them. Multicast Core or RP Location - Flood-and-prune multicast doesn't scale, and some alternatives need to associate a multicast group address with a core or rendezvous point. - There are 79 MBZ bits in an IPv6 multicast address. - Unicast prefixes are up to 64 bits long. - 64 < 79. - A prefix could be inserted in the group address which gives the core or RP location. Neighbor Discovery - by Name - Serverless address-to-name mapping is possible, how about serverless name-to-address mapping? Several possible approaches: o Multicast to all nodes. - Bad on a large serverless subnet, if such exists. - Doesn't cross a router. o Multicast to a "solicited name address" based on a hash of the name. - Would require nodes to join third mandatory multicast group. o Build it on service location. - A bit of a heavy stick? Maybe not. Downstream Renumbering - Some (most?) renumbering events will be initiated at the site level, but others will not. - Need a multi-tiered equivalent of Router Renumbering to propagate changes downward from provider NMS to customer NMS. - Require flexible options for human checking or automatic action. ND Extensions for Frame Relay / A. Conta ---------------------------------------- [speaker was not able to attend due to snow storm in Boston area] Using E.164 Telephone numbers as IPv6 addresses / H. Afifi ---------------------------------------------------------- Overview - Motivation - IPv6 address formats - E.164 address formats - The first solution - The second solution Motivations - New standards are looking at global networks (IMT 2000, UMTS, Bluetooth, ....) - One identification is better than two - Plug and play (the telephony is ahead in this domain) Brian C: Has not been convinced peer model is better than than layered model. - A field where IPv4 is not usable - A very large number of potential hosts E.164 Numbers - There possible types: o For networks +33 (6) 82 888030 o For international (+1) 514 727 2282 o For global services, imarsat, etc. - Usually a fourth type is mostly used Intelligent Network (+1) 514 727 2282 - The prefix is not part of the E.164 structure - We can have a sub-address but not routable E.164 Structure - International +--------------+--------------------+-------------------+ | Country Code | National Dest.Code | Subscriber number | +--------------+--------------------+-------------------+ 1-3 digits <-------------------max 15 digits ----------------------> - The routable part is 7 digits maximum Other Formats - E.164 for Networks (ex. ISDN, ATM, GSM, etc...) +--------------+--------------------+-------------------+ | Country Code | Ident. code | Subscriber number | +--------------+--------------------+-------------------+ <- 3 digits --> <- 1 to 4 digits --> <-------------------max 15 digits ----------------------> Global +--------------+--------------------+-------------------+ | Country Code | Global Subscriber number | +--------------+--------------------+-------------------+ <- 3 digits --> Using Intelligent Networks Abstract flat number is mapped to real routable number. [figure] IPv6 - RFC2373 +--------------+--------------------+-------------------+ | Prefix | Address | +--------------+--------------------+-------------------+ - RFC2374 Aggregatable Global Unicast Address - Hierarchy prefixes - One address at the end to identify the terminal +----+-----+-----+--------+-----------------------------+ | FP | TLA | NLA | SLA | Interface Identifier | +----+-----+-----+--------+-----------------------------+ Map telephone number into interface ID. E.164 / IPv6 - Who is the routing network o If IPv6 then: +----+-----+-----+--------+-----------------------------+ | FP | TLA | NLA | SLA | code your number | +----+-----+-----+--------+-----------------------------+ Very convenient for the current Intelligent Network or: +----+-----+-----+--------+-----------------------------+ | FP | TLA | NLA | Code your subscriber number | +----+-----+-----+--------+-----------------------------+ Where NLA is routable part of the number <---------> example: +1 514 767 2282 If routing is telephone based +--------------+--------------------+-------------------+ | Prefix | Address | +--------------+--------------------+-------------------+ Where Prefix is a special prefix for E.164 Address is different structures for different E.164 cat. Comments: To him E.164 is like a DNS name, not an IP address. Should not be mapped this directly. Discussion: Needs more detail on how these formats could be used. Assumption on size of fields, could grow to larger size from 15 digits. Needs more work... GateD IPv6 Status / W. Siadak ----------------------------- Introduction - Objective o Retro-fit Gated with IPv6 Code - IPv6 Code contributions o Francis Dupont (RIPng, BGP4+) o WIDE contributors (BGP4+) o Yixin Yang of UCLA (PIM-DM) o IBM Implementation To-Date - Gated core code - Protocols o RIPng o BGP4+ o PIMv6 Progress - Builds o KAME stack o INRIA stack - Tests Passed o Static routes o RIPng 2 and 4 machine test o BGP4+ 2 and 4 machine test o Export and import policy o Basic tests against MRT TODOs - More tests o Interoperability tests o Stress Tests - OSPFv6 - Builds o AIX o Solaris o Compaq o NLR Logistics ftp.gated.org/net-research/gated/gated-public-ipv6-snapshot.mmyyy.tar.gz - Snapshots o First one was 12/98 o Latest was 3-12-99 Current State of IPng Multihoming / S. Deering ---------------------------------------------- Will make sides available to group. Talk consists of features of IPv6 that may make multihoming easier and/or harder. Lays out issues, but does not have solutions. Comments: Multihoming is very important problem. Want to see more work on topic. Deering: expect to see action in next meeting. ----------------------------------------------- ----------------------------------------------- Meeting Adjourned ----------------------------------------------- -----------------------------------------------