Editor's note: These minutes have not been edited. IPng Working Group Minutes Montreal IETF June 24,25,26, 1996 Steve Deering / Xerox PARC, Chair Robert Hinden / Ipsilon Networks, Chair Minutes taken by Robert Hinden ----------------------------------------------------------------- ----------------------------------------------------------------- Steve Deering introduced meeting. Robert Hinden agreed to take minutes. Reviewed other working groups discussing IPv6 issues. Reviewed agenda. Asked for additional topics. The agenda agreed to was as follows: Monday 1930 - 2200 ------------------ Introduction - Steve Deering & Bob Hinden 10 min Document Status - Bob Hinden 10 min Status Reports (each 10 min or less) 130 min UNH Testing - Bill Lenharth Header Compression - Micke Degermark IPv6 Tunneling - Alex Conta Interface IDs - Robert Elz UDP & TCP/MSS vs. Jumbograms - Dave Borman Neighbor Discovery - Tom Narten ITU Request for IPv6 Addresses - Bob Hinden IPv6 Auto-Configuration - Sue Thompson DHCPv6 - Jim Bound IPv6 Mobility - Dave Johnson RIPng - Bobby Minnear OSPFng - John Moy IDRPng - Yakov Rekhter IPv6 over FDDI - Matt Crawford IPv6 over NBMA - Grenville Armitage IPv6 over PPP - Dimitry Haskin IPv6 Multicast Routing - Steve Deering Routing Table Size Issue - Ran Atkinson Tuesday 0900 - 1130 ------------------- Host Anycast - Jim Bound & Pedro Roque 30 min Multihomed Hosts - Mike Shand & Matt Thomas 30 min BSD API Issues - Bob Gilligan 30 min Naming Link-Local Addresses - Dan Harrington 10 min Router Alert Option - Ran Atkinson 10 min Host Handling of Route Header - Steve Deering 10 min Open 30 min Wednesday 0900 - 1130 ------------------- Spec Changes/Clarifications - Steve Deering 30 min Advancement of main specs to Draft Standard? 10 min Open for Additional Topics and continuation of 100 min earlier topics Conclusion / Interim Meeting Scheduling 10 min ----------------------------------------------------------------- Monday 1930 - 2200 ----------------------------------------------------------------- Document Status - Robert Hinden ---------------------------- The following documents were approved by the IESG for proposed standard since the last IETF meeting: o "A Method for the Transmission of IPv6 Packets over Ethernet Network" o "An Architecture for IPv6 Unicast Address Allocation" o "Path MTU Discovery for IP Version 6" o "Neighbor Discovery for IP Version 6 (IPv6)" o "IPv6 Stateless Address Autoconfiguration" The following documents have completed both working group and IETF last call and are waiting for IESG action: o "A Method for the Transmission of IPv6 Packets over FDDI Networks" o "A Method for the Transmission of IPv6 Packets over Token Ring Networks" o "IP Version 6 over PPP" The "IPv6 over FDDI" document has been held up because of issues regarding how this should work in the presence of mixed media bridges. The current draft includes an expanded discussion and procedures for this case. The author and chairs believe this should enable it to proceed through the IESG. The "IPv6 over Token Ring" document is waiting for resolution of the "IPv6 over FDDI" document due to similar issues with mixed media bridges. The following document was returned by the IANA: o "OSI NSAPs and IPv6" The IANA returned the document to the working group because it used all of the address space allocated to the IANA for NSAPs. To deal with this a AFI has been assigned to the IANA and a new draft has been written. The working group was Queried about moving NSAP document forward without another w.g.last call and to ask the IESG to skip the IETF last call. Working group approved this course of action. UNH Testing - Bill Lenharth --------------------------- The second IPv6 interoperability testing event was held at University of New Hampshire the week prior to this IETF meeting. About a dozen organizations participated. These included: o Bay Networks o Digital Equipment o FTP Software o HP o HP/SICS o Hitachi o IBM o INRIA o Mentat o Sumitomo o Sun o WIDE UNH staff ran both conformance and interoperability testing. Many implementation problems were found and resolved. Overall of the systems tested 1/3 ran very well, 1/3 ran well but had missing pieces, 1/3 didn't run well. Major progress from previous IPv6 testing event. UNH plans to expand testing their IPv6 testing capability. Planning started for the next testing event in late October or early November this year. Also planning event at Interop Spring 1997. Header Compression - Micke Degermark ------------------------------------ Current draft is draft version 1. New draft deals with links which reorder and loose lots of packets. Demux structure is also different. Plan version 2, which will deal with RTP header compression. SICS has a working "alpha" implementation for NetBSD 1.1 (based on INRIA IPv6 implementation). Plan to distribute code in August. Author expects to be able to move draft forward to proposed standard in August. IPv6 Tunneling - Alex Conta --------------------------- New draft version 02. Changes include: o Removed old text from appendix A o Moved section 4.1.4 (risks of recursive encapsulation) to Appendix A. o Added section 3.2, packet processing in tunnels o Added 8.4, ICMP messages generation. Discussion ICMP generation in case of recursive tunnels o Improved text and figures. Working group agreed to move this document forward and do a working group last call. UDP & TCP/MSS vs. Jumbograms - Dave Borman ------------------------------------------ How do UDP and TCP deal with Jumbograms. Dave Borman did not attend. Check w/ Dave Borman to see if wants to pursue this work. Neighbor Discovery - Tom Narten ------------------------------- On RFC editor desk. ITU Request for IPv6 Addresses - Robert Hinden ------------------------------------------- The IETF received a request from ITU-Telecommunication Standardization Sector STUDY GROUP 17, Rapporteur Q3/7 on 17 July 1995. The ITU requested an IPv6 Format Prefix for X.121 Public Data Network Addresses. It also suggested that ITU-T Study Group 2 may also make a similar request for E.164 addresses. X.121 Public Network addresses are not Internetwork addresses. As a result it would be better to treat them as IPv6 handles other networks such as Ethernet, FDDI, etc. We should define interface identifiers from the X.121 addresses. The BSD digits of the X.121 address would be converted to binary. An IPv6 over X.121 Public Data Networks document could be written. A suggestion was made that there is also an AFI for these type of addresses in the NSAP space. This would fit into the framework defined in "OSI NSAPs and IPv6" document. This could accommodate their needs. Christian Huitema suggested was ask them how this would be used. Ross Callon suggested to invite them to come to the IETF and talk about what they had in mind. The IPng document editor will draft a response. IPv6 Auto-Configuration - Sue Thompson -------------------------------------- On RFC editor desk. DHCPv6 - Jim Bound ------------------ The architecture is stable. Uses features of IPv6 and stateless addr configuration. Changes DHCPv4 architecture in significant way. Document now contains appendix describing differences. The use of IPv6 multicast helped the architecture extensively. Also integrated w/ Dynamic Updates to DNS. Security authentication model defined, but no consensus yet. New relay agent model. Bound expects implementations by October 1996. Place to request advance to proposed standard after December 1996. There will be a public domain code base. Expect to test at next UNH test event. RIPng - Bob Hinden ------------------ A new RIPng draft has been published. It includes a few mechanisms from the RIPv2 protocol not included in the first RIPng draft. This is expected to move forward in the RIPv2 working group. OSPFng - John Moy ----------------- New draft version 02. Complete specificaiton. Will be discussed in detail in OSPF meeting. Major changes from previous version o Runs directly over IPv6 o Addressing semantics removed from LSA header, router LSA, network LSA and just in other LSA's. Results in all address being removed from base OSPF headers. o Run per-link, not per-subnet, explicit support for multiple instances per link. o Uses IPv6 authentication header and encapsulation security payload. o Supports OSPF extensions: MOSPF, NSSA areas, and demand circuits o Incremented OSPF version from two to three. LSA Format Changes o LS type now explicitly encodes flooding scope (link local, area, global) and handling of unknown LS types. o Link state ID remains 32 bits o Advertising router remains 32 bits o Router-LSA can be fragmented IDRPng - Paul Traina -------------------- o IDRP for IPv4 and IPv6 (think about as BGP-5) o Based on BGP4 / IDRP o FIB tag for extensible / divergent routing (e.g., QOS and unicast vs. multicast) o Uses IDRP transport mechanisms (multicast "flooding" in the future) o IDRPv1 state eliminated. Route withdraws are now supported. IPv6 over FDDI - Matt Crawford ------------------------------ Presented issues which caused IESG to not move this forward the when it was first submitted. The main issue was how this should function in the presence of mixed media bridges (e.g., FDDI <-> Ethernet). The goal for the current design is to not require any IPv6 intelligence in a mixed media bridge. Lots of mixed media bridges exist and are heavily used. Proposed mechanism is for any node on an FDDI ring to send traffic with a non-zero value in FDDI LLC priority field. Bridge will set this field to zero when going from Ethernet to FDDI. Field does not exist on Ethernet. All routers can advertise an ethernet size MTU in IPv6 neighbor discovery. All nodes start sending multicast packets with 1500 MTU. Nodes can only send larger MTU packets when receive LLC Non-zero value. Author discovered after ID was written, that DEC VAX cluster uses a very similar algorithm to deal with the same issue. IPv6 over NBMA - Grenville Armitage ----------------------------------- Tuesday ION working group session is discussing this issue. Main issues are how to do cut through, how to keep IPv6 neighbor discovery with out changes or to develop a alternative mechanism to neighbor discovery. IPv6 over PPP - Dimitry Haskin ------------------------------ Changes from the previous draft o Token flag reduced to 32 bits o Clarifications to text Competed working group and IETF last call and been sent to IESG. IPv6 Multicast Routing - Steve Deering -------------------------------------- One missing piece of IPng is multicast routing protocols. Discussed to document how to represent multicast routing table independent of specific routing protocols. There is a large number of multicast routing protocols in IPv4. We should be able to reduce number of multicast routing protocols. We should also be able to eliminate the need for separate multicast tunnels. Multicast routing topology should be same as unicast topology. Suggested we don't need to do DVMRP for IPv6. PIM dense mode should be fine. Deering has summer students working on IPv6 multicast routing. Plan is to implement PIM dense mode for IPv6 multicast routing. Tom Pussatari noted that MOSPF has been specified and also provides IPv6 multicast routing. Note that new PIM dense mode specification also supports IPv6. Routing Table Size Issues - Ran Atkinson ---------------------------------------- Outline o IPv4 Routing entry size o IPv6 routing entry size IPv4 Routing Entry o Has two components: 32bits entry, 32bit masks IPv6 Routing Entry o 128 entry, 128 bits mask [Editors Note: Most implementations would likely not use a 128bit mask, but would instead use a 8 bit prefix length.] o IPv6 has native addresses and IPv4 compatible addresses Routing table issue o Routes for native addresses are not a big problem. o If IPv4 addresses were carried in IPv6 table would increase memory requirements by a large factor. Alternatives o Router filter out IPv4 compatible prefixes. o Do nothing o Do not put compatible addressing IPv6 table. Proposed Approach o Clarify IPv6 routing protocol specifications to prohibit transmission of IPv4 compatible IPv6 routes as if they were IPv6 routes. Implementations: o IPv6 routes will use the V4 routing table to lookup compatible addresses. Recommendations o Add clarification to NG Trans draft. Modify IPv6 routing protocol specifications: - IGP: OSPF, RIPng, I/ISIS - EGP: IDRP Group discussion on how to deal with this. There was general agreement that it is a good idea in the short term to keep IPv4 and IPv6 routing tables separate. Especially for backbone networks. This is an important issue for internet service providers. However there may be some environments where it is desirable to add IPv4 compatible routes to an IPv6 routing table. It is not clear it this recommendation has to be done in each protocol document. Could be dealt with in separate standalone document. It was noted that this issue is covered in NG-Trans routing document, but needs to be made clearer. Chairs asked that a standalone document be written which specifies this behavior. Ran Atkinson will send email. Document editor volunteered to help to turn into an internet draft. Default Hop Limit ----------------- What should be default Hop Limit be in IPv6? Deering suggested 64. Frank Kastenholts suggested max value. Much discussion. Group decided to use max value of 255 as the default IPv6 Hop Limit. IPv6 Mobility - Dave Johnson ---------------------------- Mobile IP w.g. has consensus on basic approach and protocol. Current draft isd raft-ietf-mobileip-ipv6-01.txt. Design philosophy is a combination of what we learned with Mobile IPv4, new features present in IPv6, and opportunity of a new IP. Important functions for Mobile IP o Reliable and timely location and notification to nodes that need it o Correspondent nodes communicating with a mobile node o The mobile node's home agent Basic Operation o Mobile node always addressable by home address o Mobile node away from home also has a care-of-address o Mobile node sends notification through Binding Update o Movement detection through Neighbor Discovery Binding Option is a new IPv6 Destination option (may be included in any packet). Home address for binding must be IPv6 source address. Packet must include IPv6 authentication header. Binding acknowledgment message is a new IPv6 informational ICMP Message. Only needed if acknowledgment set in binding update. Requirements for IPv6 Nodes: o Every IPv6 node must be able to: 1) Receive binding updates and send binding acknowledgments, and 2) Maintain a binding cache o Every IPv6 node that wants to be a mobile node must be able to: 1) Perform IPv6 unencapsulation, 2) send binding updates and receive binding acknowledgments, and 3) maintain a binding update list of unexpired bindings set. Requirements for IPv6 Routers o Every IPv6 router must be able to use a binding cache entry to encapsulate for forwarding. o At least one router in a mobile nodes home network must be able serve as a home agent. o Mobile nodes which function as a home agent, must be able to: 1) Maintain a registry containing the mobile nodes binding, 2) Intercept home network packets for mobile node, 3) Encapsulate the the mobile node's care-of-address. ------------------------------------------------------------------ Tuesday 0900 - 1130 ------------------------------------------------------------------ Host Anycast - Jim Bound & Pedro Roque -------------------------------------- IPv6 Anycasting Service / Minimum Requirements Goals: Anycast initiated communication Anycast Problems o Server configuration, o Routing o Unicast reply to anycast datagram (mechanisms must be present in all IPv6 nodes). Solution independent of the above two problems, no changes to TCP/UDP specifications Layering Issues o Anycast addresses are a Network issue o Transport must be able to identify datagrams belonging to the same communication Transport/Network Interface o No mapping is performed between identifier and locator o BSD based implementations o Interfaces: transp_input() transp_output() Discussion about the need for a mapping between identifier and locator. Should not be eliminated for possible future use. Operational Model [Editors Note: Time based packet trace not included in minutes] Client: S=uncast_A;D=anycast Server: S=uncast_B;D=uncast_A[Id=anycast] Client: S=uncast_A;D=anycast o Stateless UDP o TCP and state-full UDP anycast initiated communication Identification Option Processing o Network passes information to the transport layer o TCP: state SYN-SENT, demultiplexing by identifier, destination->unicast source address o UDP: applications must select the appropriate behavior, demultiplexing by identifier Deering: If server adds an options which says this was an anycast address, the client will know that the response was in response to a request sent to an anycast address. Open Issues o TCP - receipt RST/ACK segment in SYN-SENT An RST/ACK segment on an active open implies there is no listener. o Security (authentication) o UDP API Issues o Special case of anycast address represents the interfaces of an multi-homed host. Discussion about whether this is a change to TCP/UDP. Presenter disagreed, but it is a change the the behavior for TCP implementations. Discussion about need for RST/ACK semantics. Suggestion for TCP options or other mechanism. Naming Link-Local Addresses and Names - Dan Harrington ------------------------------------------------------ Introduction o Issue is that Plug and Play is limited without names. o Hex addresses are not finger friendly o Limited scope addresses do not belong in the DNS Proposal o Server / Advertisement +--------------+ | FE80::8AF1:C | +--------------+ | fred | +--------------+ o Client Request +--------------+ +----------------+ | ??????? | | FE80::CAFE:A8E | +--------------+ +----------------+ | barney | | ???????? | +--------------+ +----------------+ o Lifetime / Cacheing o Link-local multicast Issues o Interaction w/ resolver (.link pseudo-domain might be nice) o Duplicate names / addresses o Doesn't scale to CERN's LAN o Some (how much?) overlap with Service Location protocol Robert Elz thought overall was a good idea. Would remove simple names and allow fully qualified DNS names. Deering: three questions. 1) Both advertisement and on demand approach. Why both? Wanted to allow both types of interaction. 2) For query could use solicited node multicast address. 3) Overlap with service location? This could be input to service location working group when they deal with IPv6. [Editors Note: The service is starting to work on an IPv6 version of service location.] IPv6 Router Alert Option - Ran Atkinson --------------------------------------- Problem: o Some Control packets (IGMP, RSVP) that need special processing by a router but are not addressed to a router. o Desire to not have to look at all packet options in transit packets. IPv4 Approach o Control packets which contain this option are fully processed Proposed IPv6 Approach o Identical concept as for IPv4 o IPv6 Hop by Hop options Which Packet use Router Alert o IGMP o RSVP Implementation Issues o All hosts must add this option for IGMP/RSVP packets o Routers must process packets which receive this option o Control packets which do not contain this option might not be processed correctly by routers Discussion: KRE liked idea, but suspects RSVP should be a Hop by Hop option itself. Should not follow IPv4 model for this case. Deering: Need to clarify processing semantics: Just for IGMP/RSVP/etc, or process all of the packet (like it was addressed to router). We should consider allowing larger hop by hop options. General discussion about how RSVP would better if this was done with a hop by hop header. This will be discussed more on Wednesday. Host Handling of Route Header - Steve Deering --------------------------------------------- What should host do with route headers? Can a host process a route header or should routers only process route headers. Current specs permit hosts to process route header. Mobile IP has a special case where this is used. Another issues is should hosts reverse source route when replying to packets containing route headers. Should hosts only support route reversal if packet authenticated. Mobile host does not require route reversal. Third issues: What if both application and IP layer adds a routing header? One have priority over the other, or add both route headers? Proposes 1) Hosts Must process route headers. 2) Decision to reverse route headers is at transport level. Strongly suggest that authentication be used here. Simpler rule is at the present, we do not recommend that hosts reverse routes. Add this to next draft of base IPv6 specification. Suggestion from Charlie Perkins for another route header (one which is required to be reversed, one which is not). BSD API Issues - Bob Gilligan ----------------------------- Overview of Discussion Differences between current spec and previous issues raised. Current draft is version 05, April 18, 1996 Changes o Eliminated source route and interface identification features - Group could not agree on right way to provide these features - Could be proposed in follow on document. - Most applications do not need these functions, doesn't hold up "basic" spec. o Replace hostname2addr() with Posix getaddrinfo() function o Replace addr2hostname() with new getaddrinfo() function donated by Keith Sklower - Want to use existing standards when they exist. o Changed name of addr2ascii() to inet_ntop() o Changed name of ascii2addr() to inet_pton() - Semantics unchanged - Function name prefix needed to avoid conflict with user and other library functions Issues Raised o Spec should give function prototype for getaddrinfo() - Concern that Posix might change function - Our specification would have to track Posix specification o Proposed Resolution - Include function prototype in specification - Add caveat saying that Posix document is definitive specification Suggestion to make this a separate draft. Would make easier to update later. Deering: Thinks it is important to include interface identification. Asked why this was not included. Answer was that it will be dealt with later in separate document. Many other comments saying that it is very important to support interface identification o Name prefix for inet_pton() and inet_ntop() - Implies IP specific functionality, but functions are designed to be generic. - But "inet_" is prefix least likely to cause name conflict o Proposed resolution - No change o Name suffix for inet_pton() and inet_ntop() - Hard to infer meaning from name - Issue of "taste" o Proposed resolution - No change o Lower level name/address translation functions are needed - Changing existing apps to use getaddrinfo() is hard. o Proposed resolution: - Add definitions for gethostbyname(), gethostbyname2(), and gethostbyaddr() - No change to getaddrinfo() or getnameinfo() definitions. Other issues: o Interface identification o Interface naming for multicast Working group agreed to move this forward. Hinden queried group to ask for if there is any remaining issues. There are major issues with how to do interface identification. This will be very hard to resolve. Still very important to add to API. Current proposal is to handle this in separate document. Proceed now with "basic" specification. Additional issue raised: o Enable/Disable PMTU per-Socket (wants to fragment at 576 MTU, instead of interface MTU) Some discussion, no consensus. Person suggesting will write a short draft. o Flow ID & Priority - Structs vs. bitmask Some discussion. Will be left the way it is now. o Interface naming for Multicast Deering suggested we wait for conclusion of link local address discussion on Wednesday. ------------------------------------------------------------------ Wednesday 0900 - 1130 ------------------------------------------------------------------ Spec Changes/Clarifications - Steve Deering ------------------------------------------- Changes from UNH Testing o Determination of neighborness for strict source route How to decide if next hop is a neighbor? Deering will propose clarification on the mailing list. o Should Echo Replies be truncated to return MTU? No, they should be fragmented. o Need for "Full Info" flag in Router Advertisement - Unsolicited RA's may omit some info, e.g., long lived prefixes - Solicited RA's may be multicast - When a host solicits on startup first head RA, terminates solicitation - Solicited and unsolicited RA's are indistinguishable Result is that Host may not receive all info in response to solicitation. Possible solutions include: 1) Put all info in all RA's 2) Unicast all responses to solicitations 3) Add "solicited" for "full info" flag to RAS; Only Full info RAS would terminate solicitation. Discussion. Not clear how much of a problem this is. Will be discussed on mailing list. o NUD vs. Router Discovery - If NUD reports all known routers are down, for those destinations that were previously being reached through a router, should a host: a) Assume on-link and solicit locally, or b) Continue to assume off-link, until lifetime of all received RA's have expired? Discussion. Second case is the specified behavior. o What response to fragments that exceed reassembly buffer size? None. Drop packet with no error reply. o Should receivers discard overlapping fragments? Drop overlapping fragments. o Can Packets to link-local destination be forwarded onto same link? Address Arch need to expand rules to cover both source and destination link-local addresses. OK to allow router to forward these packets back on the link it came in on. o Link-local address used in route header? Two cases: 1) S1 -> L1 -> L2 R | L1 ---------------- | | L2 S1 D 2) S -> G -> L S ----.....-----R | G ---------------- | L D Do not allow link local addresses in route header. First might be ok. Deering will think about and send analysis on mailing. o Clarify format + byte order of IPv4 addresses embedded in IPv6 address representation Fix in spec. o Support options with data > 255 bytes? Would be useful for RSVP, etc. Options include: 1) Make length field bigger 2) Define new "big options" 3) Escape length 4) Semantically fragment option data 5) Forget it (e.g., just say no) Do not change spec and suggest 4) if bigger options are needed. o Eliminate (reserve) the priority field (and exclude from Authentication Header (AH) computation? Currently encourages hosts to sent more packets than will get through to the destination. Encourages bad behavior. Deering suggests this is a research topic and we should get more experience before specifying. Discussion that it can be used now to distinguish control traffic now (e.g. router updates, etc.). Would also be nice to have some reserved bits that could be used for new features later. Neighbor discovery currently specifies a priority for ND packets. Group agreed to set the bits to all zeros now. Less clear about excluding them from the AH. Discuss issue further on mailing list. Multihomed Hosts - Matt Thomas ------------------------------ Cases: ----------- ----------------- | \ / | \ / | \/ | | H H ----------- ----------------- | | | H H R------ | | | ----------- ----------------- 1) Did we cover the right cases? 2) Working group comfortable with anycast proposal? 3) Choosing and Interface? a) Never lose a packet? b) Never duplicate a packet? c) Application dependent? First case (a) may mean sending over all interfaces 4) Is there one mechanism or will we need lots of mechanisms? Discussion about building mechanisms for multihoming in IPv6 or use IPv6 Mobile Host support, and how mobility support can help with this problem. Some consensus that mobile IPv6 might be a better way to deal with these problems. Currently do not think the anycast solution is fleshed out enough. Document is good overview of the issues, but as of today we can not pick a specific solution. Group thought work is important and should proceed. Interface Token Size - Robert Elz --------------------------------- Raised issue about how big a token should be. Is it 48bits or can it grow? Deering proposes that we make maximum token length 48 bits. Group agreed to adopt this limit. Interface IDs - Robert Elz -------------------------- Reviewed proposal to add interface identifier to link local definition. Would add interface token to link local address. Discussion and questions about proposal. Proposal is compatible with current link local address definition (e.g., interface token is zero). Comment that there is no reason to have this extra information on the wire. This is dealing with a local problem inside of a machine. Author did not agree. Deering said he hates this too and naming of interface is completely orthogonal to defining addresses. They should not be tied together. These addresses should not go out on the wire. Current spec does not require any changes to hosts which do not want to implement this. Dennis Fergusion this is useful because multiple links might be bridged together later and the way we use link local would cause conflicts (e.g., routing protocols). Erik Nordmark thought the routing protocol issues could be dealt with in different ways. Comment that link local may change because interface token may change based on how host creates the interface token. Nordmark raised concerned that this was adding a lot of complexity to specifications. Deering suggested that real issue is generating duplicate tokens. Duplicate Address Detection (DAD) should be redefined to have this view. Brian Carpenter noted that this is really a L2 problem. DAD needs to look at whole address. If you end up with multiple interface on the same LAN, it does not work correctly. Ethernet gets multiple packets. FDDI will does not work. Deering polled group. Slightly more thought ok, but not clear consensus. Group needs to resolve this on the mailing list. Author encourages people to send comments. ------------------------------------------------------------------------ ------------------------------------------------------------------------ Meeting ended. The following agenda items were not discussed due to lack of time: o Advancement of main specs to Draft Standard? o Reverse Name Lookups of IPv4 Compatible Addresses - Paul Vixie o Conclusion / Interim Meeting Scheduling These will be discussed on he mailing list. ------------------------------------------------------------------------ ------------------------------------------------------------------------