home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mobileip / mobileip-minutes-96jun.txt < prev    next >
Encoding:
Text File  |  1996-10-07  |  5.6 KB  |  131 lines
  1. Editor's note:  These minutes have not been edited
  2.  
  3.  
  4.            IP Routing for Wireless/Mobile Hosts (mobileip)
  5.                         Working Group Minutes
  6.                      36th IETF, Montreal, Canada
  7.              (reported by Steven M. Glass <glass@ftp.com>
  8.         further edited by Jim Solomon <solomon@comm.mot.com>)
  9.  
  10. ======================================================
  11. ================
  12.  
  13. I) Mobile IPv6, Wednesday, June 26, 1996, 1300 - 1500
  14.  
  15. 1) Agenda Bashing:  no items added
  16.  
  17. 2) Administravia:
  18.  - All IPv4 docs (except route optimization) have been approved as
  19.      Proposed Standard RFC's.
  20.  - New co-chair Erik Nordmark <nordmark@eng.sun.com> of Sun
  21.      Microsystems announced.
  22.  - Routing Area Director Joel Halpern presented the requirements for
  23.      advancing the IPv6 mobility draft to PS RFC:
  24.      1) Language of the doc must be acceptable to the working group.
  25.      2) Need an applicability statement.
  26.      3) Normally require implementation (and deployment) but the IESG
  27.         is understanding of the limitations on currently using IPv6.
  28.         Thus, this requirement will be waived.
  29.  
  30. 3) Discussion on: draft-ietf-mobileip-ipv6-01.txt, Dave Johnson
  31.    <dbj@cs.cmu.edu> and Charlie Perkins <charliep@watson.ibm.com>
  32.  
  33.  - Two implementations are under development (IBM & CMU).
  34.  
  35.  - Deregistration is tricky, and the order of events in deregistering
  36.    with your home agent should be clearly stated as is done in the
  37.    IPv4 draft.
  38.  
  39.  - After much rehashing of old arguments, it was once again decided
  40.    that the home agent is indeed a "router" -- i.e. a device which
  41.    "forwards packets not addressed to itself".  An important
  42.    observation is that only routers can receive IPv6 anycast packets,
  43.    which has implications to "home agent discovery" by mobile nodes.
  44.   
  45.  - It was decided that Mobile IPv6 need not impose any new
  46.    requirements upon the base IPv6 protocol documents.  In summary, it
  47.    was decided that IPv6 routers SHOULD (as distinctly opposed to
  48.    MUST) implement home agent functionality; and, likewise, IPv6 
  49. nodes
  50.    SHOULD (as distinctly opposed to MUST) implement binding cache 
  51. and
  52.    insertion of routing headers for routing packets to mobile nodes.
  53.    Some key observations about these decisions:
  54.  
  55.    + Not all routers have static/stable storage (as protection from
  56.      hard resets) for storage of binding information for mobile nodes.
  57.      A suggestion was made to add a "stable storage flag" to the
  58.      neighbor advertisement (or the binding acknowledgement) so that a
  59.      home agent could advertise this capability to prospective mobile
  60.      nodes.
  61.  
  62.    + One implication of not requiring ALL routers to be home agents is
  63.      that the "anycast" method of home agent-discovery as laid forth
  64.      in the current draft is broken.  This is because a non-home-agent-
  65.      but-a-router-nonetheless could consume the anycast.  It was
  66.      agreed that a solution to the home agent discovery problem should
  67.      be architected and included in the Mobile IPv6 draft.
  68.  
  69.    + The Binding Update destination option needs to be encoded in such
  70.      a way so that nodes that don't understand it send ICMP errors
  71.      back to the source.  There should also be a return code in the
  72.      Binding Acknowledge that says "I support this but I don't have
  73.      any room for you in my cache."  
  74.  
  75.    + If a host (that is not a router) supports a binding cache, it
  76.      MUST use its current bindings in preference to it's routing table
  77.      when sending a packet to a mobile node.
  78.  
  79.  - There was consensus that the Lifetime of a binding should work
  80.    similarly to the IPv4 mobility mechanism; i.e. a mobile node
  81.    proposes a Lifetime but the home agent MAY reduce the Lifetime to
  82.    an amount of time that it is actually willing to provide service.
  83.  
  84. 4) Discussion on draft-teraoka-ipv6-mobility-sub-03.txt, Fumio
  85.    Teraoka <tera@csl.sony.co.jp>.
  86.  
  87.    [Although this discussion actually occured in the second meeting
  88.    (due to lack of time in the first), it is included here because
  89.    of its topic area; namely, IPv6 mobility.]
  90.  
  91.  - Several issues were raised regarding the working group draft.  It
  92.    is the chair's opinion that Fumio should work with the co-authors
  93.    of the working group draft, within the framework set forth in that
  94.    document, to address any substantive deficiencies that can be
  95.    identified.  Topics for discussion included sourcing of multicast
  96.    packets by mobile nodes, firewall traversal, and appropriateness of
  97.    the utilization of routing headers.
  98.  
  99. ======================================================
  100. ================
  101.  
  102. II) Mobile IPv4, Thursday, June 27, 1996, 1300 - 1500
  103.  
  104. 1) Agenda Bashing:  no items added
  105.  
  106. 2) Administravia:
  107.  - All IPv4 docs (except route optimization) have been approved as
  108.      Proposed Standard RFC's.
  109.  - New co-chair Erik Nordmark <nordmark@eng.sun.com> of Sun
  110.      Microsystems announced.
  111.  - To advance the documents further, requires "significant operational
  112.    experience". (cf RFC 1264)
  113.  
  114. 3) Presentations.
  115.  
  116.   A number of presentations were given, each of which has slides that
  117.   will go into the IETF proceedings.  Several of them focussed on
  118.   firewall travesal by mobile nodes, which is seen as a key topic area
  119.   to be addressed by the working group in order to provide more broad
  120.   applicability of Mobile IP.
  121.   
  122.   Other presentations focussed on fast converging handoff algorithms
  123.   and link quality extensions to the Mobile IPv4 registration
  124.   protocol.
  125.  
  126.   Finally, route optimization was discussed in which Dave Johnson
  127.   summarized the changes to be made in the draft.  These basically
  128.   boil down to making route optimization work in IPv4 mobility in a
  129.   similar fashion to that proposed for IPv6 mobility.
  130.  
  131.