CURRENT_MEETING_REPORT_

Reported by Mike Davis/Bay Networks and Bob Gilligan/Sun Microsystems

Minutes of the New Generation Transition Working Group (NGTRANS)

These minutes are based on excellent notes by Mike Davis with edits and
additional detail added by Bob Gilligan.


Introduction

The NGTRANS Working Group met for one of its two scheduled sessions on
Tuesday, 18 July.  Bob Gilligan lead the session.  All work was
completed by the end of first session, so the second session was
cancelled.  The agenda for the meeting was:


   o Document status
   o Routing aspects draft
   o Auto tunneling and multicast
   o Implementation status


Alan Lloyd, who had asked to discuss the topic ``Auto Tunneling and
Multicast,'' was not present, so this topic was not discussed.


Document Status

The working group document, ``Transition Mechanisms for IPv6 Hosts and
Routers'' <draft-ietf-ngtrans-trans-mech-01>, has been in Last Call for
about two weeks, with only one significant comment.  The chair could see
no barriers to a swift promotion to Proposed Standard.


Routing Aspects

Ross Callon gave a presentation on the Internet-Draft ``Routing Aspect
of IPv6 Transition'' <draft-haskin-ipv6-routing-aspects-01.txt>,
written by himself and Dimitry Haskin.  This occupied most of the
meeting.  The talk followed the organization of the paper.  A number of
issues were discussed along the way:


   o Terminology.  It was noted that this specification and the
     transition mechanisms specification use different terms for the
     same thing in a few cases.  For example, what this specification
     calls ``semi-automatic tunneling'' is termed a ``configured default
     tunnel'' in the mechanisms specification.  It was agreed that this
     specification should use the same terms as the mechanisms
     specification.

   o Router to Router automatic tunneling.  Since automatic tunneling is
     a mechanism to reach the final end host, it is not clear whether
     ``router to router automatic tunneling'' makes any sense.  It was
     agreed that it will be either left undefined or disallowed in the
     specification.

   o Host to Host automatic tunneling.  The specification as currently
     written specifies that hosts should only use automatic tunneling
     when there is no IPv6 router on their attached link.  When there is
     an IPv6 router on the link, the traffic should be sent in ``raw
     IPv6'' form via the IPv6 router.  Many people raised the concern
     that this was a policy decision that should be left up to the
     network administrator.  Some sites might wish to tunnel over IPv4,
     even though an IPv6 path exists, because the IPv6 routing system is
     less reliable.  Other sites might prefer sending via the IPv6
     routers in order to speed up the transition.  It was noted that the
     transition mechanisms specification leaves this policy decision up
     to the user, and it was agreed that this specification should as
     well.

   o Host to Router tunneling.  The current draft specifies that a host
     only uses this mode of tunneling when there is no on-link IPv6
     router.  Some people felt that this, too, was a policy decision
     that should be left up to the administrator.  The group agreed to
     relax this constraint.  Matt Crawford was given homework to write
     language for the draft on this topic.

   o Router to Host automatic tunneling.  IPv6 routers that perform
     automatic tunneling and that are connected to the IPv6 routing
     system need to advertise reachability into the IPv6 routing system
     for IPv4-compatible destinations.  There was a lot of discussion on
     the best way to do this, but no decisions were made.  Further
     discussion on the list was encouraged.

   o Automatic tunneling to IPv4 multicast addresses.  The question was
     raised how a node should transmit an IPv6 packet when the IPv4
     address embedded in the destination IPv4-compatible address is an
     IPv4 multicast address.  One thought is to ``tunnel'' the packet to
     the IPv4 multicast address.  Neither this specification nor the
     transition mechanisms specification say anything about this
     situation.  Since it is not clear whether this would be useful or
     not, it was agreed to leave automatic tunneling to IPv4 multicast
     addresses undefined for the time being.

   o Ross will clean up the example on page 15.

   o Overlap with transition mechanisms specification.  Someone noted
     that this specification re-defines mechanisms that are also defined
     in the transition mechanisms specification.  The definitions are
     not in conflict, but having multiple definitions for the same
     mechanism could confuse readers, so it was agreed that the
     redundant definitions will be deleted from the routing
     specification.

   o Progress of this specification.  It was decided to publish at least
     one more revision of this document in Internet-Draft form, as a
     product of this working group.  The group agreed that the eventual
     disposition of this document should be as a ``Best Current
     Practice'' RFC, rather than an Internet standards-track document.


Implementation Status

Jim Bound gave an update of the implementation work.  As far as anyone
in the group commented, Bay Networks is the only router vendor that is
implementing IPv6.  Several host implementations exist or are in
progress.  There was hope of conducting interoperability testing at or
before the next IETF meeting in Dallas.  We particularly need to test
tunneling.