home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / addrconf / addrconf-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  5KB  |  129 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. The ADDRCONF Working Group met once at the 33rd IETF on Wednesday, 19
  9. July.  (A second session had been scheduled, but the group finished all
  10. work before the end of the first session.)  Sue Thomson lead the
  11. meeting.
  12.  
  13.  
  14. Specification Review
  15.  
  16. Sue reviewed the changes made to the specification since the Danvers
  17. IETF meeting in April.  This included the work done at the interim
  18. meeting of the working group that was held in July.
  19.  
  20. The review brought up a couple of items for discussion:
  21.  
  22.  
  23.    o In order to be usable by a host, the address prefix provided by the
  24.      router must be short enough to accommodate the link-specific token.
  25.      That is, the prefix must be equal to 128 minus the length of the
  26.      link-specific token.
  27.  
  28.      The question was raised whether routers should be allowed to
  29.      advertise prefixes that are shorter than the length required to
  30.      accommodate the link-specific token, and have the host pad the gap
  31.      with zeroes.  It was argued that the configuration management
  32.      interface on the router could zero-fill the prefixes just as well,
  33.      and avoid situations where the same prefix with different lengths
  34.      is advertised by a router.
  35.  
  36.    o Default values for the timers in the protocol were discussed.
  37.      There was general agreement that the following values are ok:
  38.  
  39.       -  Invalidate timer:  infinity
  40.       -  Deprecate timer:  one week
  41.  
  42.  
  43. Link Initialization
  44.  
  45. Next, Sue walked through the steps of link initialization:
  46.  
  47.  
  48.   1. Form a link-local address.
  49.  
  50.   2. Join the all-nodes multicast address.
  51.  
  52.   3. Join the solicited-nodes multicast address.
  53.  
  54.   4. Dither.
  55.  
  56.   5. Send a neighbor solicitation for the link-local address.
  57.  
  58.   6. Expect to receive solicitation looped back from the local network
  59.      interface driver -- drop it when received.
  60.  
  61.   7. Wait to receive packets.
  62.  
  63.  7a. If second solicitation for the link-local address is received,
  64.      another node is preparing to use that address (a duplicate has been
  65.      detected).
  66.  
  67.  7b. If a neighbor advertisement for the link-local address is received,
  68.      another node is using that address (a duplicate has been detected).
  69.  
  70.   8. Send a router solicitation.
  71.  
  72.  
  73. This lead to discussion of a number of issues:
  74.  
  75.  
  76.    o Duplicate address detection.  The specification includes a section
  77.      explaining how a node can detect when an address generated using
  78.      stateless address autoconfiguration is being used by another node.
  79.      Some people felt that nodes should not be required to perform
  80.      duplicate address detection since the failure case is quite rare
  81.      and the cost to implement is non-trivial.  Others argued that,
  82.      while cases of duplicate addresses might be extremely unusual, they
  83.      are extremely difficult for network administrators to diagnose and
  84.      remedy when they do occur.
  85.  
  86.      After quite a bit of discussion, there was general agreement that
  87.      duplicate address detection should be required for link-local
  88.      addresses, and any address not based on the link-specific token.
  89.  
  90.    o Silently discard first duplicate solicitation.  In the duplicate
  91.      detection algorithm, a node is required to discard the first
  92.      duplicate solicitation message for its own address that it
  93.      receives.  This is done because of the assumption that the network
  94.      interface driver may loop back (deliver locally) the first
  95.      solicitation that the node sends.  Some people objected to this
  96.      language, arguing that it was an implementation issue whether the
  97.      driver loops back the solicitation packet.  Others argued that the
  98.      IP layer may not be able to disable the loopback at the driver
  99.      level, so the safest thing to do is to enable loopback and expect
  100.      one duplicate.
  101.  
  102.    o Serial-link hubs (e.g., PPP dial-in hubs).  The issue of whether
  103.      the specification should attempt to address the case of serial-link
  104.      hubs was brought up.  There was general agreement that this issue
  105.      should be covered in the IPv6 over PPP specification document, and
  106.      not in the address autoconfiguration specification.
  107.  
  108.    o Automatic resolution of duplicate addresses.  The specification
  109.      states only that a host should log the event when a duplicate is
  110.      detected and stop using the address.  Some suggested that the
  111.      specification might be able to specify a mechanism by which the
  112.      duplicate address could be resolved, allowing both hosts to
  113.      continue functioning.  But no proposal was offered for such a
  114.      mechanism, so the group agreed to leave the specification as is.
  115.  
  116.  
  117.  
  118. The Next Revision
  119.  
  120. Finally, the group discussed whether the specification should be moved
  121. forward to Proposed Standard after another revision of the draft.  It
  122. was agreed that the next version of the document should contain more
  123. explicit text on the interface initialisation procedure (perhaps in an
  124. Appendix).  Also, the time that the host is determined to be in address
  125. validation mode needs to begin as soon as the host has formed its
  126. link-local address, rather than after first sending out the Neighbor
  127. Solicitation.
  128.  
  129.