IPng Working Group Meeting February 2-4, 1999 Grenoble, France Bob Hinden / Nokia Steve Deering / Cisco IPng Co-Chairs Bob Fink / LBNL Tony Hain / Microsoft NGTRANS Co-Chairs Minutes taken by Tony Hain, Steve Deering, Bob Fink and Bob Hinden. Edited by Bob Hinden. Minutes for NGTRANS and deployment activities published separately. ----------- IPng / NGTRANS INTERIM MEETING February 2-4, 1999 Steve Deering introduced meeting. Alain Durand gave local arrangements, terminal room information, daily schedule. 92 registered to attend. 25 from France 32 from elsewhere in Europe 28 from North America 7 from Japan SCHEDULE Tuesday 8:00 Registration 9:00 Welcome speech by IMAG's director 9:10 Morning session 11:30 Lunch break & registration 13:00 Afternoon session 1 15:00 Afternoon break 15:30 Afternoon session 2 18:00 End 20:00 Rendezvous at Bus station (next to the train station) to take a bus to go to the social. 23:00 Return from the social Wednesday 8:30 Registration 9:00 Morning session 11:30 Lunch 13:00 Afternoon session 1 15:00 Break 15:30 Afternoon session 2 18:00 End Thursday 8:30 Registration 9:00 Morning session 11:30 Lunch 13:00 Afternoon session 1 15:00 Break 15:30 Afternoon session 2 18:00 End First day is an IPng w.g. meeting. Second day is an NGTRANS meeting. Third day is deployment activities (this is not an IETF meeting). ---------------------------------------------------------------------- ---------------------------------------------------------------------- IPng WORKING GROUP February 2, 1999 Grenoble, France Bob Hinden / Nokia Steve Deering / Cisco Co-Chairs Introduction / S. Deering ------------------------- Steve Deering introduced the meeting and collected the attendee required issue lists. Chairs will review lunch break and present the results. IPng charter basically complete, documents are at various points in the standards process. Document review for completeness, followed by issues or additional work. Continue, Recharter, hibernate decision. Review and update agenda / S. Deering -------------------------------------- The agenda was reviewed. The following agenda resulted: IPng AGENDA - Introduction / S. Deering - Collect attendee required issue lists (S. Deering) - Review and update agenda (S. Deering) - Review state/completeness of current IPv6-related protocols (B. Hinden) - Identify important new IPv6 protocol/standards work (detailed agenda follows) - Formulate recommendations to the IESG/IAB, re: future IPv6 work (detailed agenda follows) AGENDA: NEW PROTOCOL / STANDARDS WORK - Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden) - Securing ICMP/ND/MLD (M. Crawford) - State of Plug-and-Play (B. Hinden) - Site Scoping Issues (T. Narten) - Issues in IPv6 Multihoming (J. Hagino) - Better Support for Multihomed Hosts (R. Draves) - Better Support for Multihomed Sites (E. Nordmark) - Privacy issues with use of EUI-64 IDs (T. Narten) - Source and Destination Address Selection (T. Narten) - Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford) AGENDA: FORMULATE RECOMMENDATIONS / S. Deering, B. Hinden - Disposition of IPng w.g. - Extend charter? go on hiatus? - Distribution of work to other existing WGs? - Evaluation of all IETF protocols for "IPv6-readiness"? - Recommendations for establishing new WG(s) or RG(s)? Review State/Completeness of Current IPv6-Related Protocols (B. Hinden) ----------------------------------------------------------------------- REVIEW STATE OF IPv6 PROTOCOLS - Draft Standards - Proposed Standards - Informational - Experimental - Current Internet Drafts DRAFT STANDARDS - RFC2460 Internet Protocol, Version 6 (IPv6) Specification Issue of advancement to full standard over what time period. IESG will want to insure that protocols are mature. Discussion on what IESG will require to move base protocols to Standard. Conclusion that we should get a clear statement of what the IESG will be looking for. - RFC2463 Internet Control Message Protocol (ICMPv6) Add scope-exceeded ICMP error msg code RFC-editor suggested edits Prohibit ICMP error message in response to redirects ACTION: Document editor to do editing pass and resubmit to IESG for same status - RFC2461 Neighbor Discovery for IP Version 6 (IPv6) Forbid RAs from non-forwarding interfaces Issue of NAs without link-layer address Suggestion: guidance/interpretations document - RFC2462 IPv6 Stateless Address Autoconfiguration No issues - RFC1981 Path MTU Discovery for IP version 6 No issues. Note this was the only spec that progressed without recycling! PROPOSED STANDARDS - RFC2373 IP Version 6 Addressing Architecture No issues - RFC2374 An IPv6 Aggregatable Global Unicast Format No issues Should decide on what the "core set" of documents is. - RFC1886 DNS Extensions to support IP version 6 Should this be advanced? Not unless something else that depends on it needs to advance to next level. M. Crawford reported that new specification does not include specification of AAAA, does describe compatibility. Conclusion that both specs will need to coexist with each other. The new specification will need to have it's title changed. It is currently has the same title as RFC1886. - RFC2147 TCP and UDP over IPv6 Jumbograms To be merged with jumbogram hop-by-hop option spec to produce combined document. Work in progress. - RFC2080 RIPng for IPv6 ACTION: Document editor to poke RIP wg to advance to Draft Standard. - RFC2283 Multiprotocol Extensions for BGP-4 Francis reports there will be a new version of this spec, going to draft standard; a separate IPv6 specific part is supposed to be published as Proposed standard. Narten: This is hung in the IESG on a normative reference for another doc Summary: Update to RFC2283 to include IPv6 will be forwarded as proposed; how to it use is drafted, but not published; ACTION: Document editor will poke chairs (or ADs if necessary). PROPOSED STANDARDS - RFC2464 IPv6 Packets over Ethernet Networks No issues - RFC2467 IPv6 Packets over FDDI Networks No issues - RFC2470 IPv6 Packets over Token Ring Networks No issues - RFC2472 IPv6 over PPP No issues General conclusion is that IPv6 over Ethernet/FDDI/TR/ PPP should move to draft standard when 6 month time goes off. Need to start collecting implementation information and issue last call. ACTION: Document Editor start collecting implementation information on IPv6 over Ethernet/FDDI/TR/ PPP and issue last call for Draft Standard when 6 month timer goes off. - RFC2473 Generic Packet Tunneling in IPv6 Specification Need to add language about bidirectional tunnels and recycle at Proposed Standard. - RFC2491 IPv6 over Non-Broadcast Multiple Access (NBMA) Networks No issues PROPOSED STANDARDS - RFC2492 IPv6 over ATM Networks No issues - RFC2452 MIB for IPv6: TCP No issues - RFC2454 MIB for IPv6: UDP Bert Weinen: plan to merge with the IPv4 versions of TCP & UDP. Pick up with authors and merge. Could be done in the ops area. May not be sufficient in other area. ACTION: O&M AD's to resolve. - RFC2465 MIB for IPv6: Textual Conventions & General Group Question about support for site ids - RFC2466 MIB for IPv6: ICMPv6 Group No issues Question about any Implementations? Nordmark: instrumentation is done to support this, but the MIB browser interface is not done. Dupont: INRIA has complete implementation. PROPOSED STANDARDS - IP Header Compression (Internet Draft) No issues - Transmission of IPv6 over ARCnet Networks (Internet Draft) No issues - Transmission of IPv6 Packets over IPv4 Networks without Explicit Tunnels (Internet Draft) No issues - Reserved IPv6 Subnet Anycast Addresses (Internet Draft) No issues - RFC1752 The Recommendation for IP Next Generation Protocol Question what to do about this? Perhaps time for BCP? ACTION: Document authors (Mankin & Bradner) to decide what to do. INFORMATIONAL - RFC2450 Proposed TLA and NLA Assignment Rules No issues - RFC1881 IPv6 Address Allocation No issues - RFC2375 IPv6 Multicast Address Assignments ACTION: Document editor needs to get IANA to publish this on their web pages - RFC2133 Basic Socket Interface Extensions for IPv6 No issues. Will become historic when new back socket document is published. - Basic Socket Interface Extensions for IPv6 (Internet Draft) No issues - RFC2292 Advanced Sockets API for IPv6 Possible issue with support for home address option from Mobile IP Perhaps pass these to API stds bodies, e.g., Xopen, winsock EXPERIMENTAL - RFC2471 IPv6 Testing Address Allocation No issues - RFC1888 OSI NSAPs and IPv6 Matt C. notes that this is only current way to embed phone numbers in IPv6 addresses CURRENT INTERNET DRAFTS - Initial IPv6 Sub-TLA ID Assignments No issues - Router Renumbering for IPv6 Being revised to support reliability mechanisms; will be another WG last call - Link Local Addressing and Name Resolution in IPv6 There is interest in this - GSE - An Alternate Addressing Architecture for IPv6 ACTION: Document editor will inform secretariate that this has timed out - IPng Analysis of the GSE Proposal Has been submitted to IESG for Informational. CURRENT INTERNET DRAFTS - A method of flexible IPv6 address assignments Waiting for additional comments, then w.g. last call for Informational. - IPv6 Router Alert Option Waiting resolution of differences between IPv4 and IPv6 versions. - The IPv6 Jumbo Payload Option Will be combined with TCP/UDP jumbograms to create single document. - Multicast Listener Discovery (MLD) for IPv6 ACTION: Deering to reissue by ID deadline for Minneapolis - DNS Extensions to support IP version 6 [See discussion on "RFC1886 DNS Extensions to support IP version 6" above] - IPv6 Name Lookups Through ICMP [No notes] - Reverse Address lookup in DNS for IPng ACTION: Document editor will inform secretariate that this has timed out CURRENT INTERNET DRAFTS - OSPF for IPv6 - Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6) Continue work. - Site Prefixes in Neighbor Discovery Continue work. - Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Work progressing slowly in DHCP w.g. - Extensions for DHCPv6 Work progressing slowly in DHCP w.g. - Mobility Support in IPv6 About to start last call in Mobile IP w.g. CURRENT INTERNET DRAFTS - IPv6 over Point-to-Point ATM Link ACTION: Document editor will inform secretariate that this has timed out - Transmission of IPv6 Packets over IEEE 1394 Networks Would like see progress in IPover1284 w.g. - Transmission of IPv6 Packets over Frame Relay Networks ION w.g. about to do w.g. last call. - Forcing Fragmentation to Network MTU [No notes] - The Case for IPv6 Author working on new draft. Reviewed submitted tasks / S. Deering, B. Fink ---------------------------------------------- Summary of submitted tasks with counts of times topic appeared in "[ ]"s followed by sub-topics. Flow ID [7] Multicastcast routing [8] snooping [1] doing it better [1] dns [1] 6 over 4 [1] VoIP [3] mobility [18] dns site local security API dns discovery [1] site multihoming [15] routing usage v6 apps readyness [5] renumbering v6 compatibility text security [10] ND ICMP MLD v6 over v6 management [4] nd mibs snmpv6 tools interior routing [13] isisv6 ospv6 other address allocation [3] aggregation addressing [3] encourage implementers [2] public relations [1] plug & play [11] renumbering [3] tcp survival AAA - dialup [2] diameter VPN [1] Host & router requirements [3] Conformance / compliance [3] Secure DNS [1] Dynamic DNS [1] Exchanges [2] Anycast [5] tcp / udp DNS [4] zones number of roots Measurement [1] Host multihoming [5] Router autoconfig [2] Site definition [1] IPv4 competition [1] Service location [1] QOS - hop by hop reservation [1] Building the 6ren [1] DHCPv6 [3] Ipv6 over IOG [1] IPv6 over 1394 [2] Compatibility testing organization structure [1] Filtering [1] Source & destination selection [3] ND v6 spec problems [1] Free implementations [1] Killer app [1] Transition [2] smooth Diff serv [1] Who are you [1] Icmp scope [1] Link & site local addressing in multihoming [1] V6 interface identifier [1] V6 socket api [2] NIS & NIS + [1] Site local address usage [1] Multi-link subnets [1] Scope discovery [1] Firewalls into the host [1] IPv6 addresses in URL's [1] Discussion of new topics receiving the most votes. Flow label ---------- Deering described current state. One issue is if it has end-to-end semantics, or hop-by-hop. Currently it is end-to-end. No one has defined other usage, though there has been a lot of discussion. C. Jung described how it might relate to MPLS and it could be us to carry the MPLS label. This may be OBE. Matt Crawford noted that MPLS is "multiprotocol", hence it should not deal w/ IPv6 differently from IPv4 or any other protocol J. Bound said that RSVP for IPv6 currently uses the flow label field. C. Jung is uncomfortable with current flow label definition. Telabit said they have implemented flow label and found it useful. Bound see a lot of value with current definition because it is very important for applications for bandwidth brokers in corporate intranets. Deering suggested that we could define flow label to have either end-end or hop-hop semantics by using one bit. Another suggestion that e-e flow label would also be very helpful for user authentication and billing applications. Examples: accountable premium bandwidth. Flow label is a very good place to carry subscription information. Hinden thought there was a loose consensus on keeping the existing wording, authors could provide flow label detail in additional documents Deering outlined what we could do. Choices were: 1) Drop flow label 2) Standardize current flow label 3) Standardize hop-by-hop FL 4) Standardize hybrid 5) Leave as is Polled group. 1) 1 2) 11 3) 0 4) 13 5) 26 No consensus to change behavior or current text. Multicast Routing ----------------- Deering reported that PIM, MOSPF, MBGP have IPv6 extensions. Thinks work is going along well. Action here is to keep them moving forward. Mobility -------- Work is already in another WG charter (e.g., Mobile IP). Is the question mobility in general v.s. mobile IP? Answer: Mobility in general Wireless is one of the media. M. Crawford suggested that we get E163/E164 into IPv6 and let the phone system take it over Routing, Interior and Exterior ----------------------------- Should be in other groups; Noted that OSPF for IPv6 is only a draft. Needs to be advanced. Durand: strange feedback, spec is in draft state but WG is holding due to lack of implementations, but lack of implementations due to lack of spec; little pressure to move v6 related work forward Hinden: routing protocols actually require interoperable implementations to move forward. Deering: OSPF is not a high risk since there is not a competing proposal ISIS is a IPv6 hostile WG so they may have left it out of their charter. -------------------------------------- AGENDA: NEW PROTOCOL / STANDARDS WORK -------------------------------------- Will IPv6 work for a Billion (or more) PDA's and Mobile Phones? (B. Hinden) --------------------------------------------------------------------------- MOBILE PHONES - More Mobile Phones Sold Yearly than PC's o 163 Million sold in 1998 - Currently 300 Million Users o Expect to reach a Billion in 2005 - Every Phone is Networked - Next version of GSM has IP in it o Every phone will have an IP stack! Phone networks decided v6 was not applicable since it was not a std Deering: new groups now taking std status label more seriously Hinden: Missing piece is wireless mobile, and scale is not addressed Nordmark: Do the implementers understand the scaling issues Bound: Problem is ISP's looking at GSM, others misleading that IETF declared v6 dead T'sirtis: TV's have the same problems Hinden: More things are network appliances, all this has scaling issues PDA's are getting more networking, and converging with phones. PDA'S - PDA Market growing Exponentially - Networking coming to PDA o Wireless just starting - Some PDA's look like Mobile Phones o Some Mobile Phones look like PDA's - IP Stacks are available for PDA's now REQUIREMENTS - Global Addresses o 2 x number of devices o Server Applications - Auto Configuration o Minimum of manual configuration - Security o Encrypted Transmissions o Authenticated Node - Mobility o Roam between Providers - Efficient use of Link o Limited bandwidth available - Compact Implementations o Limited code space HOW DOES IPv6 DO? - Global Addresses o Lots of addresses o Supports large subnets - Auto Configuration o Basic functions fine o DNS? o Secure? - Security o Basic mechanisms OK o Plug and Play? - Mobility o Mobile IPv6 OK - Efficient use of Link o Can Header Compression be used? o With Security? - Compact Implementations o Should be OK NEXT STEPS - Need to Address o Secure Neighbor Discovery and Autoconfiguration o Simpler Service Discovery - Should we Pursue this Work o Is it an important problem to solve? o Are we close enough now? - Where / How? o IPng w.g. o New w.g. Nordmark: No foreign agent in current spec, general problem is authentication of guest ethernet. Generally calls are dropped when switching providers, so roaming registration happens on startup Securing ICMP/ND/MLD (M. Crawford) ------------------------------------------------ Authenticating an error message - Security policy for informational ICMP ND - Spoofing & DOS attacks MLD ? what is the problem Deering: How do you restrict access to multicast? Crawford: Payload encryption solves the problem, and the key distribution is someone else's ICMP errors & informational - IPsec errors subgroup has worked Solution space for ND - NA security concerns the right of a node to make assertions about an address - RA it is not clear how to delegate the authority ; store certificate at subnet router anycast Draves: how do you resolve NA Crawford: unauthenticated neighbor cache used just to create authenticated cache Nordmark: router authentication Crawford: how do you understand that a given prefix is valid for this subnet; Draves: auto config problem, how do you figure out who is the authority ???: AAA addresses this with pre-configured shared secret Deering: multiple smart card slots in every host Mankin: work in trusted third party solution space as thesis. Solution space for MLD - (blank) Work items - ICMP errors - Invade the IPsec WG and demand more Nordmark: No one is working on the problem of how to make this better ICMP info - Done deal ND - V6 specific as spin-off of this group ; RA is harder MLD - Almost congruent to IGMP? Site Scoping Issues (T. Narten) ------------------------------- Multi-homing Source address selection becomes the key issue How to assign block to multihomed site How to assign addresses to nodes within site Outbound packet filters may block from wrong source Scope must be same for source & destination is a debated issue State of Plug-and-Play (B. Hinden) ----------------------------------- "Dentist's office" Secure "Dentist's office" 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. SCENARIO 1 - ISOLATED [isolated figure] SCENARIO 2 - CONNECTED [connected figure] SECURE PLUG AND PLAY? - Is Security and Plug and Play an Oxymoron? o Security requires knowledge of a Secret o Autoconfiguration wants to be Stateless - If a node knew the Secret o Could everything else be automatic? o Use Hardware token? WHERE ARE WE NOW - ND and AddrConf o Global Address Creation o Router Discovery o IP Parameters - DHCPv6 - Service Location for IPv6 - Router Renumbering o Centralized reconfiguration of Router Advertisement Information - DNS o Automatic Creation of Reverse Map Comment SLP uses URL's Action: Hinden will write a draft defining preferred literal URL format. 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 - Secure Plug and Play o Simple, Easy, and Still Secure? SOLUTIONS - Role of Service Location Protocol o Appropriate for General Service Location o Works with and without Servers o Can simple client only version suffice? o Are people implementing it? - 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 configuring this info in Routers o What if no Router? - DNS Server Advertisements? o Does SL do this? - 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 - Should we Pursue this Work o Is it an important problem to solve? o Are we close enough now? - Where / How? o IPng w.g. o New w.g. Discussion: Nordmark: Will router to the Internet be a substantial services platform as well? Hinden: There will not be a single answer, some want minimalist router, others want full load. Deering: We need something that works like appletalk; when the magic do-it-all box is broken the network still needs to work. Bound: Scenario 2 the box wants to be both a router & host How can telco provide a service on minimal end point, it is important scenario. Durand: It is now my home network so now I the last thing I want is a DNS server. Conclusions: Making the isolated case work well, and securing auto-configuration appear to be the important issues. Issues in IPv6 Multihoming (J. Hagino) -------------------------------------- [No notes] Better Support for Multihomed Hosts (R. Draves) ----------------------------------------------- Multi-homed hosts defined several ways - Host with 2 interfaces into different networks Host with 2 interfaces into the same network - Host with 2 interfaces onto the same link Interfaces have several definitions - Physical interfaces - Virtual interface (will do ND on this) - Pseudo interfaces (will not do ND, just exists as a matter of convenience) VPN's & dial-to ISP becoming more popular Transition mechanisms encourage multi-homing Firewalls exist in this space Problems: Next hop determination (really next link) - ND has conceptual data structures per interface, but no mechanism to identify interface - Proposal to add info to RA Policy decision by user via multicast announced scope - Partial Aggregation is likely to cause more trouble than it helps Detecting same link - Work in IEEE may address this Switching to different interface - General case of the router renumbering issue Weak v.s. strong host model Deering: Old issues that will not converge, best we can do is document the consequences for each choice Better Support for Multihomed Sites (E. Nordmark) ------------------------------------------------- API is the only thing missing from the day's discussion Bound: What part is the API v.s. network layer Deering: The appropriate place for now it the API doc Syn6 scope ID - context dependent definition Modifying all apps is not realistic, so get addr info Bound: Get addr info is not scaling well in deployment Source and Destination Address Selection (T. Narten) ---------------------------------------------------- When initiating which address to choose, selecting 'best' is not easy for applications Favor preferred addresses over deprecated Site local v.s. global scope; choose global if expectation is to be mobile One way to scale multi-homed site; assign prefix for both ISP's Consider adding a 'middleware' layer that addresses policy Privacy issues with use of EUI-64 IDs (T. Narten) ------------------------------------------------- Link prefix obtained from RA. IID could be exploited to identify user. Uproar from privacy groups over hardware serial numbers Potential negative PR Is there a need to change IID more often than each reboot. Use clock value to randomize? Bound: This could be a lot of work, and we already have a lot of work Caller ID as a model Making TCP use Global Interface IDs (A. Mankin/T. Narten/M. Crawford) --------------------------------------------------------------------- [No notes] Formulate recommendations to the IESG/IAB, re: future IPv6 work (S. Deering, B. Hinden) ---------------------------------------------------------------- Note: This session was held on Thursday Feb 4. WG Docs to Finish up - MLD - ICMP revision o Scope-exceeded err, no error to redirect, editorial - Advanced API - router renumbering - merged jumbo gram specs - generic tunneling (add bidirectional tunnels) Unfinished IPng W.G. work - Flow label standardization (no action now) - scope issues, source address selection - multihomed host/site issues - autoconfig <-> DNS <-> mobile IP story - URL format for IPv6 literal address. - dial-up issues? Work still covered under original charter. Discussion about what "autoconfig <-> DNS story" means. Mechanisms may be there, but need to describe. Additional discussion. Comment that the story is written. Probably no IPng protocol work required. Nordmark made comment that what about creating names for devices w/out keyboards (e.g., phones, light switches, etc.). Need generic names and/or way of updating name via the network. New IPng w.g. Tasks - Specify transient interface IDs for privacy concerns - Specify E.164-in-IPv6 addressing - Specify IPv6 over additional media o USB ? o Bluetooth ? o 1O Gig pipe ? o IEEE 1394 ? - Start an IPv6 "Host/Router requirements" document Other Current w.g. chores - Keep all w.g. docs moving along publication / standardization track - Identify "base spec" of docs for advancement to full standard Other lower-layers WGs to prod - DNS, DHCPv6, IPv6-over-Firewire, Mobile IP, RIPv2, OSPF,ISIS, IDR, MOSPF, PIM, Diff-Serv, AAA (Diameter), Malloc (maybe) New work for other W.G.s - IPv6 readiness check (incl. MIBS, etc.) - Secure ICMP/ND (IPSEC) - Authenticate, Autoconfiged hosts (IPSEC) Other idea to pursue, perhaps in new w.g.(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 (single subnet spans multiple links) - Scope-name discovery - Conformance tests - Tools for reducing network mgt 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/accounting opportunities - Architected MLD snooping - Firewall in the host - ICMPv3 -> MLD Suggestion to add better multicast routing for IPv6. Other - Convey message that "IPv6" is done"; time to implement deploy, and port applications - Review/strengthen "cast for IPv6", "case against NAT" docs - Keep prodding IP address registry - Develop a voice-over-IPv6 story - Participate move in other WGs - Pass API docs to other stds bodies Suggestion to find individuals to track work in other working groups. A specific individual for each group. Will do a call for volunteers on mailing list. Suggestion by AD that we should update charter focus on remaining work and how to get to completion. Discussion about how/when to wrap up the working group. Suggestion that we go on "hiatus" after "base specs" are completed (Draft standard). Other comments that it is important to continue the w.g. to have an "official" forum to communicate / send recommendations to ICAN, IAB, IP registries, etc. Chairs will discuss future w.g. steps w/ AD's and make recommendation to w.g. ------------------------------------------------------------------------- ------------------------------------------------------------------------- Meeting Adjourned ------------------------------------------------------------------------- -------------------------------------------------------------------------