home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mobileip / mobileip-minutes-93nov.txt < prev    next >
Text File  |  1994-02-08  |  15KB  |  380 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Greg Minshall/Novell
  5.  
  6. Minutes of the IP Routing for Wireless/Mobile Hosts Working Group
  7. (MOBILEIP)
  8.  
  9. Thanks to Pierre Dupont for taking notes for these minutes.
  10.  
  11. Greg Minshall provided opening remarks and a brief history of the
  12. MOBILEIP Working Group.
  13.  
  14. Charlie Kunzinger gave a short presentation on the current Mobile IP
  15. Draft.  A question and answer session followed the presentation.
  16.  
  17.  
  18.    o Q: Why not two IP addresses for MH?
  19.      A:(Charlie Kunsinger) No need for two addresses
  20.      A:(Steve Deering) MH can acquire pop-up address to act as its own
  21.      FA
  22.  
  23.    o Q:(Tony LI) Does FA decrement TTL in IP header before forwarding
  24.      message to MH? Will this interfere with traceroute and MH location
  25.      privacy?
  26.      A: general discussion ensued on security requirements and the
  27.      pors/cons of TTL being decremented by FA. Issue was left for
  28.      further discussion on mailing list.
  29.  
  30.    o Q: How do two hosts with same subnet address communicate (one
  31.      local, other mobile)?
  32.      A: Proxy-ARP can be used to resolve addresses
  33.  
  34.    o Q: why not use source routing instead of tunneling?
  35.      A: too many problems with source routing, so it was agreed in NJ to
  36.      use encapsulation
  37.  
  38.    o Q:(Phil Karn) Can an MH be registered with more than one FA at the
  39.      same time?  This would allow MH to use either FA, and prevent
  40.      continuous registration flip/flop between FAs when MH is on a cell
  41.      boundary.
  42.      A: general discussion followed, with no clear consensus on whether
  43.      this would be beneficial.  For further discussion on mailing list?
  44.  
  45.    o Q:(Yakov Rekhter) Draft document should be clear about how mobile
  46.      IP breaks the IP subnet model.
  47.      A: Deferred for later discussion.
  48.  
  49.    o Q: Why use IP for registration protocol?  why not use UDP?
  50.      A: Discussion on 'architectural purity' vs ease of implementation
  51.      followed.  Some IP implementations do not provide an IP interface,
  52.      while all have a UDP interface.  Deferred for further discussion.
  53.  
  54.    o Q: Can Yakov expand on subnet model question?
  55.      A:(Yakov Rekhter) The IP over Shared Media draft addresses similar
  56.      problem.  The traditional model assumes that only hosts with same
  57.      subnet address can talk directly to each other.  Mobile IP means
  58.      that some hosts with same subnet ID cannot communicate directly.
  59.      Also, how do mobile hosts with different subnet IDs but on same
  60.      physical subnet communicate?
  61.  
  62.    o Q: Request that an authorization type be included before all
  63.      authorization fields in mobile IP messages.
  64.      A: Agreed.
  65.  
  66.    o Q:(Tony Li) Question on Incarnation number in Agent Advertisement
  67.      message.  Some MH may not have non-volatile storage.  Also, how is
  68.      it used?
  69.      A:(Dave Johnson) It is so that visiting MH can tell if FA has
  70.      crashed, an therefore if it must re-register with FA.
  71.  
  72.    o Q: Why not use Internet Security Protocol?
  73.      A: No decision has been reached on this yet.  Adopt a wait and see
  74.      attitude with respect to IP security.  It is not the mobile-ip wg's
  75.      job to solve IP security problems.  A suggestion was made to not
  76.      include any security fields in mobile IP messages.
  77.  
  78.    o Q: Are timer values defined?
  79.      A: The units and field sizes are defined, but not the recommended
  80.      values.  There may be dependancies between timers that need to be
  81.      considered.
  82.  
  83.    o Q: How and when does HA advertise reachability by proxy-arp?
  84.      A:(Andrew Myles) HA should never advertise unless its a router
  85.      also.  A HA that is not a router uses proxy-ARP to intercept
  86.      messages for MH. A discussion followed on whether the HA should
  87.      always be a router.
  88.  
  89.    o Q: Would like to see characteristics and behavior of HA included in
  90.      draft.
  91.      A: Agreed.
  92.  
  93.    o Q:(Steve Deering) When tunneling to FA, what happens when the MH is
  94.      not being served by the FA? Does packet go back to HA?
  95.      A: IMHP deals with this.
  96.  
  97.    o Q: If address resolution mechanism is not ARP, there may be a
  98.      problem using proxy-ARP.
  99.  
  100.    o Q: Why wait for a Home-Foreign confirm before sending notification
  101.      to the prior foreign agent?
  102.      A: The new FA is not authorized to serve the MH until it receives
  103.      the confirm message from the HA. A message to the prior FA may not
  104.      be required in this case, since the HA will direct messages to the
  105.      new FA as soon as it has authorized it, therefore there is no need
  106.      for the old FA to inform prior FA (the HA can inform the prior FA,
  107.      after it has authorized the new FA).
  108.  
  109.  
  110. IMHP Draft
  111.  
  112. Andew Myles gave a presentation on the IMHP draft.  Topics included:
  113.  
  114.  
  115.    o A definition of the MH, FA and HA elements.
  116.  
  117.    o The HA configuration (i.e., HA is not necessarily a router).
  118.  
  119.    o A new element, the cache agent, which keeps track of [MH, FA]
  120.      bindings.
  121.  
  122.    o Security (rationale for weak security).
  123.  
  124.    o Home subnet communication (performance requirements, routing
  125.      options).
  126.  
  127.    o Notification to the prior FA.
  128.  
  129.  
  130. On this final point it was mentioned that notification to the prior FA
  131. must be fast so that it does not become a black hole for packets.  The
  132. protocol should allow the new FA to accept packets from the prior FA
  133. before the MH is authorized to use the new FA. The MH must inform the
  134. prior FA as soon as it moves to a new FA. A period of questions and
  135. answers followed.
  136.  
  137.  
  138.    o Q:(Steve Deering) How are loops eliminated?
  139.      A: A number of alternative mechanisms exist to break routing loops.
  140.  
  141.    o Q:(Steve Deering) How does routing work when a FA crashes?  (Black
  142.      Hole)
  143.      A: A timeout will occur on cache entries, causing polling to the
  144.      destination FA (the Cache Agent polls the FA every timeout secs)
  145.  
  146.    o Q: How does Cache Agent get bindings?
  147.      A: Snooping can be used for dumb hosts.  This can be turned off in
  148.      the Cache agent is desired.
  149.  
  150.    o Q:What if MH moves from an authorized FA to an unauthorized FA? The
  151.      MH will be temporarily using an unauthorized FA.
  152.      A: During discussion it was pointed out that the FA may want to
  153.      bill someone (HA) for the service to the MH. Therefore the new FA
  154.      may not want to provide service to the MH until it is authorized to
  155.      do so by the HA.
  156.  
  157.    o Q: The Cache Agent may send redirect packets to any host.  This
  158.      could compromise security/privacy (e.g., location information).
  159.      A: A flag could be used to prohibit route forwarding
  160.  
  161.    o Q: What about ad-hoc networking?
  162.      A: for further study
  163.  
  164.    o Q: The cache timeout/polling mechanism may generate too much
  165.      network traffic.
  166.      A: Polling would only occur when the route is "active".
  167.  
  168.  
  169.  
  170. Outstanding Issues
  171.  
  172. Charlie Kunzinger presented a list of outstanding issues for discussion.
  173.  
  174.  
  175.    o Encapsulation method.  Generic or Home-grown?
  176.  
  177.      We need at least one required method.  Steve Deering argued against
  178.      negotiation.  Tony Li mentioned there already exists an
  179.      Internet-Draft on encapsulation (Generic Routing Encapsulation).
  180.      Dave Johnson stated that it had a large overhead and may not be
  181.      compatible with ICMP (in terms of header size).  Yakov Rekhter
  182.      stated that GRE was already implemented and being deployed.  Steve
  183.      Deering stated that generic encapsulation can be used with a reason
  184.      encoding (e.g., Mobile IP host).  Greg Minshall recommended that
  185.      the group continue discussion on the mailing list and pick an
  186.      encapsulation method later.
  187.  
  188.    o Foreign Agent receives forwarded message to MH for which it has no
  189.      binding.  What does it do with the message?  This issue was
  190.      discussed at the last session.
  191.  
  192.    o Should address fields be expanded to include address type and
  193.      length?
  194.  
  195.      Steve said that it may depend on how often packets are sent.  Dave
  196.      said the protocol is IP specific, address must fit into 64 ICMP
  197.      bits and Tony recommends addresses be TLV fields to support multi
  198.      protocols (e.g., Mobile appletalk).  No consensus was reached.
  199.  
  200.    o Do we need to control the number or frequency of registration
  201.      requests?
  202.  
  203.      A discussion followed on whether to allow MH to register in
  204.      multiple cells (i.e., with more than one FA) and have HA duplicate
  205.      messages to both FAs.  Steve suggested that protocol should not
  206.      disallow this, but recommended it be deferred to the advanced
  207.      functionality issue list.  This issue was left unresolved.
  208.  
  209.    o Is there a need for a retransmission timer on a registration
  210.      request by the MH?
  211.  
  212.      It was suggested that the MH be allowed to retransmit a request and
  213.      that the FA could respond with an in-progress message if it is
  214.      awaiting a response from the HA on a previous request for the MH.
  215.  
  216.    o State diagrams in draft document?
  217.  
  218.      This will be included in the next revision.
  219.  
  220.    o Should the protocol allow a hierarchy of HA?
  221.  
  222.      Should not preclude this option in draft.
  223.  
  224.    o Can TOS bit in IP header be used to identify mobile hosts?
  225.  
  226.      Dave stated that RFC 1122 suggests this is not possible.
  227.  
  228.    o Why can an FA terminate service to an MH? Also, HA can deregister
  229.      MH.
  230.  
  231.      It was suggested that there is no need to include FA to MH
  232.      deregistration since it will time out eventually.
  233.  
  234.    o Several comments were made on the style, packet format and byte
  235.      alignment in the draft.
  236.  
  237.    o Should ICMP or UDP be used for registration protocol?
  238.  
  239.      After some discussion, a poll was taken on the preferred method and
  240.      UDP was selected by a majority of those responding.
  241.  
  242.    o Weak security:  definition needs to be included in the draft.
  243.  
  244.    o To what degree do we break the subnet model?
  245.  
  246.      This is similar to the problem with large public data networks
  247.      (e.g., ATM). Yakov volunteered to communicate to the IAB how Mobile
  248.      IP will break the subnet model (and write an Internet-Draft?).
  249.  
  250.  
  251.  
  252. Cache Agent Model
  253.  
  254. A discussion on the pros and cons of the intermediate Cache Agent model
  255. followed, with no consensus being reached on how to proceed.  Some
  256. argued it should be left out of the initial draft while others argued
  257. the group should continue with plans to merge IMHP into the draft.
  258.  
  259.  
  260.  
  261. Documentation and Implementation Milestones
  262.  
  263. The group needs a specification which can be used to implement test
  264. systems (would like the specification before Christmas).  Charlie will
  265. continue work as the document editor.
  266.  
  267.  
  268.  
  269. Interim Meeting
  270.  
  271. An Interim meeting of the Mobile IP Working Group was proposed for
  272. January at Xerox PARC. It was suggested that implementors and
  273. specification writers convene for two days.
  274.  
  275.  
  276. Attendees
  277.  
  278. Kannan Alagappan         kannan@dsmail.enet.dec.com
  279. Kenneth Albanese         albanese@icp.net
  280. Nick Alfano              alfano@mpr.ca
  281. Stephen Batsell          batsell@itd.nrl.navy.mil
  282. Tom Benkart              teb@acc.com
  283. Mark Beyer               beyer_mark@tandem.com
  284. Ram Bhide                ram@nat.com
  285. Steven Blair             sblair@us.dell.com
  286. Jon Boone                boone@psc.edu
  287. Monroe Bridges           monroe@cup.hp.com
  288. Glen Cairns              cairns@mprgate.mpr.ca
  289. Ken Carlberg             Carlberg@cseic.saic.com
  290. Lida Carrier             lida@apple.com
  291. Bill Cash                cash@bangote.compaq.com
  292. Bilal Chinoy             bac@sdsc.edu
  293. Frank Ciotti             frankc@telxon.com
  294. David Clark              ddc@lcs.mit.edu
  295. Thomas Coradetti         tomc@digibd.com
  296. Stephen Deering          deering@parc.xerox.com
  297. Thomas Dimitri           tommyd@microsoft.com
  298. Waychi Doo               wcd@berlioz.nsc.com
  299. Avri Doria               avri@locus.com
  300. Robert Downs             bdowns@combinet.com
  301. Pierre Dupont            dupont@mdd.comm.mot.com
  302. Julio Escobar            jescobar@bbn.com
  303. Craig Fox                craig@ftp.com
  304. Richard Fox              rfox@metricom.com
  305. John Garrett             jwg@garage.att.com
  306. Robert Gilligan          Bob.Gilligan@Eng.Sun.Com
  307. Ramesh Govindan          rxg@thumper.bellcore.com
  308. Darren Griffiths         dag@ossi.com
  309. Robert Grow              bob@xlnt.com
  310. Regina Hain              rrosales@bbn.com
  311. Jari Hamalainen          jah@rctre.nokia.com
  312. Marc Hasson              marc@mentat.com
  313. Cornelius Healy          con@icp.net
  314. Juha Heinanen            juha.heinanen@datanet.tele.fi
  315. Kathryn Hill             khill@newbridge.com
  316. Robert Hinden            hinden@eng.sun.com
  317. Kevin Jackson            kjackson@concord.com
  318. David Jacobson           dnjake@vnet.ibm.com
  319. B.V. Jagadeesh           bvj@novell.com
  320. David Johnson            dbj@cs.cmu.edu
  321. Timo Jokiaho             timo.jokiaho@ntc.nokia.com
  322. Rick Jones               raj@cup.hp.com
  323. Elizabeth Kaufman        kaufman@biomded.med.yale.edu
  324. Byonghak Kim             bhkim@cosmos.kaist.ac.kr
  325. Mark Knopper             mak@merit.edu
  326. Tony Li                  tli@cisco.com
  327. Tracy Mallory            tracym@3com.com
  328. Wayne McDilda            wayne@dir.texas.gov
  329. Marjo Mercado            marjo@cup.hp.com
  330. Greg Minshall            minshall@wc.novell.com
  331. William Miskovetz        misko@cisco.com
  332. Randy Miyazaki           randy@lantron.com
  333. Robert Moose             rmoose@gateway.mitre.org
  334. Sandra Murphy            murphy@tis.com
  335. Andrew Myles             andrew@mpce.mg.edu.au
  336. Erik Nordmark            nordmark@eng.sun.com
  337. Masataka Ohta            mohta@cc.titech.ac.jp
  338. Todd Palgut              todd@nei.com
  339. Steve Parker             sparker@ossi.com
  340. Ismat Pasha              ipasha@icm1.icp.net
  341. John Penners             jpenners@advtech.uswest.com
  342. Charles Perkins          perk@watson.ibm.com
  343. Wayne Peters             waynep@telxon.com
  344. Ram Ramanathan           ramanath@bbn.com
  345. Jim Rees                 Jim.Rees@umich.edu
  346. Yakov Rekhter            yakov@watson.ibm.com
  347. Mike Ritter              mwritter@applelink.apple.com
  348. Benny Rodrig             brodrig@rnd-gate.rad.co.il
  349. Greg Ruth                gruth@gte.com
  350. Richard Schmalgemeier    rgs@merit.edu
  351. Martin Schulman          schulman@smtp.sprint.com
  352. Dallas Scott             scott@fluky.mitre.org
  353. Isil Sebuktekin          isil@nevin.bellcore.com
  354. Michael See              mikesee@vnet.ibm.com
  355. Satya Sharma             ssharma@chang.austin.ibm.com
  356. William Simpson          Bill.Simpson@um.cc.umich.edu
  357. Henry Sinnreich          hsinnreich@mcimail.com
  358. James Solomon            solomon@comm.mot.com
  359. Michael St.  Johns       stjohns@arpa.mil
  360. Martha Steenstrup        msteenst@bbn.com
  361. Robert Stevens           robs@join.com
  362. David Stine              dsa@cisco.com
  363. John Tavs                tavs@vnet.ibm.com
  364. Fumio Teraoka            tera@csl.sony.co.jp
  365. Susan Thomson            set@bellcore.com
  366. Akihiro Tominaga         tomy@sfc.wide.ad.jp
  367. Paul Traina              pst@cisco.com
  368. Hoe Trinh                htrinh@vnet.ibm.com
  369. Keisuke Uehara           kei@cs.uec.ac.jp
  370. John Veizades            veizades@ftp.com
  371. Gerry White              gerry@lancity.com
  372. Steve Willens            steve@livingston.com
  373. Bradley Wilson           wilson@ftp.com
  374. David Woodgate           David.Woodgate@its.csiro.au
  375. Richard Woundy           rwoundy@vnet.ibm.com
  376. Honda Wu                 honda@nat.com
  377. Jean Yao                 yao@cup.hp.com
  378. Weiping Zhao             zhao@nacsis.ac.jp
  379.  
  380.