INTERIM_MEETING_REPORT_ Reported by Bob Hinden/Sun Microsystems Minutes of the Simple Internet Protocol Plus Working Group (SIPP) Agenda o Document status o Implementation status o Subnet model discussion o Auto-configuration/Sue's drafts o Bob's site prefix mask idea o Ran's security Internet-Drafts o Plans for next meeting Document Status Documents that have to get out as RFCs prior to the IETF meeting: SIPP Done IPAE Done, want to rev some items Routing and Addr Done ICMP/IGMP Needs to be completed DHCP Changes Done DNS Done, may update SIPP White paper Done, may update based on comments ARP Changes/Usage (see discussion later) Documents that it would be nice to get out as RFCs: Neighbor Discovery Draft available Auto Config Draft available OSPF for SIPP Done API specification Needs to be updated for SIPP SIPP RIP Needs to be completed IDRP for SIPP Done MIB Needs to be written Action items: Bob Hinden will contact Marshall Rose for ``volunteer'' to do the SIPP MIB; Jim Bound, Bob Gilligan and Ramesh Govindan will update the SIPP API specification in two weeks; Bob Gilligan will revise the IPAE specification; and Ramesh Govindan will update and send out the ICMP specification. Implementation Status Jim Bound is doing an OSF/1 implementation. Larry Peterson's student is doing a SIPP X-Kernel implementation. NRL is doing an implementation which includes the security headers. JB suggested having an implementors meeting at the Seattle IETF meeting. Steve Pink status? Bellcore has 4.1.x implementation running for SIPP. Includes routing headers, SIPP multicast, 64-bit addresses. Need to start an SIPP-Bone deployment CH: Would like to get changes made to the INRIA code so can use that as a base for further work. BG: Suggested it would be good to have one person/group to coordinate BSD-based implementation. JB: Thinks application should only see 64-bit addresses. Applies to API work. RG: Demo at IETF? No. BG: Should focus on doing implementation testing. BG: Now has three machines running SIPP on Internet. Two at Sun, one at PARC. We should start doing coordination among implementors, addresses, Schedule a SIPP Connectathon? Yes, this is a good idea. A week in the spring. CH: Also need to test routing protocols. Modify GateD (SIPPD?). Subnet Model SD: Last year's assumption that we were going to an ES-IS areas type scheme instead of the IP subnet model. In this model Subnet would identify multiple physical wires. He had thought this would be a step forward. After working on ROAD document, he discovered when working on SIPP multicast, this approach gets very messy. Issue is that multicast routing protocols using source based algorithms want to know where a packet came from. A multihomed host would be required to send packets out on each interface. Assumption is that routers have host routes. This is harder because hosts may not have all similar addresses. The ES-IS approach makes this much harder. Also had push back from John Moy because it would be hard to do in OSPF, because it would consume one of OSPF's levels. SD proposed to go back to IP's subnet model where a single subnet can only represent one link (note that a link can have multiple subnets). If we do this, the questions is how to do address resolution. Can still do 64-bit ARP, ARP like things query response mechanism, or ES-IS style periodic advertisements. BH: Keeping mechanism similar to IP is good. Less change for administrators. BG: This will make moving hosts harder. SD: Can be handled with discovery and auto address assignment. CH: Stay with approach like IP and handle mobile hosts as a special case. Mobile hosts finds a router. JB: Asked Steve to describe models SD: Allowing multiple links per subnet requires hosts to inform router of their identity. SD: Problem with multicast is that source sensitive multicast routing uses source subnet number to identify source. This requires host to send packets out each interface instead of only one. Current IP model only requires host to only send out on one interface. PF: The ES-IS also makes auto configuration harder if you are putting subnet addresses in local use address when not using 802 addresses. Decision: Group decided to revert to IP subnet model (away from ES-IS area model). Will require changes to ROAD document. PF: Agreed to modify ROAD specification. Action: Francis: Modify to ROAD document to reflect decision to use IP subnet model. EN: Need to specify how multihomed host works. SD: Two questions: (1) Originate a packet must it be sent over interface that belongs to source address? (2) Should you refuse to accept packet which arrives on wrong interface? PF: Do not need to specify how multihomed hosts work now. SD: What do do about ARP? Three are currently three proposals: (1) 64bit ARP, (2) ICMP query/response, and (3) periodic host advertisements. Plus one approach to use as part of a transition scheme: (0) 32bit ARP with fixed prefix. JB: Should we also document 0? MC: What is wrong with existing ARP. BG: 32-bit ARP will not work with 64-bit SIPP. Need to do something new. EN: Also noted that other mechanisms (router discovery and resolution, redirect) include address resolution and are already in ICMP. CH: Implementation is easier, it is in IP layer, no change to network drivers, makes it easier to integrate routing lookup and the resolution of network addresses. Decision: After a lengthly discussion the group agreed to Approach 2 using ICMP Query/Response. JB: Should we do mobile SIPP document? SD: No let work proceed in the Mobile IP Working Group. Auto Configuration BootP extension to return SIPP address prefix. DHCP specifies that SIPP prefix must be returned. Auto Address Assignment/Configuration Discussion of effect on DHCP. SD: Minimal changes, or SIPP version of DHCP with all fields 64-bits etc. Approach described in the current document can also be used for get IPAE compatible addresses. EN: Proposed using new SIPP mechanism for address assignment, people can use DHCP for other configuration items. Take address assignment out of DHCP for SIPP. SD: Proposed separate protocols for address assignment from other configuration items, and use DHCP for other information. Decision: Group decided to proceed with Sue Thompson's auto host address assignment approach. Will want to later update DHCP to run over SIPP and update other information in DHCP for SIPP devices. ST: Wants another reviewer for her document. Decision: Group decided that ICMP/IGMP specification should have the packet formats for the neighbor and router discovery messages, but the description of how they are used should be in Bill Simpsons document. Bill Simpsons document should describe mechanisms for router discovery, address resolution, and host redirects. Messages should include fields for mobility but the document should not describe mobility mechanisms. EN: Do we want to start assigning SIPP multicast addresses. We should start separate multicast addresses. SD: Willing to be SIPP multicast assigned number authority. Do we want a SIPP assigned number ID? Erik Nordmark will write this document. Action: Nordmark: Write up SIPP assigned number document. Site Prefix Mask [Bill Simpson has raised objections to this in the past, but could not attend this meeting.] BG: Host need to decide what kind of packet to send (SIPP, IPAE, IPv4). Current rules require packet to be either IPv4 or IPAE out of site The current IPAE specification uses an algorithm that is based on high order 32 bits to determine if destination is IP reachable or SIPP reachable. This requires all SIPP nodes within same 32-bit prefix to be within IPv4 connectivity. BG proposed solution is to use a mask over the interface address to determine IPv4 connectivity. All zero mask would mean that all destinations are IPv4 reachable, all ones means all are SIPP reachable. Bill Simpson previously raised concerned that this is another piece of per node configuration information (per interface). Would need to put this in auto-configuration information. SD: Seems like the right thing to do. Believes answer to Bill's concerns is to add this to router advertisement messages. Long discussion of merits/problems. Some thought that this force packets to be sent using IPv4 when it could be sent directly with SIPP. BG: Think he can write down an algorithm which works, but might not always send the optimal packet type. SD: Thinks the masks are good to define IPv4 routability. EN: Notes the that change to use the IP subnet model removes another mask, so adding this one is a wash. Group generally agreed to go with this, but needs some more fleshing out on mailing list. BG will work out details of algorithm. Ran's Security Internet-Drafts This was not discussed because Ran Atkinson could not attend this meeting. Next Meeting The next SIPP meeting will be at the Seattle IETF. Jim Bound would like to set up a developers meeting at the IETF. Should there be a SIPP Working Group dinner at the IETF? Summary of Action Items Hinden Contact Marshall Rose for ``volunteer'' to do SIPP MIB Bound/Gilligan/Govindan Update SIPP API specification in two weeks Gilligan Revise IPAE specification Govindan Send to SIPP List, update and send out ICMP specification Francis Modify to ROAD document to reflect decision to use IP subnet model. Nordmark Write up SIPP assigned number document. Hinden Plan for Spring SIPPathon event coordination. This would a mix of testing over the Internet and a locations on east and west coasts of the US and one in Europe. Summary of Decisions o Group decided to revert to IP subnet model (away from ES-IS area model). Will require changes to ROAD document. PF: Agreed to modify ROAD specification. o After a lengthly discussion the group agreed to using ICMP Query/Response. o Group decided to proceed with Sue Thompson's auto host address assignment approach. o Group decided that ICMP/IGMP specification should have the packet formats for the neighbor and router discovery messages, but the description of how they are used should be in Bill Simpsons document. Attendees Jim Bound bound@zk3.dec.com Matt Crawford crawdad@fncent.fnal.gov Stephen Deering deering@parc.xerox.com Paul Francis francis@cactus.slab.ntt.jp Robert Gilligan Bob.Gilligan@Eng.Sun.Com Ramesh Govindan rxg@thumper.bellcore.com Robert Hinden hinden@eng.sun.com Christian Huitema Christian.Huitema@sophia.inria.fr Erik Nordmark nordmark@eng.sun.com Susan Thomson set@bellcore.com