home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ngtrans / ngtrans-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  6KB  |  125 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Mike Davis/Bay Networks and Bob Gilligan/Sun Microsystems
  5.  
  6. Minutes of the New Generation Transition Working Group (NGTRANS)
  7.  
  8. These minutes are based on excellent notes by Mike Davis with edits and
  9. additional detail added by Bob Gilligan.
  10.  
  11.  
  12. Introduction
  13.  
  14. The NGTRANS Working Group met for one of its two scheduled sessions on
  15. Tuesday, 18 July.  Bob Gilligan lead the session.  All work was
  16. completed by the end of first session, so the second session was
  17. cancelled.  The agenda for the meeting was:
  18.  
  19.  
  20.    o Document status
  21.    o Routing aspects draft
  22.    o Auto tunneling and multicast
  23.    o Implementation status
  24.  
  25.  
  26. Alan Lloyd, who had asked to discuss the topic ``Auto Tunneling and
  27. Multicast,'' was not present, so this topic was not discussed.
  28.  
  29.  
  30. Document Status
  31.  
  32. The working group document, ``Transition Mechanisms for IPv6 Hosts and
  33. Routers'' <draft-ietf-ngtrans-trans-mech-01>, has been in Last Call for
  34. about two weeks, with only one significant comment.  The chair could see
  35. no barriers to a swift promotion to Proposed Standard.
  36.  
  37.  
  38. Routing Aspects
  39.  
  40. Ross Callon gave a presentation on the Internet-Draft ``Routing Aspect
  41. of IPv6 Transition'' <draft-haskin-ipv6-routing-aspects-01.txt>,
  42. written by himself and Dimitry Haskin.  This occupied most of the
  43. meeting.  The talk followed the organization of the paper.  A number of
  44. issues were discussed along the way:
  45.  
  46.  
  47.    o Terminology.  It was noted that this specification and the
  48.      transition mechanisms specification use different terms for the
  49.      same thing in a few cases.  For example, what this specification
  50.      calls ``semi-automatic tunneling'' is termed a ``configured default
  51.      tunnel'' in the mechanisms specification.  It was agreed that this
  52.      specification should use the same terms as the mechanisms
  53.      specification.
  54.  
  55.    o Router to Router automatic tunneling.  Since automatic tunneling is
  56.      a mechanism to reach the final end host, it is not clear whether
  57.      ``router to router automatic tunneling'' makes any sense.  It was
  58.      agreed that it will be either left undefined or disallowed in the
  59.      specification.
  60.  
  61.    o Host to Host automatic tunneling.  The specification as currently
  62.      written specifies that hosts should only use automatic tunneling
  63.      when there is no IPv6 router on their attached link.  When there is
  64.      an IPv6 router on the link, the traffic should be sent in ``raw
  65.      IPv6'' form via the IPv6 router.  Many people raised the concern
  66.      that this was a policy decision that should be left up to the
  67.      network administrator.  Some sites might wish to tunnel over IPv4,
  68.      even though an IPv6 path exists, because the IPv6 routing system is
  69.      less reliable.  Other sites might prefer sending via the IPv6
  70.      routers in order to speed up the transition.  It was noted that the
  71.      transition mechanisms specification leaves this policy decision up
  72.      to the user, and it was agreed that this specification should as
  73.      well.
  74.  
  75.    o Host to Router tunneling.  The current draft specifies that a host
  76.      only uses this mode of tunneling when there is no on-link IPv6
  77.      router.  Some people felt that this, too, was a policy decision
  78.      that should be left up to the administrator.  The group agreed to
  79.      relax this constraint.  Matt Crawford was given homework to write
  80.      language for the draft on this topic.
  81.  
  82.    o Router to Host automatic tunneling.  IPv6 routers that perform
  83.      automatic tunneling and that are connected to the IPv6 routing
  84.      system need to advertise reachability into the IPv6 routing system
  85.      for IPv4-compatible destinations.  There was a lot of discussion on
  86.      the best way to do this, but no decisions were made.  Further
  87.      discussion on the list was encouraged.
  88.  
  89.    o Automatic tunneling to IPv4 multicast addresses.  The question was
  90.      raised how a node should transmit an IPv6 packet when the IPv4
  91.      address embedded in the destination IPv4-compatible address is an
  92.      IPv4 multicast address.  One thought is to ``tunnel'' the packet to
  93.      the IPv4 multicast address.  Neither this specification nor the
  94.      transition mechanisms specification say anything about this
  95.      situation.  Since it is not clear whether this would be useful or
  96.      not, it was agreed to leave automatic tunneling to IPv4 multicast
  97.      addresses undefined for the time being.
  98.  
  99.    o Ross will clean up the example on page 15.
  100.  
  101.    o Overlap with transition mechanisms specification.  Someone noted
  102.      that this specification re-defines mechanisms that are also defined
  103.      in the transition mechanisms specification.  The definitions are
  104.      not in conflict, but having multiple definitions for the same
  105.      mechanism could confuse readers, so it was agreed that the
  106.      redundant definitions will be deleted from the routing
  107.      specification.
  108.  
  109.    o Progress of this specification.  It was decided to publish at least
  110.      one more revision of this document in Internet-Draft form, as a
  111.      product of this working group.  The group agreed that the eventual
  112.      disposition of this document should be as a ``Best Current
  113.      Practice'' RFC, rather than an Internet standards-track document.
  114.  
  115.  
  116. Implementation Status
  117.  
  118. Jim Bound gave an update of the implementation work.  As far as anyone
  119. in the group commented, Bay Networks is the only router vendor that is
  120. implementing IPv6.  Several host implementations exist or are in
  121. progress.  There was hope of conducting interoperability testing at or
  122. before the next IETF meeting in Dallas.  We particularly need to test
  123. tunneling.
  124.  
  125.