home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / addrconf / addrconf-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  8KB  |  192 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. Sue Thomson presented, as part of the agenda, a list of open issues that
  9. needed to be addressed in the current draft.  These issues formed the
  10. basis for discussion in two of the three sessions.  In the first
  11. session, Dave Katz presented an overview of the current draft during
  12. which some of the above issues and a few others were raised.
  13.  
  14. The minutes are structured by issues discussed.
  15.  
  16.  
  17. Formation of Local-use Address
  18.  
  19. There was a suggestion that the term local-use address be renamed.  The
  20. term is used in the current draft to mean an address of intra-link
  21. scope.  One name suggested was local link address, but there was no
  22. agreement to use this.
  23.  
  24. A network prefix needs to be defined for this type of address.
  25.  
  26. There must be one way of forming this address given a particular link
  27. type.  In the case of IEEE 802 addresses, this is done by concatenating
  28. a well-known network prefix with the IEEE 802 address.  How to form an
  29. ATM address was left as an open issue.  There were no objections to the
  30. current proposal for assignment on point-to-point links.
  31.  
  32.  
  33. Formation of Stateless Address
  34.  
  35. There seemed to be a feeling that more than one algorithm for forming an
  36. address should be possible per link type.  Matt Crawford, for example,
  37. presented a scheme that hashes on a host token to produce a shorter host
  38. part for the address.  It was unclear what mechanisms could be used to
  39. ensure uniqueness in stateless mode.
  40.  
  41. It is necessary that the various algorithms be defined, given certain
  42. parameters.  At the least, there should be a standard mechanism for
  43. forming an address which all servers must implement.  In the case of
  44. IEEE 802 addresses, an address is produced by concatenating an 80-bit
  45. network prefix with the IEEE 802 address.  There was some debate about
  46. whether there should be a default mode of operation to ensure that two
  47. servers use the same mechanism for forming an address by default.  The
  48. group decided to define a default, in order to ensure that two servers
  49. assign unique addresses in plug `n' play operation.
  50.  
  51. There was a suggestion that there should not be a stateless mode at all.
  52.  
  53.  
  54.  
  55. Relationship Between Address Lifetime and Holding Time
  56.  
  57. Currently the holding time is really just a refresh interval, rather
  58. than a tight bound on how long the address may be used by a host.  The
  59. question was raised whether the holding time should be allowed to also
  60. specify a tight bound on an address so that address reuse can still be
  61. supported by the protocol.  While this is not an issue for the stateless
  62. mode, it is an issue for the stateful case.  The resolution was to leave
  63. the draft as it stands.
  64.  
  65. The question was raised as to what to do with incoming messages if an
  66. address is not refreshed, but not explicitly invalidated.  The thoughts
  67. were to refuse subsequent connections, and accept UDP.
  68.  
  69.  
  70. Protocol Usage (Link Layer versus ICMP versus UDP)
  71.  
  72. The argument for sending address assignment requests at the link layer
  73. is that the host needs to form a temporary address in order to get a
  74. permanent address.  This was called ``aesthetically bogus.''  It was
  75. pointed out that this would mean a separate protocol per link layer.
  76.  
  77. In IPv4, UDP is not required.  A suggestion to use ICMP for the
  78. front-end protocol and UDP for the backend protocol did not receive much
  79. support.  It was agreed that the same protocol should be used for both
  80. front-end and back-end.
  81.  
  82. After a little discussion, a consensus was reached not to use link
  83. layer.  After much discussion, ICMP was chosen by the flip of a coin.
  84.  
  85.  
  86. Other Useful Parameters to Address Assignment Request
  87.  
  88. There was a quick consensus that the specification needs to be clearer
  89. on parameters used for each interface type.
  90.  
  91. There was a feeling that the domain name may be a useful parameter
  92. (e.g., to disambiguate when host tokens are not guaranteed to be
  93. unique), although it was not clear when it would be used.
  94.  
  95. There was a suggestion that there be a field in the address reply that
  96. indicated what method was being used by the server for address
  97. assignment.  This might be useful for network management.  There was no
  98. agreement to add this.
  99.  
  100.  
  101. Server Advertises or Host Retries?
  102.  
  103. How do you know when a server comes up:  server advertises or host
  104. retries?
  105.  
  106. It was suggested that servers advertise in the manner of routers
  107. creating router advertisements.  However, this does not scale in
  108. stateful mode.
  109.  
  110. There was a discussion of renumbering:  servers say when to renumber by
  111. sending ``Hello'' messages to tell hosts when to re-request address.
  112. The problem with this is that servers are duplicating a function that is
  113. already present in routers which means it must be ensured that
  114. information advertised is properly synchronized.  It was suggested that
  115. address configuration be a router function for simplicity.
  116.  
  117.  
  118. Addrconf and Determinism
  119.  
  120. There is a strong requirement that address requests produce the same
  121. results, given the same input parameters.  There was a suggestion that
  122. this be a mandatory requirement.  This is important to keep in mind
  123. since protocols have been designed on the assumption that host addresses
  124. remain constant, e.g., DNS and SNMP MIBs.
  125.  
  126.  
  127. Addrconf and DNS Autoregistration of Inverse Mapping
  128.  
  129. When DNS is in use, there is the question of which entity updates the
  130. inverse mapping in DNS. The host may not always have the authority to do
  131. so.  Two alternatives were suggested:  the addrconf server could do so
  132. on the host's behalf since it can validate that the address being
  133. registered is indeed the one assigned to that host (or at least has the
  134. right prefix).  The second alternative was to have the server reply with
  135. credentials that the host could pass on to prove that the update is
  136. valid.  It was unclear what the security implications of the latter
  137. approach was.
  138.  
  139. The current draft specifies the first alternative above, in which the
  140. DNS autoregistration is done as a byproduct of each address assignment.
  141. Having autoregistration be a byproduct of the assignment operation could
  142. be problematic for several reasons, one of which is that DNS updates
  143. need only be done when a new address is handed out, not on every
  144. refresh.  Also, the DNS update should be done asynchronously so that
  145. successful address assignment is not prevented if DNS is unavailable.
  146.  
  147. There was some agreement that the host should drive the registration
  148. process (whether through the server or otherwise) and that the address
  149. assignment operation should be separate from the registration operation.
  150. This does introduce overhead for hosts attached to links where latency
  151. is an issue, though.  So, the capability for doing both in a single
  152. request may be desirable.  Also, the reply to an address request should
  153. indicate to the host whether to register the address through the server
  154. or not.
  155.  
  156. There were a couple of strong statements to the effect that address
  157. autoconfiguration should not rely on the DNS dynamic update mechanism
  158. being implemented.  There is parallel effort, however, in the DNSIND
  159. Working Group to specify such an extension to DNS.
  160.  
  161.  
  162. Relationship Between Addrconf and DHCPng
  163.  
  164. There is other information that may need to be autoconfigured besides
  165. the address including a domain name and protocol stack parameters.  It
  166. is the intention that DHCPng will provide this information.  [Note that
  167. having DHCPng perform stateful address configuration and having the
  168. addrconf protocol perform only stateless address configuration has
  169. subsequently come under consideration.]  The addrconf protocol should
  170. indicate to the host in a reply to an address request whether it needs
  171. to consult DHCPng for further information.
  172.  
  173.  
  174. Advanced Dentist's Office Scenario
  175.  
  176. In this configuration, two links are connected by a multihomed host.  No
  177. router is present.  It is possible that, if the host tokens used to form
  178. an address are only defined to be unique on a link the addresses formed
  179. with intra-link scope are not unique.  The suggestion was to manually
  180. configure a server in the multihomed host with a different network
  181. prefix per interface.
  182.  
  183.  
  184. ``Anonymous'' Addresses
  185.  
  186. The need was mentioned for the address assignment request to return an
  187. address even if no host token was provided.  This is for hosts that do
  188. not have a token or do not care that the same address be handed out each
  189. time an address needs to be assigned.  There was not agreement that such
  190. a function was needed.
  191.  
  192.