home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / addrconf / addrconf-minutes-95apr.txt < prev    next >
Text File  |  1995-05-27  |  7KB  |  141 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Susan Thomson/Bellcore
  5.  
  6. Minutes of the Address Autoconfiguration Working Group (ADDRCONF)
  7.  
  8. There were two sessions of the working group, both held on Tuesday
  9. afternoon, 4 April.  These are the minutes of both meetings.
  10.  
  11.  
  12. Review and Discussion
  13.  
  14. Susan Thomson reviewed the basic approach to address autoconfiguration
  15. in IPv6 as discussed on the mailing list December 94/January 1995 and
  16. refined at the interim meeting held at Xerox PARC in February 1994.  The
  17. approach being pursued is to have two separate mechanisms:  one to
  18. enable plug-and-play behavior and distributed control (the stateless
  19. scheme) and one to enable system administered, distributed control (the
  20. stateful scheme).  The stateless scheme is under the purview of this
  21. working group.  The stateful scheme is being addressed by the DHC
  22. Working Group in the form of DHCPv6.
  23.  
  24. A question was raised about whether there need be only one stateful
  25. scheme, and in particular whether an alternative approach of having a
  26. node multicast to a DNS server to look up its address had been
  27. considered.  There was some discussion about how this might work, but no
  28. decision to pursue this.  There was general agreement that the stateless
  29. draft should not use language that mandates DHCPv6 as the only stateful
  30. mechanism that might be used.
  31.  
  32. An overview was given of the host and router behavior resulting from a
  33. discussion at the XEROX PARC meeting, and since modified to include a
  34. mechanism by which hosts verify that the addresses formed are not
  35. duplicates of other addresses on the link.
  36.  
  37.  
  38. Open Issues
  39.  
  40. The open issues were then listed and the group discussed each in turn:
  41.  
  42.  
  43.    o Definition of Host Token
  44.  
  45.      At the XEROX PARC meeting, it was agreed that tokens would be
  46.      link-layer dependent, and that in the case of networks with IEEE
  47.      802 addresses, these would be used.  It was noted that a token for
  48.      a particular interface need not necessarily be the MAC address, but
  49.      only a number drawn from the IEEE 802 space that was unique per
  50.      link.
  51.  
  52.    o Message types/lifetime semantics
  53.  
  54.      The current proposal has been to piggyback off the Prefix
  55.      Information extension in Router Advertisements.  The problem is
  56.      that all extensions in a Router Advertisement share a single
  57.      lifetime which is set very low (of the order of minutes) for the
  58.      purpose of detecting when routers go down in a timely fashion.
  59.      This lifetime is deemed too small for prefix advertisements, which
  60.      are used in address autoconfiguration.  The consensus of the
  61.      working group was that separate lifetimes were needed.
  62.  
  63.      There was discussion of what the second lifetime should apply to,
  64.      whether to only prefixes used to form addresses or to prefixes used
  65.      in neighbor discovery as well, and what the performance tradeoffs
  66.      were of having a separate message advertising the prefix versus
  67.      having the information advertised in a separate extension of the
  68.      Router Advertisement.  The performance tradeoffs were considered a
  69.      non-issue.  Several folks felt that the address configuration
  70.      mechanism should be separated from neighbor discovery mechanisms
  71.      entirely.  The rough consensus of the working group was to separate
  72.      neighbor discovery prefix advertisements from address configuration
  73.      advertisements and have them advertised in entirely separate
  74.      messages.
  75.  
  76.    o Address deprecation and deletion
  77.  
  78.      The current specification says that an address should not be
  79.      removed as long as it is being actively used for communication, or
  80.      is listed in the DNS. There is currently no ``timeout'' on the
  81.      deprecated state.  An address could remain deprecated for a very
  82.      long time.  Some people felt that an explicit indication was
  83.      necessary to definitively tell a node to stop using an address.  It
  84.      was suggested that the address prefix advertisements should carry a
  85.      ``kill lifetime'' value as well as a ``deprecate lifetime.''  There
  86.      was no final resolution on this issue.
  87.  
  88.      Another related issue raised was when it was safe to reuse the
  89.      network prefix, given that the deprecated state may last a long
  90.      time.
  91.  
  92.    o Duplicate address detection
  93.  
  94.      There is no guarantee that the token is unique, even if it is the
  95.      node's link-layer address.  It is considered sufficient to detect
  96.      duplicate addresses, but not automate duplicate avoidance.  On a
  97.      node with multiple addresses, it is sufficient to verify just one
  98.      address on initialization.  The current draft of the specification
  99.      outlines a mechanism for duplicate address detection.
  100.  
  101.      Many people thought that this feature was important enough to be
  102.      needed in every system.  The group agreed that this feature should
  103.      be a ``must implement'' feature that must be enabled by default.
  104.  
  105.    o Further configuration indicator
  106.  
  107.      On a prefix advertisement, a bit of information is used to indicate
  108.      whether the host should contact DHCP for other configuration
  109.      information after forming an address using the stateless scheme.
  110.      The working group agreed that this was a useful feature.
  111.  
  112.    o Allow for DHCPv6 server in routerless scenario
  113.  
  114.      It is currently defined that in the case where no router
  115.      advertisements are being heard, a host must query for a DHCPv6
  116.      server so that hosts in a routerless topology still works.  While
  117.      this complicates the protocol somewhat, it was agreed that support
  118.      for this topology is needed.
  119.  
  120.  
  121. Other
  122.  
  123. John Veizades led a discussion on automatic address configuration for
  124. ``terminal server'' configurations.  He would like the nodes served by
  125. the terminal server to be able to autoconfigure their addresses without
  126. having to configure a separate prefix per link.
  127.  
  128. He suggested defining a separate field in the address to enable a
  129. terminal server to hand out unique addresses to all nodes based on its
  130. address.  Other suggestions were to just make the terminal server a
  131. router, or assign the box a range of IEEE 802 addresses, one for each of
  132. its serial links.  No decision was reached on this issue.
  133.  
  134. Allison Mankin, in her role as Area Director, made a suggestion to
  135. separate the autoconfiguration mechanism (on which there is basic
  136. agreement) from the reconfiguration part (which is still experimental)
  137. into two separate documents to try to expedite progress of the
  138. documents.  This generated a lot of heat.  No consensus was reached at
  139. the meeting to do this.
  140.  
  141.