CURRENT_MEETING_REPORT_ Reported by Bob Hinden/Sun Microsystems Minutes of the Simple Internet Protocol Plus Working Group (SIPP) The SIPP Working Group held an implementors' meeting on Sunday, and two working group sessions during the week. The first session was on Wednesday and the second session was on Thursday. The first session was multicast on the Internet. The minutes from the implementors' meeting were taken and written by Jim Bound. Review Agenda The agenda for the meeting was: o Review Agenda o Working Group Status o Implementors Meeting Report o SIPP Specification Update o Discover / Auto Configuration o IPAE Overview Working Group Status Bob Hinden reported that the working group charter was approved. The SIPP Working Group is now official! A ``white paper'' on SIPP was written and submitted to the IPng Area Directors. It has been published as an Internet-Draft and will appear as a ConneXions article. This was the only IPng white paper which was submitted on time. A large number of documents were published as Internet-Drafts. They include: R. Atkinson, ``SIPP Authentication Payload,'' Internet-Draft, draft-ietf-sipp-ap-01.txt, January, 1994. W. Simpson, ``SIPP Neighbor Discovery,'' Internet-Draft, draft-ietf-sipp-discovery-04.txt, March 1994. W. Simpson, ``SIPP Neighbor Discovery -- ICMP Message Format,'' Internet-Draft, draft-ietf-sipp-discovery-formats-00.txt March 1994. S. Thomson, ``Simple Internet Protocol Plus (SIPP): Automatic Host Address Assignment,'' Internet-Draft, draft-ietf-sipp-auto-addr-00.txt, March 1994. S. Thomson, C. Huitema, ``DNS Extensions to support Simple Internet Protocol Plus (SIPP),'' Internet-Draft, draft-ietf-sipp-dns-01.txt, March 1994. S. Thomson, ``Simple Internet Protocol Plus (SIPP): DHCP Options and BOOTP Vendor Extensions,'' Internet-Draft, draft-ietf-sipp-dhcpopt-01.txt, March 1994. R. Govindan, S. Deering, ``ICMP and IGMP for the Simple Internet Protocol Plus (SIPP),'' draft-ietf-sipp-icmp-igmp-00.txt, Internet-Draft, March 1994 S. Hares, ``IDRP for SIP,'' Internet-Draft, draft-ietf-ipidrp-sip-01.txt, November 1993. R. Gilligan, et. al., ``IPAE: The SIPP Interoperability and Transition Mechanism,'' Internet-Draft, draft-ietf-sipp-ipae-transition-01.txt, March 1994. P. Francis, ``OSPF for SIPP,'' Internet-Draft, draft-ietf-sip-ospf-00.txt, February 1994. G. Malkin, C. Huitema, ``SIP-RIP,'' Internet-Draft, draft-ietf-sip-rip-00.txt, March 1993. S. Deering, et al, ``Simple Internet Protocol Plus (SIPP): Routing and Addressing,'' Internet-Draft, draft-ietf-sip-routing-addr-01.txt, February, 1994. R. Atkinson, ``SIPP Security Architecture,'' Internet-Draft, draft-ietf-sipp-sa-01.txt, March 1994. R. Atkinson, ``SIPP Encapsulating Security Payload (ESP),'' Internet-Draft, draft-ietf-sipp-esp-01.txt, March 1994. S. Deering, ``Simple Internet Protocol Plus (SIPP) Specification,'' Internet-Draft, draft-ietf-sipp-spec-00.txt, February 1994. P. Francis, ``Simple Internet Protocol Plus (SIPP): Unicast Hierarchical Address Assignment,'' Internet-Draft, draft-ietf-sip-unicast-addr-00.txt, January 1994. A SIPP Mosaic page has been created on http://town.hall.org. The SIPP Mosaic page includes an overview of SIPP, information on the working group, a summary of current specifications, and information on SIPP implementations. Authors of SIPP documents should send a short biography and picture (in GIF format) to Bob Hinden. Implementors' Meeting The SIPP implementors' meeting was organized by Jim Bound, in collaboration with Steve Deering, Paul Francis and Bob Hinden, the SIPP co-Chairs. The SIPP Working Group would like to thank Megan Walnut from CNRI for assisting the group to obtain a meeting room for this meeting. The meeting was attended by the following main participants: Steve Deering, Bill Simpson, Ran Atkinson, Dan McDonald, Sue Thomson, Ramesh Govindan, Bob Gilligan, Steve Alexander, Jim Bound, Alex Conta and Peter Grehan. Also in and out were: Christian Huitema, Sue Hares, Dino Farinacci and Allison Mankin. The meeting focused on the SIPP protocol specifications and implementations issues. The meeting was lead by Steve Deering. The first part of the meeting consisted of status reports. Each participant presented his/her implementation status: o Bob Gilligan of SunSoft: The SIPP/IPAE prototype can exchange messages with IP hosts using the IPAE mechanisms. o Dan McDonald and Ran Atkinson are working on a NRL implementation which is at a very initial stage. The intention is to place the NRL implementation in the public domain. o Sue Thomson and Ramesh Govindan from Bellcore are also working on an experimental implementation, which may be made available in public domain. o Alex Conta, Peter Grehan, and Jim Bound presented the status on the Digital IPng prototypes - OSF/1 and OpenVMS. Digital's approach is to begin the prototype with kernel development for the SIPP protocol engine that will in the future support SIPP interoperability testing for the specifications. The second part of the meeting consisted of a protocol specifications walk through from the prospective of specific implementations. The review went deep into the specifics of the SIPP protocol design and SIPP headers layout. All discussion cannot be possibly captured in these minutes, and will focus on what was altered as a result of this meeting. Steve started the SIPP header review by providing more details regarding the flow ID field, which is supposed to contain a traffic class subfield, a quality of service (QOS) subfield and a flow ID number, which is randomly chosen or negotiated. For setting and getting the values, Alex Conta, Jim Bound, Ran Atkinson and Bob Gilligan discussed the potential of using a `setsockopt/getsockopt' type of API operation, similar to IPv4 in setting IP options. We all agreed on the mechanism to be used. Alex Conta further mentioned that the model should be extended to management, such that the implementations will no longer rely on operating system platform specific mechanisms. Eventually we could document the mechanisms as part of the SIPP documents or as a separate document. Further, during the review of the SIPP header, several commented that the size of the header and the position of the fields are very well thought out. Having a header which is a multiple of 64 bits optimizes caching and memory access, most likely on the 32-bit RISC processors, but it is optimal in particular on the 64-bit machine architectures like Alpha AXP. Alex made the comment that the `payload type' field being used concurrently for both multiplexing SIPP options and SIPP transport protocols, presents the risk of limiting the future number of SIPP options, and SIPP transport protocols. Additional comments on the size of the `hop limit' field were made, which seems too small - maximum 255. Though these comments have been made before, Alex felt they should be made again for clarity of a possible future issue. Steve commented that the decision on the current field sizes was made knowing the possible negative effects, and so they were left unchanged. Further, Alex made the comment that the SIPP payload length limit of 64 Kbytes may be too small in the future. This was also a topic discussed previously at length in the working group, with the current decision being defended vigorously by Steve Deering, Bill Simpson, and Ran Atkinson. It was decided to leave this discussion for now. Before starting the walk through the SIPP routing header, at the request of the attendees, Steve briefly presented a transparency on how the SIPP addressing is used in the SIPP advanced routing-hierarchy of provider, subscriber, subnet and node ID. Steve mentioned that this explanation was given to him by Paul Francis, the author of the SIPP advanced routing. The group felt this kind of clarity in the specifications was important to capture. During the SIPP routing header review, Alex made the proposal to shift the `next addr' field to the right 8 bits, such that accessing and computation on this field will not require additional shift instructions. The proposal was accepted in unanimity: Old: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type | Num Addrs | Next Addr | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . New: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type | Num Addrs | Reserved - MBZ| Next Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . During the SIPP fragment header review, Alex made the proposal to shift the `more fragment' bit to the very left, and leave the reserved bits next to the fragment offset. Then Alex proposed that the fragment offset be the natural offset value rather than the offset shifted by 3 bit positions to the right. The proposal was accepted in unanimity: Old: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type | Reserved |M| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . New: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type |M| Reserved | Fragment Offset |0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Additionally, Alex commented that since the offset is now a natural value, there is no other reason to require the 3 lowest significant bits to be zero and thus the fragments size be a multiple of 8 bytes, other than compatibility with IPv4 fragments, which is important for IPv4 to SIPP transition and coexistence. Everyone in the room liked the way the header looked after the change, and the general comment from Steve Deering and Bill Simpson was that the meeting was very substantive and therefore successful, and that they would like the working group meeting to be the same. During the discussions, Dino Farinacci joined the participants, and requested a move of the flow ID next to the SIPP source address for speeding up the flow ID-based caching and lookup. The group in general thought this was a very good idea, but unfortunately the field sizes did not allow an easy move, and therefore the change was dropped for now and would need some thought. It was generally accepted that we needed to keep the source and destination addresses aligned on 32-bit boundaries, as this is a big win perceived from most participants. On the authentication header, Peter Grehan mentioned that it is apparent that the MD5 algorithm is costly from a performance point of view. Ran Atkinson mentioned that there are other algorithms that could be looked at, and he will do that. A brief discussion followed about the position of the header, and how this affects its processing. Peter further tried to explain to the group his knowledge gained on the host kernel after building a prototype analysis for the SIPP security specifications, but it appeared most had not started this kind of kernel work and the group was not prepared to discuss this in depth. At this point, after about 2 or 3 hours of work, the group decided to break for registration and dinner, and return to continue the discussion afterwards. The registration and reception took about 30 to 45 minutes. Slowly the people regrouped and continued the discussion. On the hop-by-hop option header, Alex proposed a change to make the options in the header 8-byte aligned, since each hop-by-hop is a multiple of 8 bytes in length. While discussing the proposal, it became obvious that the text was not clear, which lead to a misunderstanding regarding the length of the options. Correctly, hop-by-hop options can be of any length, but the length of the header is a multiple of 8 bytes. The text will be corrected, and enriched with a suggestion to align hop-by-hop options to their natural boundaries. Christian Huitema underlined the importance of alignment for caching. Then, when discussing the `packet size issues' Alex reiterated that SIPP fragmentation/reassembly is allowed in end hosts, and that should be kept that way. Path MTU discovery will eliminate fragmentation in routers, but sender end hosts can fragment for UDP/IP applications that have user messages larger than the MTU size. The discussion that followed focused on payload size, so Alex presented graphs of the experiments and measurements done in Digital on OSF/1 and OpenVMS UDP/IP and FDDI on Alpha AXP. The graphs showed that the UDP/IP packet loss is a continuously decreasing function of user message size with a minimum at 64 Kbytes. The explanation is that the CPU time spent for user-to-kernel space crossing is significantly larger than the time taken for fragment reassembly, and therefore the system time spent per user message is inversely proportional the size of the message. Additionally, Alex argued that for using the pipeline effect of the SIPP fragmentation for UDP/IP, the size of a datagram must be several times larger than the maximum data link packet size, and already today there are 3 data links that have or allow 64KByte MTUs (HIPPI, Fiber Channel, and ATM). For achieving high performance pipeline for TCP, the window size limit of 64Kbytes had to be broken. Alex added that future data links may do fragmentation/reassembly at the link level, similarly to ATM, thus making the MTU size rather optional, and negotiable, with values larger than 64Kbytes. Applications such as audio/video use large messages, etc. Steve Deering and Bill Simpson argued that the per-packet system cost should be such that even at a payload size equal to MTU, the network should be efficient. Given that it was close to 9:00 p.m., Alex gave up, knowing that there are other ways to fix this. A short discussion, but no less passionate, followed about transport layer checksum. Alex and Jim argued for preserving in SIPP the IPv4 checksum characteristics. A slight change in the specifications will reflect the consensus reached. Around 9:00 p.m., we all left the meeting with a sense of accomplishment. Everyone was tired, but the general consensus among all participants was that the meeting was extremely productive, on target, and very successful. Participants at the meeting felt this was a very worthwhile event, and that it had the technical spirit of the work we should be doing at working group meetings for any work. SIPP Specification Update Steve Deering presented a summary of the changes reflected in the current SIPP specification. o The `flow label' is now specified as follows: 4 4 24 +-----+--------+------------------+ | Ver | TCLASS | FLOW ID | +-----+--------+------------------+ A flow is uniquely identified by the source address and flow ID. The flow ID is chosen randomly by the source. (There was some discussion about the value of random flow IDs for authentication.) Flow forwarding state is obtained from a control protocol or from information elsewhere in packet. All packets in the same flow must originate with the same destination address, hop-by-hop header options, and routing header. `Traffic class' (TCLASS) specifies the priority of a packet relative to other packets from the same source. Two priority ranges are defined: flow controlled traffic and non-flow-control traffic. o The authentication header in included in the main specification. It currently specifies MD5. Some concern was expressed that MD5 might be too slow. o The hop-by-hop options header was added. o Addressing details, ICMP, and IGMP were moved to separate documents. There was some discussion that the basic address formats should be in the base SIPP document. Steve Deering also pointed out some corrections to the latest specification. o Minor layout changes to fragment header and the routing header o UDP checksum value of zero disallowed from SIPP source o Corrected language for hop-by-hop options field size These changes will be reflected in the next version of the specification. ICMP and IGMP for SIPP Ramesh Govindan presented a summary of the current ICMP and IGMP for SIPP specification. The ICMP message format: The header preceding the ICMP message must have a payload type of 1. The pseudo-header checksum is the same as for TCP (except for IPv4 (C-Bit = 1) omit packet length). The processing rules for SIPP ICMP are: a) Silently discard unknown type messages. b) Include as much as possible of offending packet as will fit in 576 octets. A comment was made that it might be better if all pertinent information was included. Concern was raised about the case when the routing header had 255 entries. c) De-multiplex based on the original message payload type. d) Must not send error messages in response to: - Error messages - Packets addressed to multicast destination - Packet sent as link-layer broadcast - Not-initial fragment - SIPP special address Should not send more than n ICMP message per second for each error source Deering suggested an extension to allow MTU discovery when using multicast. There was also a discussion about rate limiting ICMP error messages. For ICMP destination unreachable there are five codes defined: Destination address unknown Payload type unknown Port unreachable Packet too big Administrative prohibited There was a discussion about need for `router unreachable' (to replace network unreachable) It was noted that the original ICMP codes should be used. There was a discussion to add `prefix unreachable.' It was decided to add a `cluster unreachable' type. A question was raised about the need for a non-authenticated code point? A question was raised about the need for a flow state lost message? Perhaps a new ICMP message? Steve Deering said that currently this is done in the flow state mechanism, and a separate message is not required. If a router can not use the flow ID, then it should just forward the packet with best effort. The discovery message will be used for both solicitation and advertisement and will have type/length/value (TLV) encoded ``extensions'' similar to the SIPP hop-by-hop option. The group reached consensus on basic formats. Bill Simpson will put out document on new formats. Media address extension contains the link layer address of the interface on which the message was sent. Erik Nordmark said this is needed for things like redirect (to avoid separate address resolution messages). Dino Farinacci asked if these can these be unicast for networks like X.25? Bill Simpson said that on networks which support multicast no, but on nets that do not support multicast it would be okay. Erik Nordmark said we need to define formats for specific media types. Bill Simpson said to use assigned number, just like ARP. Dino said that IDRP has a similar feature, and we might want to use that method. The routing information extensions include: Address sequence Prefix length Preference There were some concerns raised about the contents of these documents. Should there be a single ICMP messages document? A separate document for discovery formats? Something else? The group consensus was to have a single message format specification with a separate ``explanations'' document. SIPP Dynamic Host Address Assignment Susan Thompson presented the work on dynamic host address assignment. There are four different combinations which the dynamic mechanisms need to work. These are: o DHCP (with new options) for hosts without any routers o SIPP router discovery to allow host to discover subnet prefix from a router o SIPP router discovery and IPv4 DHCP o SIPP router discovery and SIPP DHCP All of these mechanisms assume the host has an unique identifier. Three new DHCP options are defined to support IPAE hosts. These are: SIPP prefix IPAE IPv4 reachability mask List of address sequences of SIPP routers Options are encoded as tag octet, length octet, and value. The options support address sequences and support a single SIPP prefix. SIPP router discovery works by a router advertising local use and global subnet prefixes. It can solicit a router advertisement on startup or when an interface is enabled. Hosts maintain lists of subnet prefixes, masks, and timer, local use addresses, and global address sequences. Their lists are updated on receipt of a router advertisement. Lists are also updated on expiration of a timer. On receipt of a router advertisement per interface a host will: o Add a local use address when it gets a new local prefix o Add a global address sequence when it gets a new global prefix o Add new subnet prefixes to list o Update lifetime of existing subnet prefixes The choice of subnet prefixes used should be configurable. Hosts will delete the associated address sequence when a prefix times out. Address sequences are formed generally by concatenation of a subnet prefix and an interface ID. Hosts can use localuse prefix to form a local use address. Interface can be an IEEE 802 MAC layer address. This is useful for intra-site communication and for communicating with SIPP DHCP. The global prefix is used to form a global address sequence. In this case the identifying address is a globally unique address. These address sequences are not IPv4 compatible and the address sequence must be at least length two. The interface ID is the MAC hardware address, if it fits in an 64bit address. SIPP DHCP can be used to acquire an interface identifier. The use of SIPP router discovery and IPv4 DHCP work by learning the SIPP prefix by listening to router advertisements and using IPv4 DHCP to acquire an IPv4 address. These are concatenated to form an IPv4 compatible SIPP address. This only supports single subnet prefix per interface. SIPP router discovery and SIPP DHCP work by using the router discovery to learn the global prefix and SIPP DHCP to acquire a SIPP address sequence. This approach supports multiple prefixes per interface. The reason for defining SIPP DHCP is that current DHCP is IPv4 specific. It needs to support multiple bindings per interface. SIPP DHCP is simpler because the SIPP host can form a local use address itself because the SIPP host learns its subnet from SIPP router discovery. A SIPP DHCP server will support both IPv4 and SIPP clients. The two types are distinguished by the use of different opcodes in the message. IPv4 compatible addresses are allocated out of a common database with IPv4 addresses. SIPP DHCP maps subnet prefix and client identifier to an address sequence and lease time. The operations supported are: o Allocate and bind an address sequence to a client in the subnet o Look up an existing address sequence in a subnet o Renew the lease time of a specified address sequence o Delete specified binding and deallocate address sequence After the lease time expires, the server may delete the binding and deallocate the address sequence. DHCP should allow for multiple servers to offer address sequences in the same subnet. Unfortunately, no mechanism to ensure consistency between them exists today. Servers cannot administer the same range of addresses in a subnet and ensure that a single binding exists per host per subnet. The implications are that a potential tow step allocation procedure (discover and select) and identify single binding when necessary are required. Address allocation with multiple servers works by the client multicasting a discovery message specifying the subnet. The servers make offers. The client chooses one offered address sequence. The client multicasts assign specifying offer and server. Specified servers send an acknowledgement, and others retract their offer. Other choices for this are that servers assign address sequence with zero lease. Servers return an acknowledgement when binding exists. Address renewal works by a client unicasting a renew message specifying the binding and server. The client multicasts a renew when the lease time nears expiration, and retransmits at half of the remaining lease time. Specified server extends and returns lease time in acknowledgement. Addresses are looked up by a client multicasting a query message specifying the subnet. Servers with a binding return address sequence. More than one address sequence may be returned. It is useful to avoid a two step operation on look up and to determine whether binding exists. The DHCP equivalent is to verify a specified address. IPAE Overview Bob Gilligan presented an overview of IPAE. The objectives of IPAE are to: o Allow SIPP and IPv4 hosts and routers to interoperate o Allow the Internet to transition smoothly from IPv4 to SIPP o Extend the life of the installed base of IPv4 hosts and routers IPAE's features include: o SIPP and IPv4 hosts can interoperate until IPv4 addresses run out. o Hosts do not need to change addresses when upgraded. o Hosts and routers can upgrade incrementally. o No upgrade interdependencies between hosts, routers, or DNS. o SIPP and IPv4 within a domain interoperate after IPv4 addresses run out. o Leverages installed base of IPv4 routers. IPAE mechanisms are composed of a number of mechanisms to make transition possible. Most visible is SIPP address format that is designed to be compatible with IPv4 address (contains IPv4 address). IPv4 are treated as subnet in SIPP routing. This allows SIPP to be run over an IPv4 cloud. Part of this is a mechanism to tunnel SIPP traffic in IPv4 (tunneling). Other is to translate IPv4 and SIPP. This permits SIPP traffic to flow over most of the Internet. IPv4 to SIPP translation to help with IPv4 routing scaling. The IPAE address format is: 64-bit compatible SIPP address format: 1 31 32 +---+---------------+---------------+ | C | SIPP Prefix | IPv4 Address | +---+---------------+---------------+ This allows IPAE addresses to be assigned to SIPP hosts, with the C bit defining which (C=1 is IPv4, C=0 is SIPP). The idea behind the IPAE routing model is that we can treat clusters of IPv4 as a single SIPP subnet. Packets to SIPP destinations within a cluster are tunneled SIPP in IPv4. Packets to IPv4 destinations within clusters are translated to IPv4. Packets to on-subnet destinations sent in raw SIPP or IPv4 form. Tunnel/translate/raw decision is made by using the C-bit and IPv4 reachability mask. o IPv4 clusters Requirement is that IPv4 be routable to all subnets in a cluster, with at least one IPAE router at the border. Cluster can be identified by a single SIPP address prefix. IPv4 routing is allowed between clusters and can run parallel to SIPP routing. Cluster can range from the entire Internet to one subnet. o SIPP/IPv4 routing model IPAE routers must route both SIPP and IPv4 traffic. They participate in both SIPP and IPv4 routing protocols. IPAE hosts have neighbor IPv4 and SIPP routers. Neighbor SIPP routers may be on the same subnet, and off subnet but on the same cluster. o Host and router configuration IPv4 reachability mask (cluster mask) defines the IPv4 scope of the cluster. SIPP address of neighbor SIPP routers (both on subnet and off subnet within cluster). Configuration mechanisms in system discovery, BOOTP/DHCP extensions, and configuration files. SIPP in IPv4 tunneling is used to reach SIPP destination in clouds. Can always tunnel to a destination in an IPv4 cloud if you have its SIPP address. o Translation of SIPP to IPv4 C-bit and reachability mask tell if packet should be translated. No configuration or mapping table is needed. o DNS Algorithm A new DNS record format has been defined. Records may be added for both IPv4 and SIPP hosts. SIPP records are optional, IPv4 records must exist. The hostname lookup algorithm is: 1. Lookup SIPP records first, IPv4 records second. 2. Traffic is SIPP if SIPP record is found. 3. Traffic is IPv4 if IPv4 record is found. Jim Bound suggested getting rid of the term IPAE Address; he said it should just be a SIPP address and thinks naming is important to make these issues clear. There was discussion about what can and cannot talk to a IPv4 address. How will host know if its SIPP address is an IPv4 address capable address, or is non-IPv4 capable. Need to know if it can be translated or not. This lead to a long discussion about the complexity of IPAE. It would appear that many people are having difficulty understanding why the mechanisms are there and how they work. The conclusion was that IPAE will need to be simplified and a new document written which makes the issues clear. Attendees Kannan Alagappan kannan@sejour.lkg.dec.com Steve Alexander stevea@lachman.com Michael Anello mike@xlnt.com David Arneson arneson@ctron.com Randall Atkinson atkinson@itd.nrl.navy.mil Jim Binkley jrb@cs.pdx.edu Ute Bormann ute@informatik.uni-bremen.de Michael Bradley bradley@mdd.comm.mot.com Michael Bringmann michael@rd.qms.com Jerry Burchfield burchfiel@bbn.com Ross Callon rcallon@wellfleet.com Frank Cannata cannata@cabletron.com John Carlson johnc@cac.washington.edu Paul Chang pchangmac@asante.com Ping Chen ping@apple.com Robert Christ rchrist@fhcrc.org Paul Ciarfella ciarfella@took.lkg.dec.com Bobby Clay clay@pscni.nasa.gov Alex Conta conta@lassie.lkg.dec.com Matt Crawford crawdad@fncent.fnal.gov Jonathon Crowhurst crowhurs@admin.ogi.edu Stephen Deering deering@parc.xerox.com Chuck deSostoa chuckd@cup.hp.com Peter DiCamillo Peter_DiCamillo@brown.edu Donald Eastlake dee@lkg.dec.com Kjeld Borch Egevang kbe@craycom.dk William Fink bill@wizard.gsfc.nasa.gov H. Tom Fitzpatrick fitz@ddn.af.mil Paul Francis francis@cactus.slab.ntt.jp Jerome Freedman jfjr@mbunix.mitre.org William Gilliam wag@cup.hp.com Robert Gilligan Bob.Gilligan@Eng.Sun.Com Ramesh Govindan rxg@thumper.bellcore.com Peter Grehan grehan@flotsm.ozy.dec.com Chris Gunner gunner@dsmail.lkg.dec.com William Haggerty haggerty@ctron.com Marc Hasson marc@mentat.com Robert Hinden hinden@eng.sun.com Richard Hovey hovey@silkie.enet.dec.com Christian Huitema Christian.Huitema@sophia.inria.fr Yoshinobu Inoue shin@hodaka.mfd.cs.fujitsu.co.jp Ronald Jacoby rj@sgi.com Robert Karsten robert@lachman.com Alan Katz katz@adonis.com Manu Kaycee kaycee_m@timeplex.com John Larson jlarson@parc.xerox.com Paul Leach paulle@microsoft.com Fong-Ching Liaw fong@eng.sun.com Joshua Littlefield josh@cayman.com Charles Lynn clynn@bbn.com J. Scott Marcus smarcus@bbn.com David Marlow dmarlow@relay.nswc.navy.mil Michael Massa mikemas@microsoft.com Daniel McDonald danmcd@itd.nrl.navy.mil Glenn McGregor glenn@lloyd.com Michael Michnikov mbmg@mitre.org Stephen Nahm sxn@sun.com Rina Nathaniel rina@rnd-gate.rad.co.il Erik Nordmark nordmark@eng.sun.com William Nowicki nowicki@sgi.com David O'Leary doleary@cisco.com Krishnan Parameshwaran krishnap@microsoft.com Brad Parker brad@fcr.com Andrew Pearson pearson@snmp.com Alan Perelman a_perelman@emulex.com George Phillips phillips@cs.ubc.ca Ram Ramanathan ramanath@bbn.com Ron Roberts rgr@stanford.edu William Robertson rob@agate.berkeley.edu Chris Seabrook cds@ossi.com Katsuhiro Sebayashi sebayasi@tnlab.ntt.jp William Simpson Bill.Simpson@um.cc.umich.edu Frank Solensky solensky@ftp.com Fumio Teraoka tera@csl.sony.co.jp Richard Thomas rjthomas@bnr.ca Susan Thomson set@bellcore.com Randy Turner rturner@qms.com Tony Valle valle@huntsville.sparta.com John Veizades veizades@wco.ftp.com Gary Veum veum@boa.gsfc.nasa.gov Mark Vickers mvickers@fhcrc.org Justin Walker justin@apple.com Jost Weinmiller jost@prz.tu-berlin.de Geoff White geoff@nexsys.net Walter Wimer ww0n+@andrew.cmu.edu Jane Wojcik jwojcik@bbn.com Shian-Tung Wong shian@dcsd.sj.nec.com