home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / addrconf / addrconf-minutes-95jun.txt < prev    next >
Text File  |  1995-10-18  |  9KB  |  164 lines
  1.  
  2. INTERIM_MEETING_REPORT_
  3.  
  4. Reported by Susan Thomson/Bellcore
  5.  
  6. Minutes of the Address Autoconfiguration Working Group (ADDRCONF)
  7.  
  8. The ADDRCONF Working Group held an interim meeting at Sun Microsystems
  9. in Menlo Park, California on 13-14 June 1995.
  10.  
  11.  
  12.  
  13. Specification Overview and Discussion
  14.  
  15. Sue Thomson presented an overview of the latest specification,
  16. particularly how it ties in with the latest Neighbor Discovery draft,
  17. and raised open issues.
  18.  
  19. Addrconf information is advertised in Router Advertisements.  In
  20. particular, there are flags in the fixed part of the Router
  21. Advertisement that indicate whether stateless or stateful mode is in use
  22. for address and other configuration parameters.  The Prefix Information
  23. extension (which is also used by prefix discovery) contains the
  24. necessary information for obtaining and timing out prefixes, and
  25. addresses formed from those prefixes.
  26.  
  27. On receiving Router Advertisements with a Prefix extension, the host
  28. updates its address list, adding any new addresses formed from new
  29. prefixes advertised, and resetting the lifetime of addresses formed from
  30. prefixes that are being readvertised.
  31.  
  32. In the latest draft, two lifetimes are advertised per prefix:  one to
  33. specify when addresses change from being valid to being deprecated, and
  34. one to specify when addresses changed from being deprecated to being
  35. invalid.  The intention of the two lifetimes is to allow a graceful
  36. transition period during renumbering.  That is, the deprecation time
  37. warns the host that an address is going to become invalid (the
  38. invalidation time must be no less than the deprecation time) and that
  39. the host should start using another (presumably longer lasting) address
  40. in new communications to minimise the risk of breaking communications
  41. when the old times out.  The idea is to make the deprecation period long
  42. enough so that most, if not all, communications have switched over to
  43. using the new address by the time the old one becomes invalid.
  44.  
  45. There was concern about application impact of deprecated addresses.
  46. However, all the specification intends to specify is some mechanism that
  47. enables an application (perhaps with the help of the network layer) to
  48. choose an address at the start of a communication that is likely to last
  49. for the duration of that communication, so that the problem of
  50. renumbering during a communication is avoided to the extent possible.
  51.  
  52. There was a suggestion that protocols should be designed so that
  53. communications can survive address changes and so that deprecation is
  54. not needed.  However, it was argued that this is not a problem that is
  55. likely to be solved soon and that the above is a reasonable compromise
  56. at this time.
  57.  
  58. There was some discussion about how much to specify with respect to
  59. default source address preferences.  It was clear that this is a
  60. slippery slope and that things quickly become complicated.  The
  61. resolution was to simply specify that valid global/site-local addresses
  62. are preferred over deprecated addresses in choosing a source address for
  63. new communications, assuming there are other valid global/site-local
  64. addresses to choose from.  It should be noted that there will always be
  65. at least one valid address to choose from, the link-local address.
  66. However, the rules should allow a deprecated address to be used if only
  67. the link-local is valid and the destination is (possibly) off-link.
  68.  
  69. It is possible for hosts to get address and other information, such as
  70. MTU and hop limit, using both stateless and stateful mode.  It is also
  71. possible that both stateless and stateful mode are configured to be on
  72. at the same time.  There was some discussion about how much to specify
  73. with respect to the advertisement of conflicting information.  (It is
  74. also possible for multiple routers to hand out conflicting information,
  75. e.g., the same prefix could be advertised with different lifetimes.)
  76. The implication of the current specification is that 1) the host accepts
  77. the union of all information received from all sources and 2) if
  78. conflicting information is received from different sources, the host
  79. will just update its state with the latest information received, i.e.,
  80. there are no special rules for giving preference to one or the other.
  81. It was decided that this should be left as is, but such events may be
  82. logged.  It was also decided that in the Neighbor Discovery (ND)
  83. document the router advertisement should be sent to the ``all-nodes''
  84. multicast address, rather than the ``all-hosts'' address so that routers
  85. could discover and log that they had been configured to hand out
  86. conflicting information.
  87.  
  88. Hosts are expected to attempt stateful autoconfiguration when no routers
  89. are detected on the link.  It was suggested that we only do this on
  90. startup, since the need to do this at other times is rare.
  91.  
  92. Default lifetimes for prefix advertisements were not specified in the
  93. current specification, the intention being to force system
  94. administrators to configure the lifetimes specifically since the
  95. lifetimes are expected to be environment-dependent.  It was suggested
  96. that defaults should be set, but that they be very conservative, e.g., a
  97. deprecation lifetime of several days (longer than a long weekend) and an
  98. invalidation time of infinity.  The value of infinity needs to be
  99. specified in the specification.
  100.  
  101. There was agreement as to the transition between stateless and stateful
  102. configuration as outlined in the specification.
  103.  
  104. An overview of the duplicate address detection algorithm was presented.
  105. It was agreed that there would be one change to the soliciting node part
  106. of the algorithm when the node is validating its address.  Since
  107. inhibiting local loopback on sending out multicast packets is not always
  108. supported, it was agreed that the neighbor solicitation to detect a
  109. duplicate address must always be looped back.  A duplicate address would
  110. then be detected if more than solicitation is received by a host.  It
  111. was also noted that the IPv6 multicast document needs to be written and
  112. the local delivery requirements clarified.
  113.  
  114. It was also agreed that if the stateful mode is being used to acquire
  115. addresses and these addresses are not the same as those that would be
  116. configured using the stateless mode, then the duplicate address
  117. detection algorithm should be applied to these addresses too.
  118.  
  119. It is now defined that hosts should randomise their delay both before
  120. embarking on the duplicate detection algorithm (addrconf specification)
  121. and when sending a Router Solicitation (ND specification).  If a host
  122. does both on initialisation, dithering is only necessary once and should
  123. be specified as such.  This needs to be cleaned up.
  124.  
  125. There was some discussion about how much space should be available for
  126. storing prefixes and addresses.  There was a strong suggestion that
  127. hosts should be able to accept all advertised prefixes, and complain if
  128. not.
  129.  
  130. The issue of whether addrconf information should be defined as part of
  131. Router Advertisements or advertised separately was discussed.  It was
  132. noted that addrconf processing needs to be done as often as prefix
  133. processing and needs similar information so why not advertise together.
  134. Also, that Router Advertisements have been designed to advertise a range
  135. of information, not only that needed for router discovery, e.g., it is
  136. used to advertise other configuration information such as MTU and hop
  137. limit.  There is, however, a demultiplexing issue -- folks felt that
  138. many implementations did this already for ICMP messages, and for those
  139. implementations that did not, new software needs to be written in any
  140. case, so this should not present a problem.  The consensus of the group
  141. was to maintain the current approach, with further discussion to be done
  142. on the mailing list.
  143.  
  144. In addition, there were several suggestions to add clarity to the
  145. document:
  146.  
  147.  
  148.    o Provide more rationale for the concept of deprecated addresses.
  149.  
  150.    o Change the name or acronym of the Administered flag (M flag) in
  151.      Router Advertisement.  The alternative suggestion was ``Managed.''
  152.  
  153.    o Make interface initialisation procedure more explicit.  At the
  154.      moment, the various functions that need to be done are not spelled
  155.      out in order in one place.
  156.  
  157.    o Clarify the relationship between the network and upper layers in
  158.      choosing source addresses in new communications.
  159.  
  160.    o Need to clarify use of ``hardware address'' vs.  use of ``MAC
  161.      address'' as tokens.  The link-specific part of the document will
  162.      be moved to ``IP-over-foo'' documents, yet to be written.
  163.  
  164.