home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / sipp / sipp-minutes-94feb.txt < prev    next >
Text File  |  1994-06-07  |  11KB  |  319 lines

  1.  
  2. INTERIM_MEETING_REPORT_
  3.  
  4. Reported by Bob Hinden/Sun Microsystems
  5.  
  6. Minutes of the Simple Internet Protocol Plus Working Group (SIPP)
  7.  
  8.  
  9. Agenda
  10.  
  11.    o Document status
  12.    o Implementation status
  13.    o Subnet model discussion
  14.    o Auto-configuration/Sue's drafts
  15.    o Bob's site prefix mask idea
  16.    o Ran's security Internet-Drafts
  17.    o Plans for next meeting
  18.  
  19.  
  20. Document Status
  21.  
  22. Documents that have to get out as RFCs prior to the IETF meeting:
  23.  
  24.  SIPP                      Done
  25.  IPAE                      Done, want to rev some items
  26.  Routing and Addr          Done
  27.  ICMP/IGMP                 Needs to be completed
  28.  DHCP Changes              Done
  29.  DNS                       Done, may update
  30.  SIPP White paper          Done, may update based on comments
  31.  ARP Changes/Usage         (see discussion later)
  32.  
  33. Documents that it would be nice to get out as RFCs:
  34.  
  35.  Neighbor Discovery        Draft available
  36.  Auto Config               Draft available
  37.  OSPF for SIPP             Done
  38.  API specification         Needs to be updated for SIPP
  39.  SIPP RIP                  Needs to be completed
  40.  IDRP for SIPP             Done
  41.  MIB                       Needs to be written
  42.  
  43. Action items:  Bob Hinden will contact Marshall Rose for ``volunteer''
  44. to do the SIPP MIB; Jim Bound, Bob Gilligan and Ramesh Govindan will
  45. update the SIPP API specification in two weeks; Bob Gilligan will revise
  46. the IPAE specification; and Ramesh Govindan will update and send out the
  47. ICMP specification.
  48.  
  49.  
  50. Implementation Status
  51.  
  52. Jim Bound is doing an OSF/1 implementation.
  53.  
  54. Larry Peterson's student is doing a SIPP X-Kernel implementation.
  55.  
  56. NRL is doing an implementation which includes the security headers.
  57.  
  58. JB suggested having an implementors meeting at the Seattle IETF meeting.
  59.  
  60. Steve Pink status?
  61.  
  62. Bellcore has 4.1.x implementation running for SIPP. Includes routing
  63. headers, SIPP multicast, 64-bit addresses.
  64.  
  65. Need to start an SIPP-Bone deployment
  66.  
  67. CH: Would like to get changes made to the INRIA code so can use that as
  68. a base for further work.
  69.  
  70. BG: Suggested it would be good to have one person/group to coordinate
  71. BSD-based implementation.
  72.  
  73. JB: Thinks application should only see 64-bit addresses.  Applies to API
  74. work.
  75.  
  76. RG: Demo at IETF? No.  BG: Should focus on doing implementation testing.
  77.  
  78. BG: Now has three machines running SIPP on Internet.  Two at Sun, one at
  79. PARC. We should start doing coordination among implementors, addresses,
  80.  
  81. Schedule a SIPP Connectathon?  Yes, this is a good idea.  A week in the
  82. spring.  CH: Also need to test routing protocols.  Modify GateD
  83. (SIPPD?).
  84.  
  85.  
  86. Subnet Model
  87.  
  88. SD: Last year's assumption that we were going to an ES-IS areas type
  89. scheme instead of the IP subnet model.  In this model Subnet would
  90. identify multiple physical wires.  He had thought this would be a step
  91. forward.  After working on ROAD document, he discovered when working on
  92. SIPP multicast, this approach gets very messy.  Issue is that multicast
  93. routing protocols using source based algorithms want to know where a
  94. packet came from.  A multihomed host would be required to send packets
  95. out on each interface.  Assumption is that routers have host routes.
  96. This is harder because hosts may not have all similar addresses.  The
  97. ES-IS approach makes this much harder.  Also had push back from John Moy
  98. because it would be hard to do in OSPF, because it would consume one of
  99. OSPF's levels.
  100.  
  101. SD proposed to go back to IP's subnet model where a single subnet can
  102. only represent one link (note that a link can have multiple subnets).
  103. If we do this, the questions is how to do address resolution.  Can still
  104. do 64-bit ARP, ARP like things query response mechanism, or ES-IS style
  105. periodic advertisements.
  106.  
  107. BH: Keeping mechanism similar to IP is good.  Less change for
  108. administrators.
  109.  
  110. BG: This will make moving hosts harder.  SD: Can be handled with
  111. discovery and auto address assignment.
  112.  
  113. CH: Stay with approach like IP and handle mobile hosts as a special
  114. case.  Mobile hosts finds a router.
  115.  
  116. JB: Asked Steve to describe models SD: Allowing multiple links per
  117. subnet requires hosts to inform router of their identity.
  118.  
  119. SD: Problem with multicast is that source sensitive multicast routing
  120. uses source subnet number to identify source.  This requires host to
  121. send packets out each interface instead of only one.  Current IP model
  122. only requires host to only send out on one interface.
  123.  
  124. PF: The ES-IS also makes auto configuration harder if you are putting
  125. subnet addresses in local use address when not using 802 addresses.
  126.  
  127. Decision:  Group decided to revert to IP subnet model (away from ES-IS
  128. area model).  Will require changes to ROAD document.  PF: Agreed to
  129. modify ROAD specification.
  130.  
  131. Action:  Francis:  Modify to ROAD document to reflect decision to use IP
  132. subnet model.
  133.  
  134. EN: Need to specify how multihomed host works.
  135.  
  136. SD: Two questions:  (1) Originate a packet must it be sent over
  137. interface that belongs to source address?  (2) Should you refuse to
  138. accept packet which arrives on wrong interface?
  139.  
  140. PF: Do not need to specify how multihomed hosts work now.
  141.  
  142. SD: What do do about ARP? Three are currently three proposals:  (1)
  143. 64bit ARP, (2) ICMP query/response, and (3) periodic host
  144. advertisements.
  145.  
  146. Plus one approach to use as part of a transition scheme:  (0) 32bit ARP
  147. with fixed prefix.
  148.  
  149. JB: Should we also document 0?
  150.  
  151. MC: What is wrong with existing ARP. BG: 32-bit ARP will not work with
  152. 64-bit SIPP. Need to do something new.
  153.  
  154. EN: Also noted that other mechanisms (router discovery and resolution,
  155. redirect) include address resolution and are already in ICMP. CH:
  156.  
  157. Implementation is easier, it is in IP layer, no change to network
  158. drivers, makes it easier to integrate routing lookup and the resolution
  159. of network addresses.
  160.  
  161. Decision:  After a lengthly discussion the group agreed to Approach 2
  162. using ICMP Query/Response.
  163.  
  164. JB: Should we do mobile SIPP document?  SD: No let work proceed in the
  165. Mobile IP Working Group.
  166.  
  167.  
  168. Auto Configuration
  169.  
  170. BootP extension to return SIPP address prefix.  DHCP specifies that SIPP
  171. prefix must be returned.
  172.  
  173. Auto Address Assignment/Configuration
  174.  
  175. Discussion of effect on DHCP. SD: Minimal changes, or SIPP version of
  176. DHCP with all fields 64-bits etc.
  177.  
  178. Approach described in the current document can also be used for get IPAE
  179. compatible addresses.
  180.  
  181. EN: Proposed using new SIPP mechanism for address assignment, people can
  182. use DHCP for other configuration items.  Take address assignment out of
  183. DHCP for SIPP.
  184.  
  185. SD: Proposed separate protocols for address assignment from other
  186. configuration items, and use DHCP for other information.
  187.  
  188. Decision:  Group decided to proceed with Sue Thompson's auto host
  189. address assignment approach.
  190.  
  191. Will want to later update DHCP to run over SIPP and update other
  192. information in DHCP for SIPP devices.
  193.  
  194. ST: Wants another reviewer for her document.
  195.  
  196. Decision:  Group decided that ICMP/IGMP specification should have the
  197. packet formats for the neighbor and router discovery messages, but the
  198. description of how they are used should be in Bill Simpsons document.
  199.  
  200. Bill Simpsons document should describe mechanisms for router discovery,
  201. address resolution, and host redirects.  Messages should include fields
  202. for mobility but the document should not describe mobility mechanisms.
  203.  
  204. EN: Do we want to start assigning SIPP multicast addresses.  We should
  205. start separate multicast addresses.  SD: Willing to be SIPP multicast
  206. assigned number authority.
  207.  
  208. Do we want a SIPP assigned number ID? Erik Nordmark will write this
  209. document.
  210.  
  211. Action:  Nordmark:  Write up SIPP assigned number document.
  212.  
  213.  
  214. Site Prefix Mask
  215.  
  216. [Bill Simpson has raised objections to this in the past, but could not
  217. attend this meeting.]
  218.  
  219. BG: Host need to decide what kind of packet to send (SIPP, IPAE, IPv4).
  220. Current rules require packet to be either IPv4 or IPAE out of site
  221.  
  222. The current IPAE specification uses an algorithm that is based on high
  223. order 32 bits to determine if destination is IP reachable or SIPP
  224. reachable.  This requires all SIPP nodes within same 32-bit prefix to be
  225. within IPv4 connectivity.
  226.  
  227. BG proposed solution is to use a mask over the interface address to
  228. determine IPv4 connectivity.  All zero mask would mean that all
  229. destinations are IPv4 reachable, all ones means all are SIPP reachable.
  230.  
  231. Bill Simpson previously raised concerned that this is another piece of
  232. per node configuration information (per interface).  Would need to put
  233. this in auto-configuration information.
  234.  
  235. SD: Seems like the right thing to do.  Believes answer to Bill's
  236. concerns is to add this to router advertisement messages.
  237.  
  238. Long discussion of merits/problems.  Some thought that this force
  239. packets to be sent using IPv4 when it could be sent directly with SIPP.
  240. BG: Think he can write down an algorithm which works, but might not
  241. always send the optimal packet type.
  242.  
  243. SD: Thinks the masks are good to define IPv4 routability.  EN: Notes the
  244. that change to use the IP subnet model removes another mask, so adding
  245. this one is a wash.
  246.  
  247. Group generally agreed to go with this, but needs some more fleshing out
  248. on mailing list.  BG will work out details of algorithm.
  249.  
  250.  
  251. Ran's Security Internet-Drafts
  252.  
  253. This was not discussed because Ran Atkinson could not attend this
  254. meeting.
  255.  
  256.  
  257. Next Meeting
  258.  
  259. The next SIPP meeting will be at the Seattle IETF. Jim Bound would like
  260. to set up a developers meeting at the IETF. Should there be a SIPP
  261. Working Group dinner at the IETF?
  262.  
  263.  
  264. Summary of Action Items
  265.  
  266. Hinden                      Contact Marshall Rose for ``volunteer'' to
  267.                             do SIPP MIB
  268.  
  269. Bound/Gilligan/Govindan     Update SIPP API specification in two weeks
  270.  
  271. Gilligan                    Revise IPAE specification
  272.  
  273. Govindan                    Send to SIPP List, update and send out ICMP
  274.                             specification
  275.  
  276. Francis                     Modify to ROAD document to reflect decision
  277.                             to use IP subnet model.
  278.  
  279. Nordmark                    Write up SIPP assigned number document.
  280.  
  281. Hinden                      Plan for Spring SIPPathon event
  282.                             coordination.  This would a mix of testing
  283.                             over the Internet and a locations on east
  284.                             and west coasts of the US and one in
  285.                             Europe.
  286.  
  287.  
  288. Summary of Decisions
  289.  
  290.    o Group decided to revert to IP subnet model (away from ES-IS area
  291.      model).  Will require changes to ROAD document.  PF: Agreed to
  292.      modify ROAD specification.
  293.  
  294.    o After a lengthly discussion the group agreed to using ICMP
  295.      Query/Response.
  296.  
  297.    o Group decided to proceed with Sue Thompson's auto host address
  298.      assignment approach.
  299.  
  300.    o Group decided that ICMP/IGMP specification should have the packet
  301.      formats for the neighbor and router discovery messages, but the
  302.      description of how they are used should be in Bill Simpsons
  303.      document.
  304.  
  305.  
  306. Attendees
  307.  
  308. Jim Bound                bound@zk3.dec.com
  309. Matt Crawford            crawdad@fncent.fnal.gov
  310. Stephen Deering          deering@parc.xerox.com
  311. Paul Francis             francis@cactus.slab.ntt.jp
  312. Robert Gilligan          Bob.Gilligan@Eng.Sun.Com
  313. Ramesh Govindan          rxg@thumper.bellcore.com
  314. Robert Hinden            hinden@eng.sun.com
  315. Christian Huitema        Christian.Huitema@sophia.inria.fr
  316. Erik Nordmark            nordmark@eng.sun.com
  317. Susan Thomson            set@bellcore.com
  318.  
  319.